Gastó USD 1.500 viendo si los LLMs podían hackear su app

Un investigador de seguridad armó una app vulnerable a propósito, soltó a varios LLMs contra ella y gastó USD 1.500 viendo si la podían hackear. El resultado: sí, los modelos encontraron y explotaron la falla de control de acceso en Firebase, pero fracasaron con los ataques más sofisticados. La respuesta a si pueden hackear los LLMs aplicaciones vulnerables es un “depende” con matices interesantes.

Broken Access Control (control de acceso roto) es una vulnerabilidad donde una aplicación no verifica correctamente si un usuario tiene permiso para acceder a un recurso, lo que le deja leer o modificar datos ajenos. En el caso de Firebase, suele aparecer cuando las reglas de seguridad de Firestore permiten lectura pública y las claves del proyecto vienen embebidas en el cliente. Es la categoría número uno del OWASP Top 10.

¿Qué vulnerabilidades pueden encontrar los LLMs en aplicaciones reales?

Ponele que le pasás a un modelo el código de una API y le pedís que busque agujeros. Lo que va a encontrar primero son las cosas “obvias” para una máquina que leyó millones de repos: credenciales hardcodeadas, reglas de Firestore mal puestas, endpoints sin autorización, tokens que viajan donde no deberían.

Ahí los LLMs andan bien. Son rápidos leyendo configuración y detectando el patrón “la puerta principal está cerrada pero la ventana del fondo está abierta”. El experimento de kasra.blog lo confirma: el objetivo era encontrar un flag escondido en las reseñas privadas de un usuario, y la falla plantada era exactamente de ese tipo.

El tema es que ahí también termina su zona de confort. Según la clasificación OWASP de vulnerabilidades en aplicaciones LLM, una cosa es que el modelo detecte un error de configuración y otra muy distinta que arme una cadena de explotación con varios pasos encadenados. Lo primero lo hace; lo segundo, todavía no de forma confiable.

Cómo fue el experimento de USD 1.500 con LLMs

El investigador, que hace research de seguridad para apps y sitios web, quería ver si los modelos podían reproducir una clase de exploit que él ya había encontrado a mano en varias aplicaciones reales. Así que montó un escenario controlado.

El setup, según su propio relato del 3 de junio de 2026:

• Frontend: una app falsa de reseñas de libros hecha en React Native con Expo, exportada para Android con Hermes.
• Backend: una API en Python con FastAPI, descrita por el propio autor como “muy segura” en sí misma.
• Capa de datos: Firebase, con la información del proyecto metida adentro de la app.
• Objetivo: encontrar un flag oculto en las reseñas privadas de un usuario.
• Material entregado a cada LLM: un ZIP con el APK y la descripción del desafío.

El plan era hacer 10 corridas por cada modelo. No llegó. La factura escaló hasta los USD 1.500 y tuvo que cortar antes de completar todas. Él mismo lo aclara sin vueltas: esto no es un eval científico, es un experimento para divertirse y sacarse la duda.

Un detalle importante para entender los resultados: su cuenta de OpenAI ya estaba aprobada para research de seguridad, así que GPT no le tiró negativas por política. Con los demás modelos la cosa fue distinta, y ahí entra el tema de cómo cada proveedor maneja los pedidos que huelen a ofensivo. Esto se conecta con lo que analizamos en medidas de seguridad empresarial.

Broken Access Control: la vulnerabilidad que los LLMs sí encontraron

Acá está el corazón del asunto. La API estaba bien hecha. Cualquiera que haya configurado una FastAPI con autenticación decente sabe que esa parte se puede blindar bastante. El problema no estaba ahí.

El problema era la arquitectura por debajo. La app usaba Firebase como capa de datos, y la información del proyecto de Firebase venía incrustada en el cliente. ¿Y por qué eso importa? Porque te permite saltearte la API entera.

El camino del exploit era directo: usar los datos de Firebase para registrarte como usuario contra Firebase de forma directa, y desde ahí leer la base de Firestore sin pasar nunca por la API segura. La puerta principal blindada no sirve de nada si la base de datos atiende a cualquiera que toque el timbre del costado.

El autor lo llama Broken Access Control o Missing Object-Level Authorization, según a quién le preguntes. Y aclara algo que vale oro: vio este caso exacto (API endurecida con Firebase abierto) en aplicaciones reales, en producción. No es un escenario de laboratorio inventado, es un error que la gente comete todo el tiempo.

¿En qué clase de vulnerabilidades ganan y pierden los LLMs?

Mirando el experimento junto con lo que documenta OWASP, se arma un mapa bastante claro de dónde el modelo aporta y dónde se queda corto. Ojo: esto es un panorama general, no un ranking definitivo.

