Hotelera Wyndham expuso datos de clientes por clave en app

¿Qué encontró el investigador en la app de Wyndham?

El investigador de seguridad Robert Wiggins, de la firma What Security, encontró una contraseña escrita dentro del código fuente de la app Android de Wyndham. Esa credencial abría el acceso a una base de datos interna de la compañía hotelera alojada en Salesforce, según contó en exclusiva a TechCrunch.

La base contenía información personal: nombres de clientes, direcciones de correo electrónico y el número de socio del programa de fidelidad. También guardaba tokens de sesión —los llamados JWT— que mantienen a los usuarios con la sesión abierta sin tener que volver a escribir su contraseña, además de archivos y documentos internos de la empresa.

Según Wiggins, la base tenía millones de registros, aunque no pudo determinar con exactitud cuántos clientes quedaron expuestos. La cadena declara unos 129 millones de socios inscritos en su programa de recompensas, lo que da una idea de la escala del sistema afectado.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El detalle que convierte este caso en una lección para cualquier equipo de producto: Wyndham no tenía un canal para reportar fallos de seguridad. El investigador tuvo que pedir ayuda a un medio para que alertara a la compañía. Poco después de que TechCrunch contactara al equipo de ciberseguridad, la credencial fue revocada y el acceso a la base quedó cerrado.

¿Por qué una contraseña en el código es una vulnerabilidad de gravedad máxima?

Incluir credenciales dentro del software que se distribuye públicamente se conoce como hardcoding. El problema es elemental: cualquiera que tenga una copia de la app puede extraer esa contraseña y usarla para entrar a la base de datos asociada. No hace falta un exploit sofisticado ni un zero-day. Basta con descompilar el paquete de la aplicación y leer.

Por esa simpleza, muchos sistemas de puntuación de vulnerabilidades califican los casos de credenciales embebidas con la severidad máxima. La barrera de entrada para un atacante es prácticamente cero.

El contexto de la industria respalda que este tipo de descuido no es un caso aislado. En su informe Data Breach Investigations Report de 2022, Verizon encontró que el uso de credenciales robadas estuvo presente en casi el 50% de los ataques analizados y en más del 80% de las brechas clasificadas como ataques básicos a aplicaciones web, según reportó TechTarget. El mismo informe señaló que las malas configuraciones explicaron alrededor del 40% de las brechas en 2021, impulsadas en buena medida por almacenes de datos en la nube levantados sin los controles de acceso adecuados.

Traducido a un equipo de producto: la mayoría de las brechas no ocurre por una falla criptográfica brillante, sino porque alguien dejó una puerta abierta y nadie revisó.

¿Qué no quiso responder Wyndham y por qué importa?

La respuesta pública de la compañía fue breve. Un portavoz aseguró que «nuestro equipo ha tomado medidas para abordar el problema» y que «nuestros equipos de seguridad no tienen evidencia de ningún acceso no autorizado».

TechCrunch preguntó, y la empresa no respondió:

Si tenía medios técnicos, como registros de servidor, para saber si alguien accedió a la base antes del hallazgo del investigador.
Si planeaba notificar a los clientes afectados.
Si reportaría el incidente a reguladores de EE. UU., como la notificación a la SEC que las compañías cotizadas deben presentar ante incidentes de ciberseguridad materiales.
Cuánto tiempo estuvo la contraseña embebida en la app.
Cómo piensa entregar una solución definitiva.
Si creará un programa de divulgación de vulnerabilidades para que investigadores externos reporten fallos de forma privada.

La afirmación de que no hay evidencia de acceso es la parte más delicada. Wiggins señaló que sin visibilidad sobre la actividad pasada, alguien con intención maliciosa podría haber filtrado grandes volúmenes de datos personales. Dicho de otro modo: la ausencia de evidencia no es evidencia de ausencia, y solo lo es si existen los registros para comprobarlo.

El director de ciberseguridad de Wyndham, Michael Francess, indicó a TechCrunch que los investigadores pueden reportar posibles problemas de seguridad por correo electrónico. La empresa no confirmó si modificará su sitio web para publicar esa vía de contacto.

¿La IA está acelerando el descubrimiento de fallos?

Un dato relevante del caso: fue el segundo hallazgo público de credenciales embebidas de Wiggins en dos semanas, después de encontrar una vulnerabilidad casi idéntica en la app de Applebee’s. En ambos casos se apoyó en herramientas de IA.

La razón es de escala. Revisar miles de líneas de código descompilado a mano es lento y caro; un modelo lo hace en segundos. Eso significa que el trabajo de auditoría que antes requería un especialista durante días hoy lo puede hacer alguien con criterio y buenas herramientas en una tarde.

El efecto es doble y conviene entenderlo bien:

A favor de los defensores: auditar tus propias apps deja de ser un lujo y pasa a ser viable para equipos pequeños.
En contra de quien se confía: el atacante también usa IA, y la ventana entre publicar una versión y ser descubierto se acorta.

¿Qué antecedentes de seguridad tiene Wyndham?

No es el primer incidente conocido. En 2024, un investigador encontró que varios mostradores de check-in de hoteles de la cadena ejecutaban un spyware de acceso remoto que filtraba capturas de pantalla con registros de huéspedes e información de reservas a la web abierta.

Poco después de la publicación de ese reporte, la aplicación de spyware —llamada pcTattletale— fue hackeada y sus bancos de datos de clientes robados. Su propietario, Bryan Fleming, se vio obligado a cerrar la empresa y posteriormente fue detenido por autoridades federales y condenado por crear, vender y publicitar spyware ilegal.

El patrón se repite: fallas simples, de operación más que de arquitectura, y una respuesta reactiva.

¿Qué significa esto para tu startup?

Si tienes una app móvil en producción, tu superficie de riesgo incluye cada copia del binario que ya circula. Estos son los movimientos que un founder puede ejecutar esta misma semana.

1. Escanea tu propio código en busca de secretos. Integra un escáner de secretos en el pipeline de CI/CD (hay opciones open source como gitleaks o trufflehog) para que cualquier credencial detectada bloquee el merge. La regla de oro: una clave que viaja al cliente deja de ser secreta.

2. Revisa la app como lo haría un atacante. Descarga tu propio APK, descompílalo y busca cadenas de conexión, claves de API y contraseñas. Si encuentras una, no basta con rotarla: hay que reescribir ese flujo.

3. Elimina el acceso privilegiado del cliente. El patrón correcto es que la app hable con tu backend y que sea tu backend el que consulte la base con credenciales que nunca salen del servidor. Si necesitas tokens en el dispositivo, que sean de vida corta y con alcance limitado.

4. Abre un canal de divulgación de vulnerabilidades. Un archivo security.txt, una dirección de correo monitoreada y un compromiso de respuesta en plazo cambian por completo el escenario: el investigador te avisa a ti en lugar de recurrir a la prensa. Es la diferencia entre un ticket y un titular.

5. Guarda los registros que te permitan responder con honestidad. La frase «no tenemos evidencia de acceso no autorizado» solo se sostiene si tienes logs de consultas a la base. Si no los tienes, la respuesta correcta es admitir el desconocimiento y activar el plan de respuesta, no negar el impacto.

Conclusión

Una contraseña escrita en el código de una app abrió una base con datos de clientes de una cadena que declara 129 millones de socios. No hubo malware exótico ni ataque dirigido: hubo una credencial expuesta y un canal inexistente para reportarla.

Para un founder, el mensaje es incómodo pero útil. La seguridad de tu producto no se mide por lo que tienes blindado, sino por lo que tus propios usuarios —y cualquiera que descargue tu app— pueden leer en el binario. Y se mide, sobre todo, por lo rápido que tu equipo se enteraría si alguien encontrara algo antes que tú.