GPT superó a Claude y Gemini en prueba de hackeo con IA sobre app vulnerable y Firebase

Un investigador de seguridad creó una app vulnerable, gastó cerca de USD $1.500 en pruebas y comparó a varios modelos de lenguaje para medir si podían reproducir un fallo real de acceso roto. El resultado dejó un dato incómodo para la industria: algunos sistemas de IA no solo entendieron el problema, sino que lograron explotarlo de forma consistente.
***

• El experimento evaluó si distintos LLM podían descubrir y explotar una mala configuración entre una app móvil, una API endurecida y Firebase.
• GPT 5.5 logró 7 éxitos en 10 intentos, mientras DeepSeek V4 Pro obtuvo 3 de 10 y varios modelos terminaron con 0 resoluciones.
• La prueba no fue científica, pero sí mostró diferencias claras en costos, consumo de tokens, autocensura y capacidad de razonamiento agentivo.

La discusión sobre inteligencia artificial y ciberseguridad suele oscilar entre dos extremos: la promesa de mejores defensas y el temor a que los modelos automatizados aceleren ataques reales. Un nuevo experimento informal, pero detallado, volvió a poner esa tensión sobre la mesa al medir qué tan bien distintos modelos de lenguaje podían vulnerar una aplicación diseñada con una falla clásica de autorización.

El ejercicio fue realizado por el investigador Kasra, quien construyó una app falsa de reseñas de libros con frontend en React Native sobre Expo y un backend en Python. El objetivo era sencillo en apariencia: encontrar una bandera escondida en las reseñas privadas de un usuario. La clave del reto, sin embargo, no estaba en romper la API principal, sino en detectar una exposición en Firebase.

Según explicó Kasra en I built a vulnerable app and spent $1,500 seeing if LLMs could hack it, la API estaba “muy segura” en sí misma, pero la aplicación incluía un archivo google-services.json con información de Firebase. A partir de allí, el camino correcto consistía en registrarse directamente como usuario y leer la base de datos de Firestore, en vez de insistir con la API.

Ese patrón no fue elegido al azar. El autor aseguró que corresponde a una categoría de exploit que ha visto repetidamente en aplicaciones reales con Firebase y Supabase. En términos de seguridad, lo describió como un caso de control de acceso roto o de autorización a nivel de objeto mal resuelta, una clase de error especialmente delicada porque puede coexistir con APIs bien endurecidas.

Cómo se hizo la prueba y qué límites tuvo

Kasra aclaró desde el inicio que no se trató de una evaluación científica. Su intención era más modesta y, a la vez, provocadora: ver si los LLM podían reproducir una clase común de explotación que él ha encontrado en auditorías reales. Planeó hacer 10 ejecuciones por modelo objetivo, pero terminó deteniendo el ensayo tras gastar cerca de USD $1.500.

La mayoría de los modelos fueron corridos con un arnés basado en pi y una extensión llamada pi-goal-x para obligarlos a seguir intentando. Claude fue evaluado con el modo -p de Claude Code, que no soporta modo plan, aunque el autor señaló que ese sistema no se detenía a mitad del proceso. Todos los modelos fueron probados con alto nivel de razonamiento y temperatura 0,7 en los casos compatibles.

Cada ejecución tuvo un límite de tiempo de dos horas y un techo de gasto de USD $10. Además, el autor indicó que no incluyó las ejecuciones de prueba ni las fallidas en la publicación, pese a que representaron aproximadamente 50% del costo total. Ese detalle es importante, porque sugiere que el gasto real del experimento fue afectado tanto por errores operativos como por pruebas no concluyentes.

También hubo diferencias de infraestructura. Casi todos los modelos se probaron con su proveedor canónico, mientras que uno de los casos se hizo a través de OpenRouter. El investigador añadió que utilizó Modal para ejecutar los agentes debido al tamaño de las transcripciones, aunque luego calificó esa decisión como un error, ya que la plataforma habría arruinado cerca de 10% de las corridas.

Los resultados: GPT 5.5 lideró, varios modelos no resolvieron nada

Entre los modelos que completaron 10 ejecuciones, GPT 5.5 obtuvo la mejor tasa de resolución: 7 aciertos de 10. Su intervalo de confianza de Wilson al 95% quedó entre 40% y 89%. El costo promedio por ejecución fue de USD $6,62, con un costo por resolución de USD $9,46 y un consumo promedio de 260.000 tokens por corrida, sin contar tokens en caché.

DeepSeek V4 Pro quedó en segundo lugar, aunque bastante por detrás, con 3 resoluciones de 10. Su costo medio por ejecución fue de apenas USD $0,19 y el costo por éxito fue de USD $0,62. En promedio utilizó 194.000 tokens. Claude Sonnet 4.6 y Claude Opus 4.8 terminaron con 2 aciertos de 10 cada uno, pero con costos muy diferentes: Sonnet promedió USD $9,15 por ejecución y Opus USD $3,23.

El resto del grupo principal cerró con 0 resoluciones de 10: DeepSeek V4 Flash, Gemini 3.1 Pro Preview, Gemini 3.5 Flash, MiniMax M2.7 y Step 3.7 Flash. En esos casos, los rangos de confianza quedaron entre 0% y 28%. Llamó la atención Gemini 3.1 Pro Preview, cuyo promedio de tokens por ejecución fue de apenas 9.000, muy por debajo de otros modelos, una señal consistente con rechazos tempranos por motivos de seguridad.

En una segunda tabla, con menos ejecuciones completas, GLM 5.1 obtuvo 1 éxito en 4 intentos, Qwen 3.7 Max falló en sus 6 corridas, Grok Build 0.1 también cerró en 0 de 6, MiniMax M3 terminó en 0 de 3, Kimi K2.6 resolvió 1 de 1 y Owl Alpha no logró ningún éxito en 10 pruebas. Qwen destacó por una métrica llamativa: 7,32 millones de tokens por ejecución, un volumen extraordinario para un resultado nulo.