Tipo de vulnerabilidad	¿Los LLMs la manejan bien?	Por qué
Broken Access Control / Firebase abierto	Sí	Es un patrón de configuración reconocible en el código
Credenciales hardcodeadas	Sí	El modelo las detecta leyendo el cliente
Reglas de Firestore permisivas	Sí	Falla de config legible, no requiere creatividad
XSS y bugs de lógica de negocio	Flojo	Requieren entender flujos y contexto de la app
Exploits de bajo nivel (memoria, binarios)	No	Necesitan razonamiento técnico profundo y prueba-error
Cadenas de explotación multi-paso	Inconsistente	Encadenar varios pasos todavía les cuesta

Resultados por modelo: GPT, Claude y los demás

Acá toca ser honesto con vos. El artículo original detalla el comportamiento por modelo, pero la parte fina de los números de éxito por corrida no está completa en el material disponible, así que no te voy a tirar porcentajes que no puedo verificar. Mejor quedarse con lo que sí está confirmado. Tema relacionado: ChatGPT en pruebas de seguridad.

Lo que sabemos con certeza:

• GPT corrió sin negativas porque la cuenta del investigador ya estaba aprobada por OpenAI para research de seguridad. Eso elimina un factor que distorsiona a otros modelos: el rechazo por política.
• Claude recibió un trato distinto en el experimento (el autor lo separa explícitamente del resto), lo que sugiere diferencias en cómo cada modelo aborda un pedido que parece ofensivo.
• El factor “alineación de seguridad” pesa. Un modelo que se niega a colaborar con un pedido de pentesting va a “fallar” la tarea aunque técnicamente pudiera resolverla. Eso ensucia cualquier comparación directa.

La moraleja metodológica: cuando veas un benchmark de “LLM X hackea mejor que LLM Y”, fijate si están midiendo capacidad técnica o predisposición a colaborar. No es lo mismo, y mezclarlos te da una conclusión tramposa.

¿Por qué Firebase termina siendo blanco fácil?

Firebase no es el villano de esta historia. La herramienta de Google está bien hecha. El problema es cómo la usa la gente.

El patrón se repite en miles de casos: el developer arranca el proyecto, pone las reglas de Firestore en modo permisivo para probar rápido, y nunca las vuelve a cerrar. Investigaciones de seguridad llevan años documentando bases de Firebase expuestas con datos sensibles de usuarios, justo por este descuido. La documentación oficial de Firebase sobre reglas inseguras dedica una sección entera a este error específico.

Subís el proyecto, lo probás en local, anda todo bárbaro, lo mandás a producción con las reglas de test todavía puestas, y de repente cualquiera con el SDK de Firebase y las claves que sacó del APK te lee la base entera sin que la API se entere de nada. Ese es el agujero, y es de manual.

El contraste del experimento lo deja claro: la API bien configurada bloqueó los intentos directos. Fue la capa de datos mal puesta la que abrió la puerta. Si vas a montar tu app sobre infraestructura cloud o un hosting con base de datos gestionada, las reglas de acceso son tan importantes como el código de tu backend.

¿Qué NO lograron hackear los LLMs?

Esta es la parte que más me interesa, porque marca el límite real. Los modelos encontraron la falla “fácil” de configuración. Lo que viene después es otro deporte.

Los LLMs siguen flojos en:

• Bugs de lógica de negocio: esos que requieren entender el flujo de la app, no solo leer el código. Por ejemplo, un descuento que se puede aplicar dos veces o un carrito que descuenta stock que no debería.
• XSS y ataques de inyección complejos: donde hay que armar un payload creativo y probar variantes hasta que una pega.
• Exploits de bajo nivel: corrupción de memoria, binarios, condiciones de carrera. Ahí necesitás razonamiento técnico profundo y mucho prueba-error.

¿La implicancia práctica? Los LLMs no reemplazan a un pentester humano. Son un escáner muy bueno para la fruta baja, ese primer barrido que te ahorra horas. Pero la auditoría seria, la que encuentra el agujero que nadie vio, todavía la hace una persona con experiencia.

Cómo proteger tu aplicación del hacking con LLMs

La buena noticia es que defenderse de este vector concreto no es ciencia espacial. Son prácticas conocidas que mucha gente saltea por apuro. Relacionado: capacidades de razonamiento de los modelos.

• Nunca pongas credenciales en el cliente. Si la clave está en el APK, asumí que ya está comprometida. Cualquiera la extrae.
• Cerrá las reglas de Firestore. Pasá de modo test a reglas restrictivas que validen autenticación y propiedad del recurso antes de cada lectura o escritura.
• Una sola puerta de entrada. Si tu API es la capa segura, que la base de datos no atienda pedidos directos del cliente. No tiene sentido blindar la puerta y dejar la ventana abierta.
• Auditá la configuración, no solo el código. El experimento muestra que el agujero estaba en la arquitectura, no en una línea de código mala.
• Combiná herramientas automáticas con revisión humana. Usá un LLM o un escáner para el primer barrido, después que una persona revise lo que la máquina no ve.

Y un giro lindo: la misma capacidad que usa el atacante la podés usar vos. Pasale tu código a un modelo y pedile que busque misconfiguraciones antes de subir a producción. Es defensa preventiva con la herramienta del enemigo.

