¿Por qué se rechazaron todas las tarjetas Revolut el 20 de octubre de 2026? La caída explicada

Si tu tarjeta Revolut fue rechazada esta mañana, en una caja, un surtidor de combustible o un cajero automático, el problema no era la tarjeta y tampoco eras tú. En la mañana del martes 20 de octubre de 2026, Revolut sufrió una caída general de la compañía. Los pagos con tarjeta, las transferencias, las retiradas en cajeros e incluso el inicio de sesión en la aplicación fallaron para los clientes de Reino Unido, Francia, España, Alemania y Grecia, además de Irlanda. Revolut confirmó una interrupción del servicio que afectaba a múltiples servicios y afirmó que el dinero y los datos de todos los clientes están a salvo. El desencadenante más probable es un fallo de Google Cloud en su región de Londres que comenzó a las 06:08 UTC, es decir, las 08:08 en París, y que Google ha atribuido desde entonces a un incidente de suministro eléctrico. Una persona conocedora del asunto declaró a Reuters que la caída de Revolut estaba relacionada con la interrupción de Google Cloud. Ninguna de las dos empresas ha confirmado públicamente ese vínculo.

La cobertura en directo te dice que Revolut está caído. No te dice en qué punto de la cadena de pago está el fallo, por qué un surtidor sin personal rechaza tu tarjeta incluso cuando una caja a veces la acepta, ni cómo una sola región de nube en Londres puede parar una tarjeta en una gasolinera francesa. Este artículo responde a esas preguntas, separa la caída de los recientes ataques a los centros de datos rusos y de un fallo de máquinas virtuales de Linux recién divulgado, y enumera qué llevar encima para que la caída de un único emisor no vuelva a dejarte tirado.

¿Por qué fue rechazada mi tarjeta Revolut el 20 de octubre?

Porque Revolut, la empresa que aprueba cada pago realizado con sus tarjetas, no pudo responder durante varias horas. A partir de las 08:00, hora de París, aproximadamente, informa Clubic, la aplicación mostraba un mensaje de error, las tarjetas eran rechazadas en tiendas y taxis, y las transferencias fallaban. Revolut tiene más de 8 millones de clientes solo en Francia. La prensa tecnológica francesa informó de rechazos en cajas y en cajeros automáticos.

La propia página de estado de Revolut tardó en reaccionar. A las 09:42, hora de París, todavía mostraba todos los sistemas operativos; más tarde llegó a listar 31 servicios como parcialmente no disponibles, incluidos los pagos con tarjeta, las transferencias, las retiradas en cajeros, los servicios premium y el inicio de sesión. Así transcurrió la mañana.

A las 13:25, hora de París, del 20 de octubre, Google atribuye la caída a un incidente de suministro eléctrico en la zona europe-west2-b, afirma que el incidente de suministro eléctrico está mitigado y que los servicios se están restableciendo progresivamente, pero su incidente sigue abierto y su informe completo del incidente no se ha publicado. Revolut no ha emitido ningún aviso de recuperación ni ha nombrado una causa. Actualizaremos este artículo cuando Revolut o Google publiquen un análisis del incidente.

¿Fue Revolut, Visa o la tienda?

Todo pago con tarjeta implica a tres partes. El terminal de la tienda y su banco (el adquirente) capturan la tarjeta y envían una solicitud de autorización. La red de tarjetas, Visa, Mastercard o CB en Francia, encamina esa solicitud. El emisor, el banco que está detrás de tu tarjeta, responde sí o no en tiempo real. El 20 de octubre no encontramos ningún incidente comunicado por Visa, Mastercard o CB, y ningún otro emisor de tarjetas informó de problemas con sus tarjetas, lo que, según todas las evidencias, sitúa el fallo en Revolut como emisor de la tarjeta.

Una caída del emisor se produce cuando el banco que está detrás de tu tarjeta no puede responder a la solicitud de aprobación de la red de pagos, de modo que todos los terminales rechazan la tarjeta a la vez, sea cual sea la tienda y sea cual sea el país. Por eso el patrón parecía tan extraño desde fuera: la tarjeta fallaba en todas partes al mismo tiempo, mientras la persona de al lado pagaba sin problemas.

También explica por qué los surtidores de combustible sin personal rechazaban siempre la tarjeta mientras una caja a veces la aceptaba. Un surtidor automático francés 24/7 pide al emisor que apruebe un importe máximo fijo antes de que levantes la manguera, a menudo de 100 a 150 euros fijados por la estación, y después lo sustituye por el importe real. Esa preautorización necesita una respuesta en vivo del emisor, así que cuando el emisor guarda silencio, el surtidor dice que no todas las veces. El surtidor hace visible la caída del emisor; no la causa. Una posible explicación de los pagos que sí pasaron es que algunos terminales pueden aprobar importes pequeños sin conexión y liquidarlos después, lo que puede explicar que Clubic informara de que algunos clientes de Revolut todavía podían pagar en algunas tiendas mientras la mayoría de las tarjetas eran rechazadas.

¿Qué tiene que ver Google Cloud con mi tarjeta bancaria?

Muchos bancos y fintechs ejecutan buena parte de su software en infraestructura de nube alquilada, y cuando esa infraestructura falla, sus servicios pueden fallar con ella. Google afirma que el problema comenzó a las 06:08 UTC; su primera actualización de estado, publicada a las 10:35, hora de París, unas dos horas y media después, informaba de errores elevados y fallos de red intermitentes en europe-west2, su región de Londres. Para un titular de tarjeta, ese intervalo importó. Durante unas dos horas y media la página de estado de Google no decía nada, y a las 09:42, hora de París, la de Revolut todavía mostraba todos los sistemas operativos. The Register señala que europe-west2-b es una de las tres zonas de disponibilidad de esa región. La página de incidentes de Google lista 38 productos afectados, incluidos Kubernetes Engine, Cloud Run y BigQuery Data Transfer Service, y Google publicó una disculpa a todos los afectados. A las 13:12, hora de París, Google nombró una primera causa: «Debido a un incidente de suministro eléctrico, habíamos sufrido una caída en la zona europe-west2-b. El incidente de suministro eléctrico está mitigado», dice su actualización, con los servicios restableciéndose progresivamente. El comunicado de Google se refiere a su propia zona y no menciona a Revolut. Otras regiones de Google en Europa, incluidas París y Fráncfort, no comunicaron problemas.

La conexión con Revolut sigue siendo una atribución, no una confirmación. Una persona conocedora del asunto declaró a Reuters que la caída de Revolut estaba relacionada con la interrupción de Google Cloud, y los propios comunicados de Revolut no mencionan a Google. The Journal informó de que se entiende que la interrupción procede de una avería en un proveedor externo, sin nombrar ninguno. Esa misma mañana, Downdetector UK mostró picos para Lloyds, Halifax, Bank of Scotland, HSBC, NatWest, Santander UK y MBNA, además de Royal Mail, Rightmove y GOV.UK, y los clientes de ING Alemania tuvieron problemas para iniciar sesión en la banca online y en la aplicación. Nadie ha vinculado oficialmente esos informes con Google Cloud, y los picos de Downdetector pueden engañar, ya que los usuarios preocupados comprueban servicios que en realidad funcionan bien.

Diga lo que diga el análisis final, la forma del suceso resulta familiar. En septiembre, cuando ChatGPT, Claude y Grok fallaron a la vez, una nube compartida fue la primera sospechosa y resultó no ser la causa; esta vez, una sola región de nube es la explicación principal, aunque todavía sin confirmar. Cuando muchas empresas alquilan el mismo edificio, un fallo en ese edificio puede convertirse en el fallo de todas a la vez, y esta vez el servicio en cuestión era la tarjeta de tu bolsillo.

¿Fue un ciberataque o estuvo vinculada a los ataques contra los centros de datos rusos?

No, según las evidencias disponibles. Desde el 8 de octubre de 2026, drones ucranianos han alcanzado centros de datos de Yandex en Sásovo, Kaluga y Vladímir, interrumpiendo los servicios de Yandex en Rusia y países vecinos; cubrimos esos ataques en detalle aquí. La cobertura de esos ataques no menciona ningún efecto sobre los bancos europeos, los pagos con tarjeta o los proveedores de nube occidentales. Revolut no opera en Rusia. La caída de Revolut coincidió con un problema en unas instalaciones de Google en Londres, y ninguna fuente conecta ambos sucesos. Solo riman en una cosa: ambos muestran que los servicios críticos residen en un número reducido de edificios físicos. Pero uno es un ataque militar contra infraestructuras y el otro es un fallo de nube ordinario, y confundirlos no ayuda a nadie.

