Japan’s national vulnerability portal formally confirmed today that certain Sony FeliCa contactless IC chips carry a hardware-level cryptographic flaw that enables a proximity-based attack capable of degrading the chip’s security strength — and because the defect is baked into the silicon of chips shipped before 2017, no software patch is possible. The JVN advisory JVN#40509781 assigns the identifier CVE-2026-59776 to the flaw.

Japan Vulnerability Notes (JVN), operated jointly by JPCERT/CC and the Information-technology Promotion Agency (IPA), published advisory JVN#40509781 on July 21, 2026. The vulnerability carries a CVSS v4.0 base score of 7.0 (High) and CVSS v3.0 base score of 6.8, with the attack vector classified as Physical — meaning an adversary must reach close proximity to the card to exploit it.

What Sony FeliCa Is — and Why Hundreds of Millions of Cards Are in Scope

FeliCa — short for Felicity Card — is Sony’s contactless RFID smart card technology, operating at 13.56 MHz and conforming to the ISO/IEC 18092 NFC standard. First commercialized with Hong Kong’s Octopus transit system, FeliCa became the de facto infrastructure for contactless services across Japan and parts of Asia.

By the time Sony launched its 2020-generation chip, more than 1.4 billion FeliCa chips had been produced worldwide. The technology spans transit ticketing on rail and bus networks throughout Japan — Suica, PASMO, ICOCA, and dozens of regional equivalents — as well as electronic money services at convenience stores, vending machines, and retailers; employee ID and building access cards; university student IDs; and condominium door locks.

The JVN advisory specifically targets chips shipped before 2017. That cutoff corresponds to hardware manufactured in an era before Sony introduced its current-generation chip in 2020, which carries ISO/IEC 15408 EAL6+ certification — among the highest security evaluation levels available for IC systems.

How the Cryptographic Flaw Works

The vulnerability is classified as CWE-325 Missing Cryptographic Step — a category that MITRE describes as occurring when a product omits a required operation in a cryptographic algorithm, producing weaker security than the algorithm is advertised to deliver. According to the JVN advisory, an attacker with physical access to an affected card can perform specific operations during the cryptographic exchange process that degrade the chip’s intended security strength, after which reading or tampering with data stored on the card becomes feasible.

The MITRE documentation for CWE-325 specifically identifies resource-constrained hardware — devices with limited memory or slower CPUs — as a common setting for this class of weakness, because designers sometimes omit computationally intensive steps under the mistaken belief they are unnecessary. IC card chips, which derive all power from the reader during the brief communication window and complete a full transaction in approximately 0.1 seconds, represent exactly this constraint profile.

FeliCa cards communicate contactlessly at a range of 10 centimeters or less, which means a reader held at short range — near a transit gate, in a shared workspace, or in a crowded commute environment — can initiate the card exchange sequence. The cryptographic degradation that CWE-325 enables does not happen in a single swipe; an attacker would need to engage the card’s authentication process with specifically crafted operations during that session. But the CVSS Physical attack vector classification reflects the practical reality that “physical access” to a contactless card is meaningfully easier than physical access to a device with a port — a card in a wallet in a bag presents a very different surface than a locked laptop.

Sony confirmed the vulnerability and stated that the security of FeliCa-based services rests not only on the chip itself but on the overall system architecture that each service operator builds around it. The company issued countermeasure guidelines to service operators and directed them to its technical documentation portal for impact assessment and remediation.

Why Hardware Has No Patch — and What That Means for Users

Unlike software vulnerabilities, which vendors can address by pushing an update, the CWE-325 flaw in pre-2017 FeliCa chips cannot be fixed by any update Sony or a carrier delivers. The cryptographic step is missing from the chip’s silicon — it is a design artifact of the manufacturing era, not a configurable parameter.

For consumers, the practical mitigation guidance in the JVN advisory is direct: manage IC cards carefully to prevent theft or skimming. That means keeping cards in RFID-blocking wallets or card sleeves, monitoring e-money and transit accounts for unexpected transactions, and reporting lost or stolen cards immediately.

For service operators — transit authorities, building managers, employers, universities — the JVN advisory directs compliance with Sony’s countermeasure guidelines and the FeliCa developer website’s technical documentation. The principal remediation tools available are: service-level authentication and anomaly detection (catching suspicious card activity before it causes harm), blocklisting of specific cards suspected of compromise, and acceleration of hardware replacement cycles to retire pre-2017 cards from active use.

JR East for Suica stated that its system’s broader security measures ensure continued safe use. ICOCA, operated by JR West, confirmed it had been strengthening monitoring since receiving Sony’s August 2025 report and will continue coordinating with Sony and related operators. Operators of transit and payment networks typically follow replacement cycles measured in years; transit gate infrastructure in Japan operates on five-to-seven-year cycles, giving operators an established mechanism to phase out affected cards.

One practical note flagged by Japan transit technology analysts: Mobile FeliCa — the version embedded in smartphones via the Osaifu-Keitai system, and accessible through Apple Pay and Google Pay in Japan — is not affected by this vulnerability. The flaw is limited to physical IC cards. Travelers and commuters who have moved their Suica or PASMO to Apple Pay or Google Pay are not in scope for this advisory.

A Disclosure Process That Took Nearly a Year — and What That Reveals

The JVN publication today closes a disclosure process that ran nearly eleven months from its first public exposure — not because Sony was slow to respond, but because Japan’s coordinated vulnerability disclosure framework encountered a type of vulnerability it was not designed to handle efficiently.

