A research team at the University of Massachusetts Amherst found that contactless cards can still process transactions after expiration. This happens because the expiration date isn't cryptographically protected in certain transaction flows. The findings were presented at USENIX Security 2026.
This issue isn't just theoretical. In live retail tests, an expired card completed purchases at $2.79 and $3.19 after researchers altered the expiration date using two smartphones and a Wi-Fi relay. The vulnerability exists because each system in the payment chain assumes another component has already validated the card's status.
Why These Mistakes Keep Happening
Payment processing involves terminals, acquiring banks, networks, and issuers. With multiple parties handling a transaction, each optimizes for speed and assumes others handle edge cases. The card checks its cryptographic signature, the terminal reads the date, the network routes the message, and the issuer verifies the account.
No one confirms that the physical card matches the one on file.
This fragmentation creates gaps. A Visa Kernel 3 terminal resets the expired-card indicator field to zeros before sending data to the issuer, effectively hiding the terminal's check result. The issuer sees a valid account number and approves the transaction without knowing the card failed local validation.
Mistake 1: Treating the Expiration Date as Informational
Why it happens: The expiration date is printed on the card and transmitted in transaction data, but in affected Visa contactless flows, it falls outside the data covered by the card's cryptographic signature. Engineers assume the printed date and the account validity window align, treating the date as a display field rather than a security control.
Real consequence: An attacker intercepts the transaction data, overwrites the expiration date with any future value, and the terminal accepts it because the signature still validates. Testing against one major US bank, researchers completed transactions at $1, $100, and $500 using this technique.
The fix: Bind the expiration date to a cryptographic check like Mastercard, American Express, and Discover do. When researchers tested the same relay attack against those networks, each one rejected the altered date because tampering broke the signature. The date must be inside the signed data structure.
Mistake 2: Zeroing Out Terminal Check Results
Why it happens: Visa Kernel 3 includes a field that flags expired cards during terminal validation. Before sending transaction data to the issuer, it resets this field to zeros. This design likely aimed to simplify message formatting or avoid redundant data, assuming the issuer would run its own checks.
Real consequence: The issuer never learns that the terminal's validation failed. It sees a clean transaction request with no indication that the card was flagged locally. One test bank approved every manipulated transaction because it only verified the account existed and the Primary Account Number was active.
The fix: Preserve terminal check results through the entire authorization flow. The issuer needs to see what the terminal found, even if it plans to run independent validation. If the terminal detected an expired card, that signal should reach the issuer as a mandatory field in the authorization request.
Mistake 3: Validating Accounts Instead of Cards
Why it happens: Issuers maintain account-level records, not card-level ones. When an authorization request arrives, the system checks whether the account is open and the PAN is correct. This works for most fraud scenarios because a stolen card still carries a valid PAN tied to an active account. Engineers didn't anticipate attacks using legitimately issued cards that are no longer current.
Real consequence: Both the expired card and its replacement processed transactions on the same account in testing. The issuer confirmed the account was active but didn't verify which physical card should be working. A cardholder who destroys an expired card as instructed still faces exposure if an attacker recovers it.
The fix: Store and verify the current expiration date at the issuer level, not just the account status. When you receive an authorization request, confirm that the expiration date in the transaction matches the date on the currently issued card for that PAN. If they don't align, decline the transaction and flag it for review.
Mistake 4: Extending Certificate Validity Beyond Card Life
Why it happens: Cards carry a digital certificate that secures communication between the card chip and the issuer. To avoid disruption during card renewals, issuers set certificate expiration dates well past the printed card date. This prevents a gap where a replacement card arrives but the old certificate hasn't expired yet.
Real consequence: Even when the printed date passes and the terminal's local check would fail, the underlying certificate remains valid. Combined with the other vulnerabilities, this extended validity window gives attackers more time to exploit recovered expired cards.
The fix: Align certificate validity with card validity, or implement certificate revocation when you issue a replacement. If you must maintain overlap for operational reasons, add an explicit card-instance identifier to the certificate and verify it during authorization.
Mistake 5: Assuming Cardholders Destroy Expired Cards
Why it happens: Issuers include destruction instructions with replacement cards, assuming compliance eliminates the risk. Engineers design systems for the intended use case, a cardholder who follows instructions, not the actual behavior pattern where expired cards end up in drawers, wallets, or trash bins.
Real consequence: Researchers noted that cardholders routinely underestimate this risk because they assume expired cards stop working. An expired card in a coffee shop trash can or a stolen wallet becomes an active attack vector if the underlying systems don't enforce expiration cryptographically.
The fix: Design the system to fail safely even when cardholders don't follow instructions. Cryptographic enforcement and issuer-level validation make destruction a defense-in-depth measure rather than the primary control. You can't rely on user behavior for security, the card itself must become inert after expiration.
Prevention Checklist
For payment networks:
- Include expiration date within cryptographically signed transaction data
- Preserve terminal validation results through the authorization chain
- Require issuers to verify card-instance details, not just account status
For issuing banks:
- Store current expiration date for each PAN in authorization systems
- Decline transactions when presented expiration doesn't match issued card
- Align certificate validity periods with physical card expiration dates
- Implement certificate revocation when issuing replacement cards
For terminal operators:
- Verify that expired-card flags reach the issuer in authorization requests
- Monitor for authorization approvals on locally failed validation checks
- Flag discrepancies between terminal and issuer decisions for investigation
For cardholders:
- Destroy expired cards by cutting through the chip and magnetic stripe
- Monitor closed and expired account statements for unauthorized activity
- Report unexpected refunds or credits that might indicate card misuse
The researchers disclosed their findings to Visa and affected banks in May and December 2025, including reproduction guides and transaction records. No CVE had been assigned by publication, and neither Visa nor the banks had confirmed a fix.
