Sygnia, firma especializada en ciberseguridad, encontró una vulnerabilidad crítica en una aplicación de alta de clientes utilizada por una empresa de servicios financieros que gestiona miles de millones en activos. De acuerdo con la investigación, la herramienta se había construido en gran medida con ayuda de Claude, y el fallo podía dejar expuesta información personal y financiera de una sensibilidad extrema.
Lo inquietante no era un bug de manual, de esos que saltan a la vista en una revisión básica. La aplicación tenía varias defensas que, vistas por separado, parecían sensatas. El problema es que todas estaban colocadas en la capa equivocada: la decisión de fondo sobre qué debía considerarse confiable estaba mal planteada.
La mecánica era esta. La aplicación emitía o regeneraba tokens de acceso para los solicitantes solo por el hecho de que alguien presentara su GUID, un identificador global único que, en teoría, debía servir únicamente para localizar un registro. En la práctica, explica Sygnia, ese identificador terminó funcionando como una llave maestra. Si alguien conocía el GUID, podía entrar como si fuera el titular legítimo.
Ahí estaba el agujero.
A partir de ese punto se podía consultar nombres, datos de contacto, estado de la solicitud, información financiera, datos usados para la verificación de identidad, información de pago, números de la Seguridad Social y registros de co-solicitantes. Dicho de forma simple, no era una fuga menor, sino la exposición potencial de expedientes completos de clientes.
La aplicación sí había incorporado medidas que muchas organizaciones considerarían razonables: tokens temporales, caducidad de sesiones, limitación de peticiones, auditoría de accesos, recuperación de sesión y detección de actividad sospechosa. El problema es que todas esas barreras descansaban sobre una premisa equivocada.
La pregunta decisiva nunca quedó bien resuelta: quién debía recibir un token desde el principio. Si un sistema acepta un simple identificador como prueba suficiente de identidad, casi todo lo demás pierde buena parte de su valor.
Sygnia insiste en que este caso deja ver un problema muy delicado del desarrollo actual. El código puede compilar, pasar pruebas básicas y no mostrar los patrones inseguros de siempre, y aun así seguir siendo peligroso. No había aquí una inyección SQL ni un flujo de datos claramente expuesto, sino un fallo de arquitectura en la frontera de confianza entre el usuario y el sistema.
Y ese tipo de error suele pasar de largo en muchas revisiones automáticas, porque, técnicamente, cada pieza por separado parece correcta.
El caso se suma, además, a una lista cada vez más larga de advertencias sobre el uso de herramientas de generación automática de código en entornos sensibles. Sygnia cita estudios que sitúan entre el 45% y el 62% la proporción de código generado que presenta vulnerabilidades, con mejoras bastante limitadas con el paso del tiempo. Estas herramientas suelen rendir mejor ante fallos muy conocidos, pero siguen tropezando con errores lógicos más sutiles.
Hay además una paradoja incómoda. Esta tecnología ya la están usando tanto atacantes como defensores. Sygnia sostiene que también está acelerando ofensivas y menciona un caso reciente en el que un solo atacante logró comprometer un entorno corporativo en la nube en 72 horas. Al mismo tiempo, la propia firma recurrió a un modelo de lenguaje para ayudar a detectar esta vulnerabilidad.
Para muchos expertos del sector, la lección cae por su propio peso: el código generado automáticamente no debería darse por confiable hasta haber pasado una validación a fondo. Con el ritmo de desarrollo actual, la deuda de seguridad crece más deprisa que la capacidad de revisarla, y mientras tanto aumentan la presión regulatoria y el riesgo para la confianza del consumidor.
