Contactless payment cards are widely assumed to stop working past their printed expiration dates,
and many stakeholders rely on this assumption for authorization and access control.
This paper shows that banks enforce the expiration as a transaction policy check, rather than an
intrinsic property of the card, which allows an expired card to still initiate contactless payments.
We demonstrate a practical “Zombie Card” attack that makes an expired card appear unexpired,
allowing successful transactions despite the card being past its printed date.
We evaluate the attack across real-world transaction configurations spanning multiple EMV kernels
(Visa, Mastercard, and Discover), POS terminals, merchants, and five major US banks.
Our results show that Visa contactless transactions are susceptible to man-in-the-middle tampering
due to a lack of effective integrity protection. We further find that banks often rely on the POS
terminal’s decisions and skip critical security checks during transaction authorization for faster
payments. Across our trials, the attack remains operational under typical in-store conditions using
commodity NFC transceivers and does not require specialized hardware. Together, these findings
indicate that the outcome of a “zombie card” transaction is determined by how security responsibility
is divided between terminals, card manufacturers, and issuers, and by how consistently issuers
enforce card lifecycle state. Based on these findings, we propose countermeasures that span kernels,
issuers, and payments to ensure end-to-end transaction integrity and security.
BibTeX
@inproceedings{anwar2026zombie,
title={Zombie Cards Back Online: Reviving Expired Credit Cards for Contactless Payments},
author={Anwar, Raja Hasnain and DeCunha, Gerard and Raza, Muhammad Taqi},
booktitle={USENIX Security 26},
year={2026}
}
Demo Video
A live demonstration of the Zombie Card attack: an expired Visa card completing a $100 contactless transaction at a real POS terminal.
EMV (Europay, Mastercard, Visa) is the global standard governing chip-based card payments.
In a contactless transaction, the card and a Point-of-Sale (POS) terminal exchange
Application Protocol Data Units (APDUs) over NFC. Five parties participate:
Card (Payment Device) — stores the payment application and cryptographic keys in a secure element.
POS Terminal — reads the card over NFC, applies kernel rules, and decides whether to approve locally or escalate online.
Acquirer — the merchant's bank; routes the transaction to the payment network.
Payment Network (Visa, Mastercard, Discover) — defines the kernel specification and routes between acquirer and issuer.
Issuer — the cardholder's bank; ultimately authorizes or declines based on its own risk engine.
Each payment network defines a kernel — the protocol logic the terminal executes.
Kernels differ in which fields they authenticate and how they handle edge cases.
This paper focuses on Kernel 3 (Visa payWave) and compares it against Kernel 2 (Mastercard),
Kernel 4 (AmEx), and Kernel 6 (Discover).
The Expiry Duality: Card expiration appears in two separate fields.
The Application Expiration Date (#5F24) is read by the terminal for its local check.
The expiry embedded in Track 2 Equivalent Data (#57) is forwarded to the issuer in the
online authorization request. These two representations are consumed independently — and Kernel 3
does not require them to be consistently bound end-to-end.
The Zombie Card Attack
The key insight is that in Visa Kernel 3, the terminal’s expiry check is a local policy decision,
not a cryptographic proof from the card. The Application Expiration Date (#5F24) is transmitted
in plaintext over NFC and is excluded from the card’s RSA signature (SDAD). An attacker with an
NFC man-in-the-middle position can rewrite this field without invalidating any cryptographic check
the terminal performs.
Attack Flow
Step 1 — Relay Setup.
The attacker places a CardEmulator phone near the POS terminal and a POSEmulator phone
near the expired card. The two phones relay APDUs over Wi-Fi, creating a transparent NFC
man-in-the-middle using commodity Android devices — no specialized hardware required.
Step 2 — Payload Injection.
During the terminal's READ RECORD phase, the card returns its Application Expiration Date
and Track 2 data in plaintext. The relay intercepts the response and rewrites
#5F24 from the expired date Dexpired to a future date
Dfuture > Dtransaction.
Track 2 (#57) is left untouched — it carries the expired date toward the issuer.
Step 3 — Integrity Checks Bypassed.
Kernel 3 excludes #5F24 from SDAD, so the RSA signature over the card's
dynamic data remains valid. The terminal never learns the real expiry was manipulated.
Additionally, Kernel 3 forwards a TVR of all zeros to the issuer, stripping out any
flag the terminal might have set for "Expired Application."
Step 4 — Certificate Validity Holds.
Per EMV spec, certificate lifetimes may extend beyond the card's printed expiry.
The expired card's PKI certificates are still valid, so Offline Data Authentication (fDDA)
succeeds normally.
Step 5 — Issuer Authorization.
The card computes a valid ARQC using its still-valid issuer master keys. The issuer
receives a valid cryptogram, an active PAN, and a zeroed TVR — indistinguishable from a
legitimate transaction. Issuers that check only whether the account is open (not whether
the specific card instrument is still valid) approve the transaction.
Experimental Setup
We implemented a standard NFC relay on two OnePlus Nord 5 Android phones running a custom
app in two roles: CardEmulator (near the POS terminal) and POSEmulator
(near the expired card). Cards from Visa, Mastercard, Discover, and AmEx issued by five major US
banks were tested, alongside Apple Pay and Google Pay wallets. POS terminals used were SumUp Plus
and SumUp Solo readers, with additional in-the-wild validation at campus retail and grocery merchants.
Each APDU round-trip added 20–50 ms of relay overhead — well within the 500 ms EMV response window.
Experimental setup. (1) SumUp Plus terminal, (2) companion merchant app, (3) SumUp Solo terminal, (4) CardEmulator phone presenting card data to the terminal, (5) victim expired card, (6) POSEmulator phone reading and relaying card APDUs.
Transaction receipt for a $100 contactless payment approved on an expired Visa card ending in 8634, as shown in the video.
FAQ
Click a question to reveal the answer; click again to hide it.
It is an NFC man-in-the-middle attack that rewrites the expiration date a POS terminal reads from an expired card, making the card appear valid so the transaction is approved — without breaking any cryptography.
No. The card's keys, signatures (SDAD), and cryptograms (ARQC) remain valid throughout. The gap is that Visa Kernel 3 does not bind the terminal-read expiration date to any authenticated data, so it can be modified in transit undetected. This is a lifecycle-enforcement gap, not a cryptographic break.
The attack exploits a documented misconception — expired cards are widely assumed inert, so cardholders discard them carelessly. The precondition is improper disposal by a subset of cardholders, not wide availability. Following issuer guidance to physically destroy the card eliminates the precondition entirely.
Visa (Kernel 3) was the susceptible configuration; Mastercard (Kernel 2), AmEx (Kernel 4), and Discover (Kernel 6) rejected the modification. We tested five major US banks (anonymized as Bank A–E). Issuer behavior varied: some approved revived transactions, others declined and prompted for the replacement card.
Digital wallets are more resilient. Their tokens and expiry are refreshed over-the-air by the issuer's token service provider, without cardholder action, reducing the chance that an expired underlying credential stays usable. Centralized lifecycle management is more robust than terminal-local policy checks.
Three: (i) which EMV kernel is in use and whether it cryptographically binds expiry-relevant fields; (ii) whether the issuer authorizes against the (PAN, expiry) tuple or only checks that the PAN is active; and (iii) whether terminal validation results reach the issuer via TVR. Amount, merchant category, and POS brand did not independently determine the outcome.
Prior work targeted PIN/CVM bypass, brand mix-ups, or relay proximity. We instead treat card expiry as an end-to-end lifecycle invariant and show it degrades into a policy-only attribute. The attack requires no induced authentication failure and no brand routing — only an unbound, terminal-consumed expiry field.
Yes. Once the terminal accepts the modified expiry and the issuer does not enforce instrument-level checks, the attack succeeds across all tested amounts ($1, $100, $500). PIN thresholds in European deployments are a separate check, orthogonal to the expiry-integrity gap.
The relay added 20–50 ms per APDU round-trip (~415 ms total) — within the 500 ms EMV response window; no timeouts occurred. RRP would defeat the relay by detecting the added latency and aborting, but RRP is optional and was not deployed on any card or terminal we tested.
The simplest protection is to follow issuer guidance for expired cards: physically destroy them by cutting through the chip and magnetic stripe, or return them through an approved channel. An expired card you have securely destroyed cannot be used in this attack.
IRB approval was not required — no human subjects were involved. Controlled experiments used our own cards and merchant account. In-the-wild merchants were informed in advance and all charges were paid in full. Use of standard EMV cards and commercial terminals falls within normal cardholder use.
The implementation provides a direct capability to modify live financial transactions and could lower the barrier to fraud. As of publication, Visa and affected banks have not confirmed mitigation status. We release sanitized transaction logs and full protocol-level detail — consistent with prior EMV research that withheld exploit-capable artifacts.
Yes — in May 2025 and December 2025, with a step-by-step reproduction guide, full APDU traces, and a video demonstration. Visa's report has passed initial triage and is undergoing reproduction by their red team. As of writing, neither Visa nor the notified banks has provided an update on mitigations.
