As reported by The Hacker News, researchers at the University of Massachusetts Amherst have disclosed a contactless payment attack dubbed "Zombie Card" that revives expired Visa cards for in-store transactions without defeating any cryptographic control on the card itself. The findings were presented at the 35th USENIX Security Symposium in Baltimore on August 12–14, 2026.

Security Impact: As reported by The Hacker News, researchers at the University of Massachusetts Amherst have disclosed a contactless payment attack dubbed "Zombie Card" that revives expired Visa cards for in-store transactions without defeating any cryptographic control on the card itself.

What makes this finding significant is not the attack's practicality — it requires physical possession of or sustained NFC proximity to an expired card plus an active relay device — but the architectural insight it exposes. Visa's Kernel 3 specification does not require the Application Expiration Date (TLV tag 5F24), which the terminal checks against its processing restrictions, to be cryptographically bound to the Track 2 Equivalent Data (tag 57) that the issuer evaluates during online authorization. The fast Dynamic Data Authentication (fDDA) signature verified by the terminal excludes tag 5F24 entirely. A relay can rewrite the terminal-facing date to a future value while leaving Track 2 and the card's cryptogram untouched, so every cryptographic check still passes — yet the terminal never blocks the expired card.

Why This Matters Beyond Visa

This is a specification-level design gap, not an implementation bug in a single terminal or issuer. Any terminal running Visa Kernel 3 that relies on tag 5F24 for expiry enforcement is affected. The researchers tested across five major US banks; one approved revived transactions, one declined them, and a third ran a different EMV kernel on which the modification failed. That variance is telling — it means issuer-side authorization logic is the de facto backstop, yet at least one major issuer's configuration does not independently re-verify expiry during authorization. The attack surface widens considerably when you consider that card replacement under the same PAN is standard practice at most issuers, meaning the pool of "expired but still open" accounts is continuously replenished.

AttributeDetail
Attack NameZombie Card
TargetVisa contactless (Kernel 3) EMV transactions
Root CauseTag 5F24 (Application Expiration Date) not cryptographically bound to Track 2 data or covered by fDDA signature
CVENone assigned as of August 20, 2026
SeverityMedium — requires physical card access or sustained NFC proximity plus relay hardware
Active ExploitationNone reported
DisclosureMay 2025 to Visa and affected banks; re-contacted December 2025
Patch / MitigationNone published by Visa, EMVCo, or terminal vendors as of August 20, 2026

Who Is Most at Risk

  • Issuers whose authorization host does not independently validate card expiry against the PAN during online authorization — the one bank that approved revived transactions falls here.
    • >
  • Merchants running Visa Kernel 3 terminals in unattended or semi-attended environments (self-checkout, fuel pumps, transit gates) where a relay device can operate without cashier scrutiny.
    • >
  • Cardholders who discard expired cards without shredding or who leave them accessible in wallets, desk drawers, or glove compartments — the relay needs only sustained NFC proximity, not theft.
The critical takeaway: EMV's cryptographic guarantees protect transaction integrity and card authenticity, but they do not uniformly protect every data element the terminal uses for business-logic decisions. Any TLV field excluded from the fDDA signature scope is a candidate for relay modification if the issuer does not enforce consistency server-side.

Shield53 Recommendations

Immediate Actions

Shield53 Recommendations
Issuers: Audit your authorization host logic now. Confirm that every online authorization request independently validates card expiry derived from Track 2 (tag 57) against the PAN's current status — not the terminal-supplied tag 5F24. If your host trusts the terminal-facing expiry without re-derivation, you are exposed regardless of kernel version.
Issuers: Consider closing the PAN or flagging it for decline-by-default when a card reaches expiry and has not been activated as a replacement, rather than leaving the account open indefinitely.
Acquirers and terminal integrators: Until EMVCo publishes a specification fix, implement a terminal-side heuristic: compare tag 5F24 against the terminal's own RTC date and decline contactless transactions where the card expiry is implausiously far in the future (e.g., more than 10 years ahead). This is a partial control — a relay can set any future date — but it catches unsophisticated implementations.
Merchants: In unattended environments, inspect for relay devices during routine maintenance. A Zombie Card relay must sit between the card and the terminal's NFC field, making it more detectable in controlled physical spaces than in open retail.
Cardholders: Shred or mechanically destroy expired cards. Do not assume an expired card is inert — under this attack model, physical access to the card is the primary enabler.

Broader Implications

Fifteen months have passed since initial disclosure with no published advisory, specification update, or CVE. This gap is concerning for a payment-ecosystem flaw, even one with significant physical-access preconditions. EMVCo's multi-stakeholder specification process is slow by design, but the absence of interim issuer guidance is a missed opportunity. The research also raises a broader question for EMV architecture: how many other TLV fields consumed by terminal business logic sit outside the fDDA signature scope? A systematic audit of tag coverage across all EMV kernels — Visa 2 and 3, Mastercard, Amex, Discover, JCB — would be a valuable contribution. The Zombie Card technique is specific to expiry today, but the class of "unsigned TLV relay modification" attacks may not be.