Índice de contenidos
Claves de la noticia
- Google afirma que PageBreak, su agente interno de seguridad, ha encontrado más de 500 vulnerabilidades XSS en aplicaciones web propias.
- El sistema exige una prueba ejecutada por un validador especializado antes de enviar un aviso confirmado a los equipos de producto.
- La cifra describe hallazgos internos, no ataques sufridos por usuarios ni un balance público de fallos pendientes de corregir.
Google ha publicado este 24 de septiembre los primeros resultados detallados de PageBreak, un proyecto que combina modelos Gemini con herramientas tradicionales para buscar fallos en sus aplicaciones web. El dato más llamativo son más de 500 vulnerabilidades de ejecución de scripts entre sitios (XSS) detectadas en servicios de la propia compañía. La noticia importa tanto por la escala como por la forma en que Google intenta distinguir una hipótesis convincente de una vulnerabilidad demostrada.
Quinientos hallazgos, con un alcance concreto
El ingeniero de seguridad Michał Bentkowski explica en el relato técnico de Google que PageBreak empezó como piloto en noviembre de 2025 y pasó a proyecto formal en enero de 2026. El agente examina aplicaciones web de Google y usa mayoritariamente modelos Gemini 3.1 Pro y Gemini 3.5 Flash, aunque su arquitectura admite otros modelos. La compañía atribuye al despliegue a gran escala el descubrimiento de más de 500 XSS, incluso en dominios que califica de sensibles.
Un XSS permite que contenido controlado por un atacante acabe ejecutándose como código en el navegador bajo el contexto de una página legítima. Su efecto depende del lugar concreto, de los permisos de la sesión y de las defensas del servicio. Por ello, 500 hallazgos no equivalen a 500 cuentas comprometidas, ni Google ofrece en esta publicación una lista de productos afectados, gravedad individual, fechas de reparación o incidentes reales de explotación. Es una cifra comunicada por el operador de los sistemas analizados, no una auditoría independiente.
La secuencia temporal también limita la lectura del dato: el piloto comenzó en 2025, el proyecto tomó forma en enero y Google presenta ahora un resultado acumulado sin separar meses, aplicaciones o clases de gravedad. Sería incorrecto transformar ese total en una tasa mensual de fallos o en un porcentaje de sitios vulnerables. La publicación tampoco dice que todos los errores permanezcan abiertos hoy.
El validador decide qué llega al equipo
La diferencia técnica de PageBreak está en el paso posterior a la sospecha. Según Google, el agente plantea una posible vulnerabilidad y un validador específico, escrito sin IA, intenta reproducirla en un entorno en ejecución. Para XSS, inyecta una carga de JavaScript y observa si realmente se ejecuta en el navegador. Las pruebas para inyección SQL inspeccionan cambios en respuestas o tiempos; las de recorrido de rutas intentan verificar la lectura de un archivo creado para la prueba. La publicación describe también mecanismos de confirmación para ejecución remota de código y solicitudes desde el servidor hacia servicios internos.
Ese diseño evita que un patrón de código aparentemente peligroso se convierta por sí solo en una incidencia confirmada. Google afirma que la tasa de falsos positivos de los avisos validados se aproxima a cero. No aporta, sin embargo, un denominador de hipótesis descartadas ni una evaluación externa de esa tasa. La precisión de las alertas es una afirmación de Google; el método descrito permite entender por qué podría mejorar respecto a un agente que solo lee código, pero no autoriza a cuantificar la mejora.
El filtro tiene un coste reconocido por la propia empresa: una vulnerabilidad que el validador aún no sabe reproducir puede quedarse sin aviso confirmado. PageBreak conserva esos indicios como semillas para nuevas pasadas y como guía para crear más validadores, pero no los envía a los equipos de producto. De ahí surge una conclusión operativa: la calidad del sistema depende de dos coberturas diferentes, la capacidad del modelo para proponer rutas de ataque y la capacidad de las herramientas para probarlas. Mejorar una sin la otra no garantiza encontrar más fallos reales.
La arquitectura segura cambia el resultado
Google aporta una segunda observación, fechada al 4 de septiembre de 2026. En cientos de aplicaciones construidas con sus marcos web de alta garantía, PageBreak solo identificó dos XSS; ambos estaban limitados a aplicaciones internas o puntos de depuración con carencias de endurecimiento. La empresa había explicado en 2025 su apuesta por marcos que eliminan clases de vulnerabilidades desde el diseño. La comparación es sugerente porque enfrenta el mismo tipo de búsqueda automatizada con una defensa estructural, aunque faltan tamaños y condiciones comparables de las dos muestras.
El contraste entre más de 500 XSS en el conjunto analizado y dos en las aplicaciones de esos marcos sostiene una lectura prudente: automatizar la caza de fallos no reemplaza construir aplicaciones con barreras de seguridad por defecto. Los dos números proceden de universos distintos y no permiten calcular cuánto reduce el riesgo el marco. Sí señalan que el valor de PageBreak no reside solo en hallar errores, sino en comprobar dónde resisten las defensas que Google ya había desplegado.
Esta lectura coincide con un cambio anterior en la política de recompensas de Google. En abril de 2026, la compañía explicó que, ante el aumento de informes asistidos por IA, su programa para Android y Chrome empezaría a dar más peso a reproductores y pruebas concretas que a descripciones extensas sin demostración. La lógica de PageBreak traslada ese criterio al trabajo interno: un reporte útil debe poder verificarse y dirigirse al equipo responsable. Son ámbitos distintos, por lo que el cambio del programa externo no demuestra por sí mismo la eficacia del agente.
Qué cambia para quienes protegen aplicaciones
PageBreak aprovecha ventajas que Google reconoce como particulares: acceso a un gran repositorio de código, señales del tráfico de sus servicios e infraestructura de pruebas capaz de autenticarse en aplicaciones internas. Una empresa sin esos recursos no puede trasladar directamente la cifra de 500 hallazgos a su propio entorno. Sí puede evaluar el principio verificable del sistema: separar la generación de hipótesis de una prueba reproducible, registrar lo que el validador no alcanza y mantener barreras preventivas en el desarrollo.
El antecedente de Palo Alto Networks y sus agentes de búsqueda de vulnerabilidades ilustra que distintas compañías están combinando modelos y herramientas para investigar fallos, aunque sus resultados no son directamente equiparables. También hay una diferencia con la prueba de Gemini que accedió a sistemas de tres empresas: PageBreak se presenta como una operación defensiva dentro de aplicaciones propiedad de Google, no como una medición abierta del rendimiento de un modelo frente a terceros.
Google prevé integrar PageBreak con iniciativas que generan correcciones automáticas, como CodeMender. La publicación describe ese trabajo como una aspiración de reducir la intervención del equipo de producto, no como un ciclo de reparación ya demostrado para los 500 hallazgos. Por ahora, la aportación comprobable es más delimitada: una alerta respaldada por ejecución real resulta más accionable que una sospecha redactada por un modelo, mientras la prevención en el diseño sigue siendo la defensa que reduce la superficie que habrá que perseguir después.