Under Japan’s Information Security Early Warning Partnership Guideline, established by METI in 2004, the standard workflow calls for a researcher to report a vulnerability to IPA, JPCERT/CC to coordinate with the developer, and the developer to prepare a remediation or workaround before public advisory publication — typically within 45 days of initial contact. Yudai Kirishiki of Unknown Technologies, Inc. followed this process when he reported the flaw to IPA in late July 2025.

That process was disrupted on August 28, 2025, when Kyodo News published an unauthorized exclusive based on information obtained from sources involved in the disclosure — before Sony had prepared countermeasures or notified all affected service operators. Sony was forced to issue an emergency statement acknowledging the flaw’s existence without being able to provide the guidance that gives public disclosure its safety value — a situation security expert Hiroshi Tokumaru described as increasing user anxiety without enhancing safety. METI and IPA issued a joint notice in September 2025 urging media and researchers to follow established disclosure protocols.

The reason the formal JVN publication arrived eleven months after Kyodo’s leak — rather than 45 days after Kirishiki’s IPA report — is not documented in any single source but is visible in the structure of the problem. A software vulnerability can be patched; the developer issues an update, distributes it, and the advisory goes out once the patch is available. A hardware vulnerability with no patch instead requires every affected service operator to individually assess impact, strengthen monitoring, issue guidance to their own users, and prepare blocklisting and replacement workflows — across potentially dozens of transit authorities, payment processors, building managers, and government ID system operators simultaneously. None of Japan’s standard coordinated disclosure rules were written to govern that multi-party hardware remediation timeline.

That gap — between a 45-day window designed for software patches and an eleven-month coordination effort required for hardware without patches — is the structural lesson this disclosure process made visible. It is a gap that will only become more relevant as IoT hardware, embedded systems, and contactless infrastructure continue to age in place.

Current-Generation Chips and the Path Forward

Sony’s post-2020 FeliCa chips are not affected by CVE-2026-59776. The 2020-generation hardware achieved ISO/IEC 15408 EAL6+ certification, and Sony announced it in 2020 as carrying updated security to address the maturation of attack capabilities. For organizations still operating pre-2017 hardware in building access, employee ID, or IoT deployments, the JVN disclosure is a concrete prompt to prioritize hardware refresh timelines.

The broader significance of the FeliCa disclosure is not specific to Sony or Japan. As RFID and contactless hardware from the 2010s decade continues to operate in transit systems, access control infrastructure, and IoT deployments across Asia and beyond, the computing power required to conduct proximity-based cryptographic attacks has decreased substantially, while the hardware itself cannot be updated. CVE-2026-59776 is a case study in what that combination looks like when it finally reaches formal public disclosure — and in what coordinated vulnerability disclosure frameworks need to account for when the vulnerability cannot be fixed with a patch.

Frequently Asked QuestionsDoes the Sony FeliCa vulnerability affect my Suica or PASMO transit card — and do I need a new one?

If you are using a physical Suica, PASMO, ICOCA, or other FeliCa-based transit card that was manufactured before 2017, it is in scope for CVE-2026-59776. All major transit operators — including JR East for Suica, and JR West for ICOCA — have stated their service-level security systems (online verification, anomaly detection, and the ability to blocklist individual cards) mean that transit card holders can continue using their cards. That said, if your physical card is old and you have not yet transitioned to Mobile Suica or Mobile PASMO on a smartphone, doing so removes you entirely from the affected hardware class — Mobile FeliCa is not affected by this flaw.

Can an attacker exploit this flaw without ever touching my card?

The CVSS attack vector for CVE-2026-59776 is classified as Physical (AV:P), meaning the attack requires the attacker to initiate a contactless exchange with your card — not merely be in the same room. The card communicates at a maximum range of 10 centimeters. In practice, this means an attacker would need to bring a reader to close proximity of your card — at a transit gate, in a crowded area, or through a bag. RFID-blocking card sleeves or wallets prevent this entirely. No remote or network-based exploitation of this vulnerability is possible.

If there is no patch, what are operators and businesses doing to protect FeliCa-based access systems?

Service operators have received Sony’s countermeasure guidelines and have been implementing them since late 2025. The countermeasures are system-level: enhanced monitoring of transaction patterns, blocklisting of cards that show signs of compromise, and accelerated replacement cycles for pre-2017 hardware. Operators running building access or employee ID systems on pre-2017 FeliCa cards should consult the Sony FeliCa developer website directly. For organizations with the highest security requirements, the appropriate response is to treat any pre-2017 card as a candidate for replacement rather than monitoring alone.

Why did it take nearly a year between the initial leak and today’s formal JVN advisory?

Japan’s coordinated vulnerability disclosure framework is built around a roughly 45-day window for developers to prepare patches before public advisory publication. This flaw has no patch — it is a hardware design defect in chips that cannot be updated. Instead of a patch, the remediation process required Sony to develop countermeasure guidelines and then coordinate separately with dozens of service operators — transit authorities, payment processors, building access operators, and government agencies — each of whom needed to assess impact, strengthen monitoring, and prepare card replacement workflows for their own user populations. That multi-operator coordination for an unpatched hardware vulnerability is exactly the scenario Japan’s 2004-era disclosure framework was not written to handle, and the eleven-month timeline reflects that structural gap.