Agente de IA PageBreak da Google encontrou mais de 500 falhas XSS nas suas aplicações

A Google divulgou pormenores do PageBreak, um agente de IA interno que procura falhas de segurança nas aplicações web da própria empresa. Utilizado em grande escala, descobriu mais de 500 vulnerabilidades de cross-site scripting (XSS) nas aplicações web próprias da Google, algumas em domínios sensíveis, escreve o engenheiro de segurança da Google Michał Bentkowski no blogue da empresa; o iThome apresenta os mesmos números.

O cross-site scripting é um tipo de vulnerabilidade em que um atacante consegue injetar código JavaScript numa página web vista por outro utilizador, o que lhe pode permitir agir na sessão da vítima. É uma das falhas mais comuns nas aplicações web.

O problema que o PageBreak quer resolver: o ruído da IA

Usar grandes modelos de linguagem para analisar código mudou a gestão de vulnerabilidades, mas também gerou ruído, explica a Google. Muitas equipas de segurança estão sobrecarregadas porque uma parte significativa dos relatórios que recebem são hipóteses não verificadas ou falsos positivos produzidos por modelos que funcionam como analisadores estáticos de código, aquilo a que a empresa chama AI slop. Distinguir uma falha real e explorável de uma alucinação convincente tornou-se um grande desafio, que muitas vezes aumenta a carga das equipas de produto.

O PageBreak começou como projeto-piloto em novembro de 2025 e tornou-se um projeto de pleno direito em janeiro de 2026. Pode funcionar com diferentes modelos, mas a maior parte da utilização assenta em modelos Gemini como o Gemini 3.1 Pro e o Gemini 3.5 Flash, segundo a Google.

Como funcionam os validadores

A escolha de conceção central é a validação determinística. Quando o agente identifica uma falha potencial, passa a hipótese a um validador especializado, escrito sem IA, que executa uma carga real contra um ambiente em funcionamento para confirmar a exploração. Os candidatos não verificados nunca são enviados às equipas de produto. A Google diz que isso resulta numa taxa de falsos positivos próxima de zero, ponto também sublinhado pelo iThome.

• XSS: injeta uma carga JavaScript, carrega o URL num ambiente de renderização e verifica se o código injetado é realmente executado.
• Injeção de SQL: verifica se as consultas à base de dados podem ser manipuladas, observando a resposta ou o tempo de resposta.
• Travessia de diretórios: cria um ficheiro num local legível por todos e verifica se a aplicação o consegue ler.
• Execução remota de código: tenta técnicas como um atraso, a escrita de um ficheiro ou o envio de um pedido DNS ou HTTP de saída.
• Falsificação de pedidos do lado do servidor: deteta se a aplicação faz um pedido a um serviço interno.

A Google reconhece que os seus validadores ainda não cobrem todos os tipos de vulnerabilidade nem todos os cenários complexos, o que cria o risco de falhas passarem despercebidas. Os resultados não verificados ficam, por isso, internos: servem de ponto de partida para análises mais profundas em execuções seguintes, mostram onde são precisos novos validadores, e o agente indica que capacidades ou acessos lhe faltaram para confirmar uma descoberta.

Falhas que tinham escapado aos humanos

A Google descreveu ainda três casos de gravidade elevada encontrados pelo PageBreak em aplicações que já tinham sido analisadas pelos seus engenheiros de segurança e por caçadores de falhas externos sem que estas fossem detetadas, relata o iThome. Num deles, o agente encontrou um XSS em admin.google.com que exigia uma assinatura válida no pedido; depois encontrou outro ponto de acesso que levava a aplicação a gerar uma assinatura válida para um parâmetro malicioso, o que permitia construir um URL de exploração que contornava a proteção por assinatura. Segundo a Google, estes casos mostram que os modelos de linguagem são cada vez mais capazes de encontrar vulnerabilidades cuja exploração exige vários passos.

A Google publicou os pormenores técnicos destas explorações num artigo complementar do seu blogue Bug Hunters. Entre eles está uma falha complexa de envenenamento de cache, causada pela má configuração de um serviço, e um caso em que o agente contornou totalmente sozinho proteções criptográficas, segundo a empresa. Estes exemplos contam porque vão além dos padrões simples de injeção que os scanners clássicos já detetam.

O agente beneficiou também de vantagens próprias da Google, diz a empresa: um repositório único de código com milhares de milhões de linhas, sinais de segurança que ligam o tráfego HTTP real a linhas de código-fonte e um scanner já existente capaz de se autenticar em quase todas as aplicações web da Google. Para aumentar as probabilidades, a Google executa os agentes com sementes idênticas ao longo de muitas iterações.

O que mudaram as frameworks seguras desde a conceção

O resultado mais marcante diz respeito às aplicações construídas sobre as frameworks web de alta garantia da Google, concebidas para eliminar por omissão as vulnerabilidades web exploráveis. A 4 de setembro de 2026, o PageBreak tinha encontrado apenas 2 falhas XSS em centenas de aplicações construídas sobre essas frameworks, ambas limitadas a aplicações internas ou a pontos de depuração com lacunas de proteção, escreve a Google. Mesmo verificados, os relatórios chegam em volume sem precedentes, pelo que o PageBreak trabalha com outros agentes, como o CodeMender, que geram correções automáticas, com o objetivo de reduzir o papel das equipas de produto à validação das correções propostas.

O que muda para as empresas portuguesas

Para as empresas de software e as equipas internas de segurança que já recebem relatórios de vulnerabilidades gerados por IA, a abordagem da Google oferece uma regra prática: não agir perante a suspeita de um modelo antes de um teste determinístico ter reproduzido a exploração. O resultado das frameworks é igualmente útil: a forma mais barata de resistir a atacantes automatizados é construir as aplicações web sobre frameworks que bloqueiam por omissão categorias inteiras de falhas, em vez de caçar erros um a um a posteriori.