Qué está confirmado y qué no

• Confirmado: el experimento existe, lo publicó kasra.blog el 3 de junio de 2026, costó USD 1.500 y usó una app de reseñas de libros (React Native + FastAPI + Firebase).
• Confirmado: la vulnerabilidad era Broken Access Control vía Firebase con credenciales en el cliente, y el autor la vio en apps reales.
• Confirmado: GPT corrió sin rechazos por tener la cuenta aprobada para research; Claude tuvo un tratamiento aparte.
• Pendiente: los porcentajes exactos de éxito por modelo y por corrida no están completos en el material disponible. Tomá cualquier ranking con pinzas.
• Pendiente: al ser un experimento no científico con corridas incompletas, no sirve para concluir “el modelo X es mejor hacker que el Y”.

Errores comunes al interpretar esto

Error 1: pensar que “el LLM hackeó la app” significa que es un hacker autónomo. No. Encontró una falla de configuración plantada a propósito, con el código servido en bandeja. La corrección: distinguir entre detectar una misconfig y armar un ataque real desde cero.

Error 2: echarle la culpa a Firebase. Firebase funciona como se espera. El error fue del developer que dejó las reglas abiertas y las claves en el cliente. La corrección: revisá tus reglas de Firestore antes de culpar a la plataforma.

Error 3: creer que un escáner con LLM reemplaza al pentesting. El propio experimento muestra que los modelos no tocaron XSS, lógica de negocio ni exploits complejos. La corrección: usá el LLM como primer filtro, no como auditoría final.

Error 4: comparar modelos sin separar capacidad de predisposición. Un modelo que se niega por política no es peor técnicamente, es más cauto. La corrección: cuando leas un benchmark de seguridad, fijate qué están midiendo en realidad.

Preguntas Frecuentes

¿Pueden los LLMs encontrar vulnerabilidades reales en aplicaciones?

Sí, pero con límites claros. Encuentran bien misconfiguraciones, credenciales hardcodeadas y fallas de control de acceso como la de Firebase del experimento de kasra.blog. Flojean con XSS, lógica de negocio compleja y exploits de bajo nivel, que siguen necesitando un pentester humano. Cubrimos ese tema en detalle en herramientas de seguridad de Google.

¿Cuál es la diferencia entre Claude y GPT para testing de seguridad?

La diferencia principal observada en el experimento fue de política, no de capacidad pura. GPT corrió sin rechazos porque la cuenta estaba aprobada por OpenAI para research de seguridad, mientras que Claude recibió un tratamiento distinto. Los datos finos de éxito por modelo no están completos, así que no hay un ganador técnico definitivo.

¿Qué tipos de vulnerabilidades explotan mejor los LLMs?

Las de configuración y control de acceso. Broken Access Control, reglas de Firestore permisivas y claves embebidas en el cliente son su terreno fuerte, porque son patrones reconocibles en el código. Es la categoría número uno del OWASP Top 10, lo que la hace muy frecuente en apps reales.

¿Cuánto cuesta hacer pentesting con inteligencia artificial?

En este experimento puntual, el investigador gastó USD 1.500 corriendo varios modelos contra una sola app, sin llegar a completar las 10 corridas previstas por modelo. El costo depende del modelo, la cantidad de intentos y el tamaño del contexto. Para un barrido inicial es accesible; para una auditoría completa sigue saliendo más a cuenta combinarlo con trabajo humano.

¿Cómo protejo mi aplicación Firebase del hacking con LLMs?

Cerrá las reglas de Firestore para que validen autenticación y propiedad del recurso, nunca pongas credenciales en el cliente y hacé que la base de datos no atienda pedidos directos si tu API es la capa segura. Auditá la configuración además del código, porque ahí suele estar el agujero.

Conclusión

El experimento de los USD 1.500 deja una foto realista, sin humo. Los LLMs ya son una herramienta útil para encontrar la fruta baja de seguridad: misconfiguraciones, claves expuestas, controles de acceso rotos. Esa parte la hacen rápido y barato, y conviene aprovecharla del lado defensivo antes de subir nada a producción.

Pero el experimento también marca el techo. Los modelos no tocaron los ataques que requieren creatividad o razonamiento técnico profundo. Si tenés una app con Firebase o Supabase, el mensaje urgente es revisar hoy mismo tus reglas de acceso y sacar cualquier credencial del cliente. Eso te cubre del vector más común. Para el resto, el pentester humano sigue teniendo trabajo, y por un buen rato.

Fuentes

• kasra.blog – I built a vulnerable app and spent $1,500 seeing if LLMs could hack it (experimento original)
• Firebase – Documentación oficial sobre reglas de seguridad inseguras
• Tarlogic – OWASP Top 10 de vulnerabilidades en aplicaciones LLM
• Kaspersky – LLMjacking 2026 y seguridad de servidores de IA privados
• arXiv – Investigación sobre capacidades de LLMs en seguridad ofensiva