El control de acceso roto es un punto ciego del código generado por IA. La startup VulX presenta un mecanismo de verificación determinista que no solo sospecha vulnerabilidades, sino que las demuestra, y rechaza con el mismo rigor los hallazgos no probados.
Hoy el código se escribe más rápido de lo que se puede revisar. La clase de vulnerabilidad que menos se beneficia de esa velocidad es la autorización rota, conocida como Broken Object-Level Authorization (BOLA) o IDOR, difícil de detectar de forma automatizada.
La empresa londinense VulX Ltd ha publicado un whitepaper técnico que describe un nuevo enfoque para una clase de vulnerabilidad especialmente difícil de detectar con herramientas automatizadas: la autorización rota. En lugar de confiar en la propia evaluación de un modelo de lenguaje, el documento describe un «oráculo de exploits» determinista que verifica experimentalmente las vulnerabilidades sospechadas en vez de simplemente aceptar la afirmación de un modelo.
Según la empresa, el núcleo del problema es que la autorización no es una propiedad sintáctica que un escáner basado en coincidencia de patrones pueda detectar, sino una propiedad de la política de acceso prevista de una aplicación. Precisamente ahí, sostiene el whitepaper de su fundador Minh Danh Ngo, es donde los generadores de código con IA fallan con más frecuencia: un modelo de lenguaje produce una consulta a la base de datos que funciona, pero omite silenciosamente la comprobación de que el usuario solicitante realmente es propietario de los datos consultados.
Como prueba de su relevancia práctica, el whitepaper menciona el CVE-2025-48757, una vulnerabilidad en aplicaciones creadas con la herramienta de IA Lovable. Según el análisis citado, 170 de 1.645 proyectos examinados (10,3 por ciento) estaban afectados, con 303 endpoints vulnerables y una puntuación CVSS de 9,3.
El núcleo del sistema presentado por VulX es un oráculo de exploits determinista: en lugar de confiar en un modelo de lenguaje que simplemente considera plausible una vulnerabilidad, una regla fija comprueba tres mediciones: si un ataque realmente funciona antes de aplicar un parche, si deja de funcionar después, y si una solicitud legítima sigue teniendo éxito, el llamado control negativo. Solo cuando se cumplen las tres condiciones se clasifica un hallazgo como confirmado y se reporta. Según la descripción, el propio modelo de lenguaje nunca emite el veredicto final.
Según el whitepaper, el enfoque se probó en once aplicaciones reales y disponibles públicamente. El oráculo confirmó seis vulnerabilidades de autorización y rechazó otros cinco hallazgos, por tres motivos distintos: impacto no reproducible, imposibilidad de establecer una medición de control, y sistemas objetivo que no se pudieron poner en marcha técnicamente. Solo una de las seis vulnerabilidades confirmadas fue descubierta de forma totalmente autónoma por el propio sistema; las otras cinco se probaron con escenarios de ataque proporcionados manualmente. Como capa de detección puramente determinista, sin evaluación de un modelo de lenguaje, un componente independiente localizó correctamente cinco de las seis vulnerabilidades confirmadas con una confianza alta de al menos 0,7, según el documento.
Como comparación, VulX utilizó las herramientas de análisis establecidas Semgrep y CodeQL. Según las pruebas documentadas en el whitepaper, ninguna de las dos herramientas señaló ni una sola de las cinco vulnerabilidades de autorización confirmadas y revisadas, un resultado que los autores citan como prueba de que esta clase de vulnerabilidad queda estructuralmente fuera del alcance del análisis estático convencional.
El modelo de lenguaje utilizado para construir los ataques fue, según la empresa, el modelo alojado Claude Opus 4.8, explícitamente no un modelo entrenado por la propia VulX. El coste por caso verificado sería de aproximadamente entre 0,065 y 0,11 dólares.
La propia empresa reconoce limitaciones claras en un apartado dedicado al alcance y la honestidad: la muestra es pequeña, el método se encuentra en una etapa temprana, y en aplicaciones reales las correcciones aplicadas hasta ahora son parches de referencia y no correcciones generadas de forma autónoma. Una capacidad de corrección totalmente autónoma no forma parte todavía del producto, según el documento, aunque está prevista para el futuro. Según el whitepaper, tampoco está resuelto el problema de las configuraciones de bases de datos gestionadas fuera del repositorio de código: en tres de las once aplicaciones de prueba no se pudo construir un entorno de prueba funcional por este motivo.
Para los responsables de seguridad de empresas que recurren cada vez más al código generado por IA, el whitepaper ofrece sobre todo un diagnóstico: la generación automatizada de código agrava un riesgo para el que las herramientas de escaneo convencionales todavía no ofrecen una respuesta fiable. Si el mecanismo de verificación determinista y basado en pruebas propuesto por VulX se consolida a mayor escala está por verse, dada la muestra todavía pequeña y la etapa temprana de desarrollo que la propia empresa reconoce.
Más allá de la simple confirmación, el whitepaper hace especial hincapié en los casos en los que el sistema rechaza deliberadamente un hallazgo. En un ejemplo documentado, el oráculo detectó una vulnerabilidad de autorización real en una función de uso compartido, pero no pudo demostrar de forma medible la consiguiente fuga de datos: la causa, según el análisis, fue una política de base de datos mal configurada que bloqueó de forma involuntaria la ruta de ataque real. En lugar de reportar de todos modos la supuesta vulnerabilidad, el sistema la rechazó explícitamente por no ser reproducible. Es precisamente esta lógica de rechazo, sostienen los autores, la que distingue este enfoque de los métodos de verificación basados únicamente en modelos de lenguaje, que tienden a reportar como reales hallazgos plausibles pero no probados.
El Dr. Jakob Jung es redactor jefe de Security Storage y Channel Germany. Lleva más de 20 años trabajando en el periodismo especializado en TI. A lo largo de su carrera ha colaborado con Computer Reseller News, Heise Resale, Informationweek, Techtarget (almacenamiento y centros de datos) y ChannelBiz. Además, colabora como freelance con numerosas publicaciones del sector de las TI, entre las que se incluyen Computerwoche, Channelpartner, IT-Business, Storage-Insider y ZDnet. Sus temas principales son el canal, el almacenamiento, la seguridad, los centros de datos, los sistemas ERP y CRM.
Contacto – Contacto por correo electrónico: jakob.jung@security-storage-und-channel-germany.de