In the appendix of a paper presented this month sits a photograph of an ordinary Visa credit card. The print on the front reads "Valid Thru: 08/24". Roughly a year after that date, that same card paid for $3.19 of groceries at a checkout, and $2.79 at a retail merchant, and nobody at either till noticed anything unusual.
It should not have worked. That is the finding.
Raja Hasnain Anwar, Gerard DeCunha and Muhammad Taqi Raza of the University of Massachusetts Amherst presented Zombie Cards Back Online at the 35th USENIX Security Symposium in Baltimore. They did not break Visa's cryptography, and they are careful to say so. They broke an assumption almost everyone holds, including the banks: that a payment card stops working when the date printed on the front has passed.
Expiry is a rule, not a fact
A contactless card does not refuse to pay after its expiry date. It has no idea what the date is. What actually happens is that the payment terminal reads a date out of the card, compares it to today, and decides. The researchers call this out plainly: expiry is enforced as a transaction policy check rather than an intrinsic property of the card.
Worse, the date exists twice. It is carried once as a standalone Application Expiration Date object, and again inside Track 2 Equivalent Data, the field that gets forwarded to the bank for authorization. The two copies are consumed at different moments by different parties, and Visa's contactless kernel does not require them to agree. The team names this Expiry Duality, and it is the crack everything else falls through.
The whole attack, at the byte level. Diagram by IntelFusions, built from the researchers' released capture (CC BY 4.0).
Two characters, and the card is alive
The researchers published their relay captures as an open dataset, and we read them. This is the part no summary of this work has shown, because it is sitting in a 3 MB Android log rather than in the paper.
In the successful transaction against the bank the paper calls Bank A, the relay intercepts the card's answer to a single command, GET PROCESSING OPTIONS. That answer is 89 bytes long. Exactly two hex digits are different by the time the terminal sees it.
The first sits inside Track 2, where the expiry field reads 2408. It becomes 2508. August 2024 becomes August 2025, and the card is no longer expired. The second sits in the Card Transaction Qualifiers, where 0000 becomes 0080, setting the bit that means the cardholder already verified themselves on their own device. To the terminal, the payment now looks like somebody tapping a phone after a fingerprint check.
Every other byte is untouched. The card's own signature still verifies, because neither field was ever covered by it.
The certificates outlive the card
This is where the design gives way rather than the maths. The terminal does check certificates during offline authentication, and those certificates are genuinely valid. Banks routinely issue them to run past the card's printed expiry so that reissues overlap cleanly. The card's cryptographic keys encode no notion of expiry at all, because expiry was never an architectural property. So an expired card produces perfectly good cryptographic evidence, and the terminal accepts it, exactly as designed.
The terminal tells the bank nothing
The bank could still catch this. It does not, for two reasons the paper documents carefully.
First, the terminal keeps a register of everything it checked, including a specific bit for "expired application". Visa's kernel specifies that this register is forwarded to the issuer set to all zeros. The one channel by which a bank could learn what the terminal actually saw is defined to carry nothing.
Second, the issuer then approves against the account rather than the card. If the account number exists and the account is open, the transaction goes through. It is not checking whether this particular piece of plastic is still the live one. The bank sees an active account and a transaction that passed every terminal check, and says yes.
The same edit, four different answers. Diagram by IntelFusions.
Three networks said no
What makes this a design choice rather than an inevitability is that the other networks refused. Mastercard's kernel compares the two copies of the expiry and treats a mismatch as a card data error. American Express signs the expiry field as part of offline authentication, so editing it breaks the signature. Discover hashes the records it read after it has read them, so a rewritten value no longer matches. In the team's testing, all three declined.
The same relay, the same edit, and only the Visa path went through. The researchers also found the terminal at one Visa bank accepted the modified card while that bank's own authorization system declined it and emailed the cardholder to say the card had expired and to use the new one. The second line of defense worked there. At another bank it did not.
The card they replaced still worked
One result deserves more attention than it has had. The team also tested a card that had not expired but had been automatically replaced by the bank a few months early. The reasonable expectation is that issuing a replacement kills the old card. Both the old card and its replacement completed transactions against the same account.
Replacement, it turns out, is a state the bank holds in its own systems. It is not necessarily a state the card knows about, and it is not something the protocol at the terminal is required to enforce.
Fifteen months, and no answer
The researchers disclosed to Visa and the affected banks in May 2025 and made contact again in December 2025. Their report included a step by step reproduction guide, full protocol traces and a video of the authorization bypass. Visa's report passed initial triage and went to their red team for reproduction. As of the paper's acceptance, the authors write that neither Visa nor any notified bank had provided an update on the status or nature of mitigations. On the project page the team notes that no CVE has been assigned.
They also drew a line on what to release. The transaction logs are public under an open licence. The relay application is not, and they say plainly why: it would be a reusable capability for modifying live NFC payments, and remediation has not landed.
What would actually fix it
EMV already contains a defense. The Relay Resistance Protocol times the card's responses and rejects anything too slow, which is precisely what a relay introduces. The researchers measured their own relay adding about 415 ms per transaction against a 500 ms allowance. Not one card or terminal in their testbed implemented the protocol.
Beyond that, the fixes are unglamorous and structural. Bind the expiry to something the terminal verifies. Make the two copies agree before anything else happens. Have issuers authorize against the account number and the expiry date together rather than the account number alone, so an obsolete card stops working the moment a replacement is issued. Preserve the terminal's validation results instead of forwarding zeros.
For anyone holding a dead card, the practical advice is duller and still worth repeating: destroy the chip as well as the magnetic stripe, because the chip is the part that still answers. An expired card in a drawer is not inert. It is a working credential with a misleading label, and as the criminal NFC relay kits we covered in fake bank calls that turn one card tap into instant fraud show, the hardware to talk to it is no longer exotic.
The uncomfortable part of this research is not the trick. It is what the trick reveals: that the date on the front of your card is a label, that the systems meant to honour it each assumed somebody else was checking, and that fifteen months after being told, the answer is still pending.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.