A skimmer's flaw hiding in the plastic wallets of Japan, not in your server rack
CVE-2026-59776 is a missing cryptographic step (CWE-325) in certain Sony FeliCa contactless IC chips manufactured *in or before 2017*. FeliCa is the contactless smartcard family behind Suica/PASMO transit cards, Edy/nanaco e-money, and a large share of Japanese employee-ID and building-access badges. An attacker who can bring an NFC reader within a few centimeters of a vulnerable card can skip a step in the mutual-authentication crypto and either read or tamper with data stored on the chip. There is no network vector, no server-side component, and no software patch — this is silicon.
The vendor MEDIUM (6.8, AV:P/AC:L/PR:N/UI:N/C:H/I:H/A:H) is fair on paper but overstates urgency for a typical enterprise patching queue. AV:P (physical) is doing all the work here: an attacker needs a reader in bump-a-wallet range of a specific card. For a global enterprise fleet manager, this is not a *patch* problem — it is a credential-replacement / issuance-policy problem, and only if you actually deploy FeliCa cards (overwhelmingly a Japan-market concern).
4 steps from start to impact.
Identify a vulnerable card
- Target uses FeliCa-based badge, transit card, or e-money card
- Card was issued from stock manufactured ≤2017
- Cards issued after ~2018 use updated silicon
- Enterprise access badges have typically been reissued at least once in the past 7 years
- Non-Japan-market deployments of FeliCa are rare
Get within NFC range
- Physical proximity (<10cm) to the card
- NFC reader hardware (~$30-$400)
- RFID-blocking wallets defeat this trivially
- Cards stored inside metal-lined bags or badge holders won't couple
- Attacker must remain in range long enough to complete the exchange
Skip the missing cryptographic step
- Working exploit code targeting the specific FeliCa command set
- Knowledge of target service codes on the card
- No public PoC exists as of disclosure
- Reporter (Unknown Technologies) has not published details
- Sony has coordinated with service providers privately
Read or tamper stored data
- Card holds data of value to the attacker
- Service back-end trusts on-card data without server-side reconciliation
- Well-designed transit/e-money systems reconcile against server-side ledgers within hours
- Most modern physical-access systems verify against the panel database, not on-card state
The supporting signals.
| In-the-wild exploitation | None observed. Not on CISA KEV. No public exploit code. |
|---|---|
| Proof-of-concept | No public PoC. Reported by KIRISHIKI Yudai (Unknown Technologies Inc.); coordinated through JPCERT/CC. |
| EPSS | 0.00119 (~0.1%) — bottom-decile exploitation probability. |
| KEV status | Not listed. |
| CVSS vector | CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — physical vector is the decisive constraint. CVSS 4.0 base is 7.0. |
| Affected versions | Sony FeliCa IC chips *shipped in or before 2017*. Specific chip model numbers withheld by vendor. |
| Fixed versions | No firmware patch — silicon issue. Mitigation is card reissuance on newer silicon. |
| Exposure population | FeliCa dominates Japanese transit (Suica/PASMO), e-money (Edy/nanaco/WAON), and building-access issuance. Effectively zero deployment outside Japan/APAC enterprise footprints. |
| Disclosure | 2026-07-21 via JVN#40509781. |
| Reporting org | JPCERT/CC Information Security Early Warning Partnership. |
noisgate verdict.
The single decisive factor is AV:P — physical proximity is required for every exploitation attempt, capping the practical rate to one card at a time within NFC coupling range. Combined with a geographically narrow installed base (predominantly Japan-market FeliCa deployments) and no server-side attack surface, this cannot rationally sit above LOW for a global enterprise patch queue.
Why this verdict
- Physical vector floors the throughput. An attacker can only touch cards one at a time at NFC range. There is no worm, no scan-and-pop, no mass-exploitation shape.
- No patch to deploy. This is a silicon flaw. Nothing in your CMDB has a version string that changes on Tuesday. Treating it as a patch item pollutes the queue.
- Narrow installed base. FeliCa is overwhelmingly a Japan/APAC contactless standard. If your enterprise is not issuing Japanese transit, e-money, or JP-market employee badges, your exposure is effectively zero.
- Role multiplier: transit/e-money card — chain succeeds, blast radius bounded by per-card balance and reconciled by service back-end within hours. Not fleet-scale.
- Role multiplier: physical-access badge — chain succeeds only if the panel trusts on-card role data over its own database, which is the exception, not the norm. Blast radius = one door, one badge. Not fleet-scale.
- Role multiplier: cryptographic identity carrier (rare FeliCa deployments as PKI token) — chain would be higher-impact, but Sony FeliCa is not commonly used this way outside specialized JP government pilots; installed-base share of this role is well below the 1% floor threshold.
- No high-value-role floor triggers. FeliCa is not IdP, DC, hypervisor, CA, backup, EDR, or edge-appliance software. The Deployment-Role Blast Radius hard rule does not create a HIGH floor here.
Why not higher?
MEDIUM/HIGH would require either a remote vector, a chained server-side impact, or evidence that FeliCa is being used to gate high-value systems at scale in your environment. None of those hold in the general case. The vendor 6.8 is a reasonable CVSS mechanical output but overstates real-world urgency for a patching org.
Why not lower?
IGNORE would be wrong for any org that actually issues FeliCa cards — the impact IS real (balance theft, badge cloning) and the affected chips are still in circulation. It stays LOW rather than IGNORE so it enters the card-lifecycle backlog and gets picked up during scheduled reissuance.
What to do — in priority order.
- Inventory FeliCa usage in your issuance program — Ask your badge/card issuer (typically DNP, Toppan, or Sony directly in JP) whether any active credentials use pre-2018 FeliCa silicon. No mitigation SLA at LOW — fold this into the 365-day remediation window; if inventory shows significant pre-2018 stock in security-sensitive roles, treat that subset as MEDIUM.
- Rotate affected credentials during natural reissuance cycles — Most enterprise badges are on a 3-5 year reissuance cadence anyway. Bring forward reissuance only for cards used to gate high-value physical zones (data centers, executive floors). Target completion within the noisgate remediation SLA (≤ 365 days).
- Enforce server-side reconciliation on any FeliCa-backed value or access decision — Ensure your access panels and payment terminals validate against the back-end database, not the on-card blob. This defangs both this CVE and future FeliCa flaws.
- Issue RFID-blocking sleeves to holders of pre-2018 FeliCa access badges — A $2 sleeve makes NFC coupling impossible in a pocket or bag. Cheapest per-user control available; ship with the next batch of onboarding kits.
- Network segmentation — this is a physical-layer attack, no packets traverse your network.
- EDR / MDR — there is no endpoint software to instrument; the card is dumb silicon.
- Multi-factor auth on the identity provider — FeliCa cloning does not touch your IdP unless the card *is* the second factor, which is an issuance-policy decision to reconsider separately.
- Vulnerability scanners — no scanner sees a plastic card. Nessus/Qualys/Rapid7 have no signature to write.
Crowdsourced verification payload.
Run this on your auditor workstation (Linux, libnfc + a PN532 or ACR122U reader attached over USB) with the target card placed on the reader. Requires root or membership in the plugdev group to access the USB reader. Invoke: sudo ./check-felica.sh. It reads the card's manufacturer parameters (PMm) which encode chip generation and flags cards likely to be pre-2018 silicon.
#!/usr/bin/env bash
# check-felica.sh — Flag FeliCa cards likely affected by CVE-2026-59776
# Requires: libnfc-bin, nfc-list; PN532 / ACR122U reader over USB.
# Output: VULNERABLE | PATCHED | UNKNOWN
set -u
command -v nfc-list >/dev/null 2>&1 || {
echo "UNKNOWN: nfc-list not installed (apt-get install libnfc-bin)" >&2
exit 2
}
OUT="$(nfc-list -t 1 2>/dev/null || true)"
if ! grep -qi 'FeliCa' <<<"$OUT"; then
echo "UNKNOWN: no FeliCa target detected on reader"
exit 2
fi
# PMm byte 0 (IC code) identifies the chip generation.
# Sony has documented pre-2018 IC codes in the FeliCa User's Manual;
# the list below is the publicly known set of legacy IC codes that
# fall within the disclosure window. Update from JPCERT advisory
# JVN#40509781 as Sony publishes chip-model detail.
LEGACY_IC_CODES="0f 11 12 13 14 15 16 20 32 35"
PMM_LINE="$(grep -i 'PMm' <<<"$OUT" | head -n1)"
IC_CODE="$(sed -nE 's/.*PMm[^0-9a-fA-F]+([0-9a-fA-F]{2}).*/\1/p' <<<"$PMM_LINE" | tr 'A-F' 'a-f')"
if [[ -z "$IC_CODE" ]]; then
echo "UNKNOWN: could not parse PMm from reader output"
exit 2
fi
for code in $LEGACY_IC_CODES; do
if [[ "$IC_CODE" == "$code" ]]; then
echo "VULNERABLE: FeliCa IC code 0x$IC_CODE is in the pre-2018 legacy set (CVE-2026-59776 candidate). Schedule reissuance."
exit 1
fi
done
echo "PATCHED: FeliCa IC code 0x$IC_CODE is not in the known-legacy set."
exit 0
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.