Tampoco nada apunta a un hackeo. Ninguna fuente informa de una intrusión, Revolut afirma que el dinero y los datos de los clientes están a salvo, y la aplicación de presupuestos Emma, también afectada esta mañana, describió su propio problema como un fallo técnico y no como una brecha de seguridad. Un ciberataque no queda formalmente descartado hasta que aparezca un análisis del incidente, pero todo lo visible hoy apunta a un incidente de nube, no a un ataque, y la propia Google atribuye ahora su caída de Londres a un incidente de suministro eléctrico en la zona europe-west2-b, con su informe completo del incidente todavía pendiente.

¿Fue el fallo de Linux PwnEscape o parte de una racha de caídas de nube?

Una segunda pregunta merece el mismo tratamiento. ¿Podría estar detrás un fallo de Linux recién divulgado? El 15 de octubre de 2026, cinco días antes de la caída, el equipo de CVE del núcleo de Linux publicó CVE-2026-99999, apodado PwnEscape, un fallo crítico en el código de red del núcleo, en su gestión de sumas de verificación IPv4, puntuado con 9,3 sobre 10 según CVSS 3.1. La puntuación es alta por lo que permite el fallo. Una máquina virtual invitada maliciosa puede enviar paquetes de red manipulados que corrompen el núcleo de la máquina anfitriona en la que se ejecuta, y los investigadores demostraron fugas de memoria del anfitrión, caídas del anfitrión y ejecución de código como root en el anfitrión, en su propio laboratorio. El fallo reside en la pila de red de Linux que gestiona el tráfico de los invitados, no en un hipervisor concreto.

El descubrimiento en sí fue ordenado. El equipo de investigación PWN.AI encontró el fallo durante el desafío de seguridad de sandbox de Vercel, lo comunicó de forma privada a los mantenedores del núcleo el 4 de septiembre, y la corrección llegó al núcleo principal de Linux el 14 de octubre. Más importante aún, no se ha informado de explotación activa. La evaluación de CISA del 16 de octubre, recogida en la entrada del CVE, indica «Exploitation: none» (ninguna explotación), y el fallo no figura en el catálogo de vulnerabilidades explotadas conocidas de CISA. Google no ha publicado ningún boletín de seguridad al respecto, y sus boletines hasta el 19 de octubre no lo mencionan. Google atribuye la caída de Londres a un incidente de suministro eléctrico en la zona europe-west2-b, los comunicados de Revolut no mencionan ni a Google ni ninguna vulnerabilidad, y Emma describió su propio problema como un fallo técnico y no como una brecha de seguridad. Ninguna fuente creíble vincula PwnEscape con esta caída.

El contexto, eso sí, es real. Este otoño trajo una racha de grandes incidentes de nube. El 1 de septiembre, unos cables de fibra de red desconectados durante un mantenimiento rutinario de routers aislaron partes de dos zonas de la región us-central1 de Google Cloud en Iowa durante unas cuatro horas, de 07:41 a 11:52, hora del Pacífico de Estados Unidos, afectando a 16 productos. Del 30 de septiembre al 1 de octubre, los servicios de pasarela de Microsoft Azure, incluidos ExpressRoute, VPN Gateway, Azure Firewall, Application Gateway y Azure VMware Solution, sufrieron interrupciones en 18 regiones desde las 20:30 UTC, y Microsoft citó una correlación con tareas de actualización del sistema operativo de la infraestructura. El 8 y el 9 de octubre, una actualización de configuración de balanceo de carga sobrecargó nodos de Google Cloud Storage en us-central1, provocando errores de escritura durante un total de unas 18 horas repartidas en dos días.

La conclusión justa se desprende de esos informes. La racha de incidentes es real y muestra cuánto depende de un puñado de proveedores, pero las causas declaradas fueron trabajos de mantenimiento, cambios de configuración y capacidad, y ninguno de esos informes menciona un ataque o una vulnerabilidad. La caída de Londres encaja ahora en ese patrón: Google la atribuye a un incidente de suministro eléctrico, otra causa que no es un ataque, aunque su informe completo del incidente sigue pendiente.

¿Por qué los mensajes de phishing siguen a las caídas?

Porque una caída entrega a los estafadores una historia ya hecha. Miles de personas acaban de ver su tarjeta rechazada, están preocupadas y esperan un mensaje de su banco. Un SMS falso que dice que tu tarjeta ha sido suspendida, con un enlace para verificar tus datos, resulta mucho más creíble en un día como hoy que en un martes normal. Espera una oleada de ellos en los próximos días, por SMS, correo electrónico y llamada telefónica.

Hay una razón para tomárselo en serio con Revolut en particular. En septiembre de 2026, un atacante que se hacía pasar por un regulador gubernamental italiano, enviando correos desde un dominio gubernamental legítimo, obtuvo datos de unos 650 clientes, incluidos documentos de identidad, fotos, extractos de cuenta e historiales de transacciones. Revolut lo calificó de estafa sofisticada de suplantación externa, afirmó que sus sistemas y los fondos de los clientes no se vieron afectados y contactó con los afectados. Esa filtración no está vinculada a la caída del 20 de octubre, pero significa que los datos reales de algunos clientes están en circulación, lo que hace que un mensaje de phishing parezca convincentemente personal.

Ningún agente de soporte bancario legítimo necesita tu PIN, contraseñas, códigos de un solo uso o datos de la tarjeta, y ninguno te pedirá aprobar algo en tu aplicación porque te haya llamado; en caso de duda, cuelga y contacta con el banco a través de su aplicación. No pulses enlaces en los mensajes sobre la caída; abre directamente la aplicación y lee sus avisos. Como red de seguridad, Threat Protection de Le VPN bloquea dominios conocidos de phishing y malware antes de que se carguen. No puede impedir que llegue un SMS ni detectar todos los dominios de estafa recién creados, así que tu propio escepticismo sigue siendo la primera línea de defensa.

¿Cómo evitas quedarte tirado la próxima vez?

No puedes evitar la próxima caída de Revolut, pero puedes conseguir que para ti no suponga nada.

• Lleva una segunda tarjeta de un emisor distinto. Una segunda tarjeta Revolut falla junto con la primera. Para los residentes en Francia, una tarjeta de un banco francés en la red CB es un buen complemento, ya que la aprueba un emisor diferente.
• Ten algo de efectivo. Suficiente para combustible y comida. Las retiradas en cajeros de Revolut también estaban caídas, así que el momento de sacarlo es antes de una caída, no durante.
• En la gasolinera, merece la pena probar en el mostrador con personal en lugar del surtidor automático durante una caída del emisor, aunque también puede rechazar la tarjeta.
• Consulta primero la página de estado y los avisos de la aplicación. Antes de asumir que tu tarjeta está bloqueada o comprometida, comprueba si el emisor está comunicando un incidente. Revolut también enumera los motivos ordinarios de rechazo, como una tarjeta congelada, un límite de gasto, una confirmación 3-D Secure pendiente o un tipo de pago desactivado, con el motivo concreto mostrado en la aplicación.
• No congeles, canceles ni restablezcas la tarjeta por pánico. Durante una caída del emisor eso no cambia nada, y una tarjeta cancelada supone esperar un reemplazo cuando vuelva el servicio.
• Nunca des datos a nadie que te contacte diciendo ser el soporte de Revolut, hoy menos que nunca.
• Guarda capturas de pantalla con fecha y hora de los pagos rechazados y las transferencias fallidas si te costaron dinero, y reclama al soporte de Revolut a través de la aplicación cuando se restablezca el servicio.

Una cosa que no habría ayudado es una VPN, y lo decimos siendo un proveedor de VPN. La autorización de la tarjeta se produce entre el terminal, la red de tarjetas y el emisor; tu propia conexión, con o sin un servidor VPN en Francia, no interviene en si un pago se aprueba o no. Una VPN protege tu tráfico y, con Threat Protection, filtra muchos de los dominios de estafa que siguen a un día como este. No mantiene un banco en funcionamiento.

Google ha dado una primera causa, un incidente de suministro eléctrico en su zona europe-west2-b, pero el informe completo del incidente está todavía por llegar. Cuando llegue, habrá tres cosas que vigilar: qué dejó fuera de servicio exactamente el incidente de suministro eléctrico, si Revolut confirma el vínculo con Google Cloud con sus propias palabras, y por qué su página de estado mostraba todos los sistemas operativos mientras las tarjetas ya estaban siendo rechazadas en las cajas de toda Europa.