Durante el intercambio, el intermediario modificaba la fecha de vencimiento que se enviaba al terminal. Una fecha pasada podía reemplazarse por cualquier fecha futura, de modo que las comprobaciones locales del terminal trataran la tarjeta como vigente. El ataque requería tener la tarjeta física o mantenerla lo bastante cerca del dispositivo NFC que se comunicaba con ella, además del sistema de retransmisión entre la tarjeta y el terminal.
La cuenta asociada también debía seguir abierta y ser apta para una autorización. El ataque no convierte una cuenta cerrada o inválida en una cuenta activa.
El problema señalado se relaciona con el tratamiento de la fecha de vencimiento en la implementación de pagos sin contacto Visa EMV Kernel 3. En la configuración analizada, la fecha mostrada al terminal no estaba vinculada criptográficamente con suficiente solidez a los datos de la tarjeta y a la información de la transacción utilizada posteriormente para la autorización en línea.
El flujo podía producir así una discrepancia:
Por tanto, el ataque no rompía la criptografía de EMV ni fabricaba una firma válida desde cero. Explotaba que un campo relevante para la decisión —la fecha de vencimiento— podía alterarse sin invalidar el resto de los datos autenticados.
Es habitual pensar que la fecha impresa en la tarjeta funciona como un apagado criptográfico automático. Sin embargo, la investigación disponible indica que, en algunos sistemas sin contacto, la caducidad se aplica como una comprobación de cumplimiento durante el procesamiento de la transacción, y no necesariamente como una propiedad criptográfica intrínseca que inutilice la tarjeta.
Si el terminal recibe una fecha futura y el emisor obtiene pruebas de transacción que, por lo demás, son auténticas, el sistema puede no contar con una señal fiable y autenticada que demuestre que la tarjeta física ya caducó. La autorización seguirá dependiendo de otros factores, como el estado de la cuenta y los controles del emisor.
Los informes proporcionados indican que la sustitución de la fecha no tuvo éxito en las configuraciones probadas de Mastercard Kernel 2, American Express Kernel 4 y Discover Kernel 6.
No obstante, las fuentes disponibles no ofrecen un análisis técnico completo, kernel por kernel, que explique exactamente qué vinculaciones de campos o validaciones hicieron que esas operaciones fueran rechazadas. La conclusión prudente es que esas implementaciones probadas resistieron mejor esta manipulación concreta que la configuración de Visa analizada.
Eso no significa que todas las tarjetas de esas marcas sean inmunes a cualquier ataque de retransmisión o a otros tipos de fraude. La resistencia depende de la implementación, la tarjeta, el terminal, el emisor y las condiciones de la operación.
La investigación habría incluido tarjetas de varios bancos importantes de Estados Unidos y pruebas con distintos emisores.
Sin embargo, el material disponible no identifica de forma verificable los cinco bancos ni proporciona un resultado confirmado de aprobación o rechazo para cada uno. Por eso no es responsable publicar una tabla banco por banco ni afirmar que un emisor aceptó o bloqueó universalmente el ataque.
El resultado puede variar según el producto de tarjeta, el estado de la cuenta, los controles de autorización, el terminal, el adquirente y las características concretas de cada transacción.
Un informe señala que los investigadores comunicaron los hallazgos a Visa y a bancos afectados en mayo y diciembre de 2025. La información compartida habría incluido material para reproducir el problema, registros de transacciones y un vídeo de demostración.
Las fuentes suministradas no incluyen una respuesta verificable de Visa, un aviso de seguridad confirmado ni pruebas de que se haya completado el despliegue de una solución. Por tanto, no hay evidencia suficiente para afirmar que el problema esté completamente corregido, qué tarjetas o terminales estarían cubiertos o si existe una mitigación obligatoria para todo el ecosistema de pagos.
La solución central es impedir que la fecha que ve el terminal difiera de la información autenticada de la tarjeta.
Primero hay que seguir las instrucciones del banco o emisor, especialmente si solicita devolver la tarjeta antigua. Si permite destruirla, conviene:
Estas medidas reducen el riesgo de exposición de los datos impresos, pero no sustituyen la supervisión de la cuenta ni la obligación de avisar al emisor ante cualquier cargo desconocido.