# Expedia confirma la brecha y no verifica ni una cifra > Expedia admite una brecha a través de un proveedor externo. El grupo n0n dice tener 830 millones de filas de fidelidad y la empresa no confirma el alcance. > Por José Maldonado · Ciberseguridad · 2026-11-14 Expedia Group reconoció el 12 de noviembre de 2026 que unos atacantes llegaron a sus sistemas a través de un proveedor externo de plataforma de datos. Lo hizo con un comunicado breve que deja casi todo abierto: hubo un ataque de cadena de suministro, ese proveedor sirvió de puerta a varias empresas y la compañía no piensa decir cuál era ni qué datos salieron. La [confirmación de la brecha de Expedia](https://skift.com/2026/11/12/expedia-confirms-cyberattack-through-third-party-vendor/) no incluye ni una sola cifra sobre el alcance, y la empresa tampoco ha aclarado si el incidente que admite es el mismo que describe el grupo. En paralelo, el grupo de extorsión n0n sostenía su propia versión en la web de filtraciones: 830.069.282 filas de programas de fidelidad en 800 archivos y 35 programas, con correos e identificadores de socio, saldos en 21 divisas y valores de reserva. Son números que nadie ha comprobado, que la empresa no ha validado y que el grupo publicó sin ofrecer una muestra auditable de lo que dice tener en su poder. La distancia entre lo que una empresa firma y lo que un extorsionador pública, es la parte más informativa de este caso. Aquí lo confirmado es el camino, no el botín: un tercero con acceso de confianza abrió la puerta y la cerró tarde. ## Lo que Expedia confirmó y lo que dejó sin responder El comunicado no incluye una sola cifra. Expedia Group dice que contuvo el problema en cuanto lo conoció, que investiga con expertos externos en seguridad y que sus plataformas siguen siendo seguras para viajeros y socios, sin nombrar al proveedor comprometido ni detallar qué datos quedaron expuestos. Tampoco aclara cuándo ocurrió la intrusión, qué marcas del grupo están afectadas o cuántas personas podrían estar dentro del balance. El grupo es dueño de Expedia, Hotels.com, Vrbo, Orbitz, Travelocity y Hotwire, y ninguna de esas marcas ha recibido de momento una explicación distinta. La falta de un solo dato verificable contrasta con la precisión de la reclamación que circula desde la primera semana de noviembre de 2026, cuando n0n añadió a la compañía a su lista de víctimas. El silencio sobre el alcance duró hasta el 12 de noviembre de 2026. Antes de esa fecha, la empresa declinó comentar las afirmaciones del grupo, y el comunicado llegó cuando el inventario llevaba más de una semana circulando entre analistas de seguridad, sin que nadie hubiera podido comprobar su contenido. Lo que sí admite la empresa tiene peso técnico, aunque suene a fórmula de manual. Un proveedor de datos comprometido no necesita atacar a nadie: entra con las llaves que le dieron para hacer su trabajo y desde dentro todo parece normal durante días. ## Las cifras que n0n pone encima de la mesa El grupo publicó su inventario en la web de filtraciones y lo mantuvo incluso después de marcar a la compañía como víctima que no había pagado. No hay importe de rescate en la ficha, la [lista de volúmenes reclamados](https://breachnews.com/breaches/expedia-supply-chain-attack-n0n-claim/) supera el terabyte y el desglose tiene más de una cifra que conviene mirar con lupa. ¿Qué dice tener n0n? Volumen reclamado Comprobado Programa de fidelidad 830.069.282 filas en 800 archivos y 35 programas No Perfiles de viajero Más de 58 millones No Cuentas y credenciales Más de 333 millones de registros No Viajes Más de 22 millones, con reservas y pagos de Vrbo No Comunicaciones de huéspedes Casi 500.000 No El recuento de filas no equivale al número de personas: un mismo cliente aparece en la tabla de fidelidad, en el perfil de viajero y en la reserva, y cada aparición suma una línea distinta. Ese detalle convierte los 830 millones en una cifra sin traducir a víctimas, y explica por qué la empresa no la ha confirmado ni desmentido en ninguno de sus comunicados. El inventario que describe el grupo incluye además credenciales de trabajo de la plataforma de datos, repositorios de código fuente y un entorno cloud de producción. Si esa parte fuera cierta, el problema dejaría de ser el histórico de reservas y pasaría a ser la capacidad de volver a entrar sin pedir permiso a nadie. Con esos datos se puede montar un engaño barato y creíble. Un mensaje que cite el destino, las fechas exactas de una reserva y el saldo de puntos del programa de fidelidad no necesita ganarse la confianza de nadie: la tiene por adelantado. La [brecha de Sega a través de su proveedor de boletines](https://observatorioblockchain.com/ciberseguridad/sega-arara-brecha-2-2-millones-correos/) mostró el mecanismo con 2,19 millones de correos expuestos y ninguna contraseña de por medio: el valor estaba en la lista, no en la clave. Aquí el paquete sería más rico, porque incluye historial de reservas y niveles de fidelidad. ## El rol de AWS que sobrevivió al proveedor El [análisis técnico de Wiz](https://www.wiz.io/blog/qubole-cross-account-access-abused-in-the-wild) documentó entre el 14 y el 26 de octubre de 2026 el mecanismo que encaja con esa descripción. Un atacante usó credenciales IAM de la cuenta de AWS desde la que Qubole opera, plataforma de datos para grandes volúmenes, para asumir los roles que los clientes habían creado para confiar en esa cuenta. Cada petición llevaba el identificador externo correcto y cada petición funcionó. Con esos permisos, el atacante enumeró recursos, leyó secretos de Secrets Manager, del almacén de parámetros y de las variables de las funciones Lambda, probó las claves encontradas y copió objetos de S3 sin escribir ni borrar nada. La [investigación de Sentra](https://www.sentra.io/blog/breaches/inside-the-qubole-supply-chain-attack) añadió el dato incómodo: los roles seguían vivos en clientes que habían dejado de usar la plataforma, dormidos desde la primavera y sin que nadie los revocara. Las direcciones desde las que se hicieron las peticiones tampoco ayudaban a desconfiar. Wiz sitúa las primeras llamadas en una IP de una red privada virtual comercial y la mayoría del resto en un servidor alquilado, mientras el proveedor no registraba actividad propia en esa ventana: para AWS, el visitante era el proveedor. ### El origen del fallo Ahí está el fallo de fondo. El identificador externo no autentica a nadie: es un código que el proveedor presenta, y si el proveedor lo pierde, el código sigue siendo válido para quien lo tenga en la mano. Expedia es antigua clienta de Qubole y su comunicado encaja con ese escenario, pero ni la empresa ni Wiz ni Sentra la han señalado públicamente como víctima de esa campaña concreta. La relación entre los dos hechos sigue siendo una hipótesis razonable y sin confirmar, y escribirla como un hecho sería repetir el error que este caso castiga. La lista de comprobación para cualquier empresa que externalizó su plataforma de datos cabe en cuatro líneas, y ninguna de ellas exige comprar nada ni contratar a un equipo nuevo durante un trimestre. * Revisar qué identidades externas conservan permisos sobre tus datos y revocar las que ya no usas. * Activar los eventos de datos de S3 en CloudTrail, porque los registros de gestión no ven las lecturas de objetos. * Rotar los secretos que ese rol podía leer, no solo desactivar el rol. * Tratar el identificador externo como una condición del contrato, no como una prueba de identidad. El [ataque con agentes de IA que expuso datos de clientes de Chainstack](https://observatorioblockchain.com/agentes-de-ia/ataque-ia-expuso-datos-clientes-chainstack/) dejó la misma lección desde otro ángulo: una credencial de fábrica olvidada en un servidor de pruebas bastó para entrar en producción, y nadie la había retirado porque el servidor seguía encendido para otras tareas. ## La llave que nadie devolvió Cerrar una integración no borra el permiso. Esa frase resume el incidente mejor que cualquier recuento, porque el acceso que usó el atacante no fue robado a Expedia ni a las otras empresas: lo habían concedido ellas mismas, por escrito, para que un proveedor hiciera su trabajo. La [brecha de Gnosis Pay](https://observatorioblockchain.com/ciberseguridad/brecha-gnosis-pay-expone-datos-titulares-tarjetas/) mostró la misma asimetría desde el lado de los titulares de tarjetas: datos sensibles en manos de un tercero y clientes sin forma de saberlo hasta que fue tarde.