Qué hizo bien cada modelo y dónde se perdió

Kasra describió patrones de conducta bastante definidos. En GPT 5.5, casi cada ejecución se enfocó rápidamente en Firebase una vez descomprimido el APK. El modelo no solía atascarse buscando fallas en la API o en la aplicación React Native, lo que sugiere una capacidad mayor para reconocer cuándo el vector de ataque principal no está en la superficie más obvia.

DeepSeek V4 Pro mostró una conducta más ambigua. En cinco ejecuciones nunca tocó Firebase y se concentró solo en la API o en la app. En las otras cinco sí se dio cuenta de que podía acceder a Firebase, pero dos de esas corridas intentaron usar la autenticación de Firebase contra la API en lugar de interactuar directamente con la base de datos, un desvío táctico que terminó costando resoluciones.

Claude Sonnet 4.6 y Claude Opus 4.8 también llegaron a identificar el camino correcto en varias ocasiones. Sonnet investigó la API y la app antes de moverse hacia Firebase, pero cinco corridas se quedaron sin presupuesto antes de completar la explotación. Opus, por su parte, estuvo muy cerca repetidamente, aunque las barandillas de seguridad terminaron la sesión tarde en el proceso, no desde el inicio.

Entre los modelos que no resolvieron nada, DeepSeek V4 Flash arrancó de forma prometedora al reconocer la funcionalidad de Firebase, pero luego cerraba con informes concluyendo que la API parecía segura. MiniMax M2.7 insistió por completo en la API y la app, sin reconsiderar el enfoque. Step 3.7 Flash documentó muy bien la API, pero llegó a reportar falsos hallazgos de explotación cuando en realidad no había logrado el objetivo.

Rechazos, autocensura y diferencias entre proveedores

Un punto llamativo del ensayo fue la disparidad en las respuestas de seguridad de los proveedores. Gemini 3.1 Pro Preview fue descrito como un caso de rechazo inmediato por razones de seguridad. Gemini 3.5 Flash también mostró muchos rechazos desde el inicio, aunque dos ejecuciones sí avanzaron algo antes de ser frenadas más tarde, en una dinámica que el autor comparó con la de Claude Opus.

Kasra afirmó que su cuenta de OpenAI ya estaba aprobada para investigaciones de seguridad, y por eso GPT no terminó en rechazos. Ese detalle vuelve difícil hacer comparaciones puramente lineales entre modelos, porque el entorno de permisos influyó sobre la conducta final. Aun así, el contraste entre sistemas que razonaron activamente y otros que bloquearon la tarea fue una de las conclusiones más visibles del ejercicio.

El investigador también observó una diferencia cultural o de diseño entre familias de modelos. A su juicio, los modelos chinos se mostraron mucho más cómodos atacando directamente la base de datos. Otros sistemas, en cambio, tuvieron momentos de vacilación del tipo “esto afectaría a la base de datos en vivo, así que no voy a hacerlo”, lo que en una prueba controlada redujo su desempeño frente al objetivo planteado.

Esa diferencia no implica necesariamente superioridad general en seguridad ofensiva. También podría reflejar el peso que cada proveedor asigna a sus políticas de uso, sus filtros de riesgo o la tolerancia al accionar autónomo. Pero sí deja una lección importante para empresas y equipos técnicos: la utilidad o el peligro de un modelo no depende solo de su capacidad bruta, sino del marco operativo en que se despliega.

Costos, frustraciones y una advertencia para equipos que usan Firebase

Más allá del ranking, Kasra fue muy crítico con algunos proveedores e infraestructuras. Dijo que no volverá a usar MiniMax ni GLM debido a caídas constantes en sus API y a la necesidad de reiniciar múltiples ejecuciones tras haber quemado dinero en corridas fallidas. Sobre GLM 5.1 fue todavía más duro, al afirmar que probablemente no volverá a usarlo por su costo y por su alto consumo de tokens.

Qwen 3.7 Max también lo decepcionó. El autor dijo que, en pruebas locales previas al arnés completo, había sido el único modelo no GPT capaz de completar la tarea, pero no pudo replicar ese desempeño en corridas largas. Grok Build 0.1, mientras tanto, se limitó a comprobaciones básicas de IDOR contra la API y en dos ocasiones incurrió en falsos positivos al interpretar que leer reseñas propias equivalía a una vulnerabilidad.

En contraste, Kimi K2.6 dejó una impresión favorable al completar el desafío en su única ejecución, con velocidad y consumo de tokens similares a DeepSeek V4 Pro. Sin embargo, el autor no siguió probándolo porque la API de Kimi no soporta usos agentivos concurrentes y tiene un límite bajo de tokens por minuto que además incluye los tokens en caché.

El mensaje de fondo del experimento es incómodo, pero útil. Incluso cuando una API parece bien protegida, una mala configuración en Firebase o Firestore puede abrir una vía de acceso directa a los datos. Para startups, desarrolladores móviles y proyectos Web3 que integran servicios externos, la lección es clara: endurecer el backend no basta si la capa de datos conserva permisos excesivos o reglas mal definidas.

Para el ecosistema de IA, el ensayo deja otra conclusión. Los agentes autónomos ya son capaces, en algunos casos, de encadenar análisis del APK, inferencia sobre arquitectura y explotación de accesos rotos. No es una prueba definitiva ni un estudio académico, pero sí una advertencia práctica sobre cómo las capacidades agentivas están empezando a cruzarse con problemas de seguridad demasiado comunes en aplicaciones reales.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín