El agente de IA PageBreak de Google halló más de 500 fallos XSS en sus propias aplicaciones

Google ha publicado detalles de PageBreak, un agente de IA interno que busca fallos de seguridad en las aplicaciones web de la propia compañía. Utilizado a gran escala, ha descubierto más de 500 vulnerabilidades de cross-site scripting (XSS) en las aplicaciones web propias de Google, algunas en dominios sensibles, escribe el ingeniero de seguridad de Google Michał Bentkowski en el blog de la empresa; iThome recoge las mismas cifras.

El cross-site scripting es un tipo de vulnerabilidad en el que un atacante consigue inyectar código JavaScript en una página web que ve otro usuario, lo que puede permitirle actuar en la sesión de la víctima. Es uno de los fallos más frecuentes en las aplicaciones web.

El problema que quiere resolver PageBreak: el ruido de la IA

Usar grandes modelos de lenguaje para analizar código ha cambiado la gestión de vulnerabilidades, pero también ha generado ruido, explica Google. Muchos equipos de seguridad están desbordados porque una parte importante de los avisos que reciben son hipótesis sin verificar o falsos positivos producidos por modelos que actúan como analizadores estáticos de código, lo que la empresa llama AI slop. Distinguir un fallo real y explotable de una alucinación convincente se ha convertido en un gran desafío que a menudo aumenta la carga de los equipos de producto.

PageBreak comenzó como piloto en noviembre de 2025 y se convirtió en un proyecto completo en enero de 2026. Puede trabajar con distintos modelos, pero la mayor parte de su uso se basa en modelos Gemini como Gemini 3.1 Pro y Gemini 3.5 Flash, según Google.

Cómo funcionan los validadores

La decisión de diseño clave es la validación determinista. Cuando el agente detecta un posible fallo, pasa la hipótesis a un validador especializado, escrito sin IA, que ejecuta una carga real contra un entorno en funcionamiento para confirmar la explotación. Los candidatos sin verificar nunca llegan a los equipos de producto. Google afirma que así logra una tasa de falsos positivos cercana a cero, algo que también destaca iThome.

• XSS: inyecta una carga de JavaScript, carga la URL en un entorno de renderizado y comprueba si el código inyectado se ejecuta de verdad.
• Inyección SQL: comprueba si las consultas a la base de datos pueden manipularse observando la respuesta o el tiempo de respuesta.
• Recorrido de directorios: crea un archivo en una ubicación legible por todos y comprueba si la aplicación puede leerlo.
• Ejecución remota de código: prueba técnicas como un retardo, la escritura de un archivo o el envío de una petición DNS o HTTP saliente.
• Falsificación de peticiones del lado del servidor: detecta si la aplicación hace una petición a un servicio interno.

Google reconoce que sus validadores todavía no cubren todos los tipos de vulnerabilidad ni todos los escenarios complejos, lo que implica el riesgo de pasar fallos por alto. Por eso los hallazgos sin verificar se quedan dentro: sirven de punto de partida para análisis más profundos en pasadas posteriores, muestran dónde hacen falta nuevos validadores, y el agente informa de qué capacidades o accesos le faltaron para confirmar un hallazgo.

Fallos que se les habían escapado a las personas

Google también describió tres casos de gravedad alta encontrados por PageBreak en aplicaciones que ya habían revisado sus ingenieros de seguridad e investigadores externos sin detectar esos fallos, informa iThome. En uno de ellos, el agente encontró un XSS en admin.google.com que exigía una firma válida en la petición; después halló otro punto de acceso que hacía que la aplicación generara una firma válida para un parámetro malicioso, lo que permitía crear una URL de explotación que eludía la protección por firma. Según Google, estos casos muestran que los modelos de lenguaje son cada vez más capaces de encontrar vulnerabilidades cuya explotación requiere varios pasos.

Google ha publicado los detalles técnicos de estas explotaciones en un artículo complementario de su blog Bug Hunters. Entre ellos figura un complejo fallo de envenenamiento de caché, causado por la mala configuración de un servicio, y un caso en el que el agente eludió por completo y por sí solo unas protecciones criptográficas, según la empresa. Estos ejemplos importan porque van más allá de los patrones de inyección sencillos que ya detectan los escáneres clásicos.

El agente también se benefició de ventajas propias de Google, según la compañía: un único repositorio de código con miles de millones de líneas, señales de seguridad que vinculan el tráfico HTTP real con líneas de código fuente y un escáner ya existente capaz de autenticarse en casi todas las aplicaciones web de Google. Para aumentar sus posibilidades, Google ejecuta los agentes con semillas idénticas en numerosas iteraciones.

Lo que cambian los frameworks seguros por diseño

El resultado más llamativo se refiere a las aplicaciones construidas sobre los frameworks web de alta garantía de Google, diseñados para eliminar por defecto las vulnerabilidades web explotables. A 4 de septiembre de 2026, PageBreak solo había encontrado 2 fallos XSS en cientos de aplicaciones construidas sobre esos frameworks, ambos limitados a aplicaciones internas o a puntos de depuración con carencias de endurecimiento, escribe Google. Incluso verificados, los avisos llegan en un volumen sin precedentes, por lo que PageBreak trabaja con otros agentes como CodeMender, que generan correcciones automáticas, con el objetivo de que los equipos de producto se limiten a validar los parches propuestos.

Qué cambia para las empresas españolas

Para las empresas de software y los equipos de seguridad internos que ya reciben avisos de vulnerabilidades generados por IA, el enfoque de Google ofrece una regla práctica: no actuar ante la sospecha de un modelo hasta que una prueba determinista haya reproducido la explotación. El resultado de los frameworks es igual de útil: la forma más barata de resistir a atacantes automatizados es construir las aplicaciones web sobre frameworks que bloquean por defecto categorías enteras de fallos, en lugar de perseguir errores uno a uno a posteriori.