Zombie Card Attack Revives Expired Credit Cards for Contactless Payments

Expired credit cards still paid at the checkout. Researchers spent $500 on one, then $2.79 in a shop. The cards had already been handed in for a replacement, and the account behind them stayed open.

A payment card sells one promise on its front. The date printed there is the day the card stops working. Shops rely on it, banks rely on it, and you rely on it when you drop an old card in a drawer instead of destroying it. Researchers at the University of Massachusetts Amherst took that promise apart. Their finding is that the date is not a property of the card at all. The date is a policy, checked in different places by parties that never compare notes, and a card that is past it can still pay.

To see how, you need one idea about how a contactless payment runs.

When you hold your card against a terminal, the terminal asks the card for its data. The card answers with its account number, its expiration date and a handful of other fields. The terminal reads that date, compares it with today, and decides whether to carry on. Expired card, and it declines on the spot. That comparison is the only thing standing between an old card and a payment.

The date it compares is sent in plain text, and nothing binds it to anything else.

That would be survivable if there were one copy. There are two. The first is the field the terminal reads for its check, tag 5F24. The second sits inside the block of account data that travels on to your bank when the payment goes online for approval, tag 57. The terminal looks at the first, your bank looks at the second, and the Visa version of the contactless standard does not require the two to match.

This is what the card sends back, straight from the paper:

1
2
3
4
5
6
7

→ 00 B2 01 0C 00
← 70 2A
   5A 08 4761739001010010
   5F24 03 240831
   5F34 01 01
   57 13 4761739001010010D24082211234567890F
   90 00

The value 240831 in tag 5F24 is the 31st of August 2024. Inside tag 57, after the account number, the same date appears again in a different form. Change the first one to a date in the future, leave the second one untouched, and the terminal accepts a card that has expired while the bank receives account data that looks entirely normal.

The obvious question is why the card’s cryptography does not stop this, because a payment card does sign transaction data, and changing signed data breaks the signature. The expiration date is not part of what it signs.

The keys do not expire either. A card carries certificates with their own validity dates, and the specification only says a card must not outlive its bank’s certificate. It never says the certificate has to die with the card, and banks issue certificates that run past the card date on purpose, so replacements can overlap. An expired card can still prove itself, still sign correctly, still produce a valid cryptogram. On the inside, nothing about it has expired.

That leaves your bank as the last line of defence, and the standard closes that door itself. During a transaction the terminal keeps a five-byte status register where it records how its checks came out, and when it decides a card has expired it sets a bit in that register. Section B.1.1 of the Visa kernel specification then instructs the terminal to send that register to the bank filled with zeros.

The terminal noticed. The bank was never told.

What reaches the bank is a valid cryptogram, an account number that is still active, and a report saying nothing went wrong. From there it comes down to how each bank checks. Some validate the account: does this number exist, is it open, approve. Others validate the card: is this specific card, with this specific date, the one we currently consider valid. Five major US banks were tested and they did not agree with each other.

One approved it all. On the researchers’ own terminal an expired card that had already been handed back paid $1.00, then $100.00, then $500.00. Out of the lab it paid $2.79 in a shop and $3.19 in a grocery store, on ordinary commercial terminals with nothing to do with their setup. The card in their photograph ends in 8634.

A second bank let it reach the network and then declined, and emailed the cardholder to use the replacement card instead. Same attack, same standard, opposite answer, because that decision is left entirely to the bank.

The other card networks refused, and how each one refuses is the part that matters, because it shows this was avoidable:

• → Mastercard compares the two expiry fields against each other and treats a mismatch as a card data error
• → American Express includes the date in the data its cards sign, so any edit breaks the signature
• → Discover puts all transaction data under a single hash and verifies it at the end

Three ways of doing it right, inside the same standard. The split has a name in the specifications. Visa’s kernel uses fast Dynamic Data Authentication, which leaves the expiration date outside the data the card signs. Discover’s kernel uses Combined Dynamic Data Authentication, where the card signs a hash covering the fields the terminal received, so a rewritten date no longer matches. Wallet apps came through untouched as well, because a wallet has its expiry refreshed over the air and hands the decision to the bank by default. The gap is not in the mathematics of card payments. It sits in one configuration that chose speed over checking.

The equipment is two ordinary Android phones running software the researchers wrote themselves. One lies near the terminal and presents itself as your card. The other lies near your card and presents itself as a terminal. They talk over WiFi, and what your card says passes through both of them on the way to the checkout.

That detour costs time, and time is what should have caught it. Each exchange took 20 milliseconds longer, or 50 when a field was being rewritten, and a full transaction averaged around 415 milliseconds. The standard allows 500 milliseconds per command before a terminal gives up. Not one transaction timed out. There is a defence built for exactly this, a Relay Resistance Protocol where the terminal times how long the card takes to answer and stops if it comes back too late. The protocol is not mandatory, and not one card and not one terminal in the testbed had it running.

Then there is card number 4, which the news reports left out.

That card had not expired. The bank replaced it early and automatically, because it had under three months of validity left, and the new card arrived in the post. Both cards kept paying from the same account, without a relay and without a single rewritten field. Replaced is a status that lives in the bank’s systems, it does not exist anywhere on the card, and nothing in the payment standard says what that status has to do during approval. The attack exposes the gap. This one is sitting open on its own.

The work is by Raja Hasnain Anwar and two colleagues, presented at the USENIX Security Symposium in Baltimore this August, and they call it the Zombie Card attack. This is the second time the same lead author has taken payment security apart at that conference. In 2024 he showed that a bank card someone had locked and reported stolen kept paying through a digital wallet, because the bank never revoked the token it had handed out. Back then the physical card was the safe half of the story. This time the card itself is the problem.

They reported it to the card network and the affected banks in May 2025, with a step-by-step reproduction guide, full transaction traces and a video of the bypass, and followed up in December 2025. By the time the paper was accepted the report had passed triage and the network’s red team was reproducing it. Neither the network nor any of the banks has said whether anything was fixed, and no CVE has been assigned. They ran the tests on their own cards, told shop staff in advance, kept it to two transactions per shop, bought goods and paid for it. They also published their raw material: ten sanitized transaction logs on Zenodo, under an open licence, so other researchers can walk through the captures themselves. The relay software they held back, because that code would work in someone else’s hands tomorrow.

So who is exposed, and what do you do about it.

The card at risk is one that expired or was replaced while the account behind it stayed open, which is how card renewal normally works. The account number usually stays the same and only the date changes. If that old card is in a drawer, in a bin, or in a bag someone else can reach, that card still works.

What to do:

• → Cut an expired card through the chip and through the magnetic stripe, not once across the middle
• → Do not hand an old card to a shop, a stall or a recycling bin without destroying it first
• → Keep reading your statements after a card expires or is replaced, because the account outlives the plastic

Beneath the rest, this is a lifecycle failure, not a cryptography failure. The signatures held. The cryptograms held. What broke is that four parties each hold a piece of the answer to one question, whether this card is still valid, and none of them is required to ask the others. A card is only as dead as the system that retires it.

This attack came down to sitting between two devices and rewriting what one of them saw. My ethical hacking course puts you in that position yourself, step by step, on your own lab network.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

USENIX Security 2026: Zombie Cards Back Online | Transaction logs on Zenodo | Khwarizmi Lab project page