Googles KI-Agent PageBreak fand mehr als 500 XSS-Lücken in eigenen Web-Apps

Google hat Details zu PageBreak veröffentlicht, einem internen KI-Agenten, der in den eigenen Webanwendungen des Konzerns nach Sicherheitslücken sucht. In großem Maßstab eingesetzt, hat er mehr als 500 Cross-Site-Scripting-Schwachstellen (XSS) in Googles eigenen Webanwendungen aufgedeckt, einige davon auf sensiblen Domains, schreibt Google-Sicherheitsingenieur Michał Bentkowski im Unternehmensblog; iThome berichtet dieselben Zahlen.

Cross-Site Scripting ist eine Klasse von Schwachstellen, bei der ein Angreifer JavaScript-Code in eine Webseite einschleust, die ein anderer Nutzer aufruft, und so in der Sitzung des Opfers handeln kann. Es gehört zu den häufigsten Lücken in Webanwendungen.

Das Problem, das PageBreak lösen soll: KI-Rauschen

Der Einsatz großer Sprachmodelle zur Codeanalyse hat das Schwachstellenmanagement verändert, aber auch Rauschen erzeugt, erklärt Google. Viele Sicherheitsteams sind überlastet, weil ein erheblicher Teil der eingehenden Meldungen unbestätigte Hypothesen oder Fehlalarme von Modellen sind, die als statische Codeanalysatoren arbeiten, was das Unternehmen AI slop nennt. Eine echte, ausnutzbare Lücke von einer überzeugenden Halluzination zu unterscheiden, ist zu einer großen Herausforderung geworden, die Produktteams oft zusätzlich belastet.

PageBreak begann im November 2025 als Pilot und wurde im Januar 2026 zu einem vollwertigen Projekt. Es kann mit verschiedenen Modellen arbeiten, stützt sich laut Google aber überwiegend auf Gemini-Modelle wie Gemini 3.1 Pro und Gemini 3.5 Flash.

So arbeiten die Validatoren

Die zentrale Designentscheidung ist die deterministische Validierung. Findet der Agent eine mögliche Lücke, übergibt er die Hypothese an einen spezialisierten, ohne KI geschriebenen Validator, der einen echten Angriffscode gegen eine laufende Umgebung ausführt, um die Ausnutzbarkeit zu bestätigen. Unbestätigte Kandidaten gehen nie an Produktteams. Google gibt an, so eine Fehlalarmquote nahe null zu erreichen, was auch iThome hervorhebt.

• XSS: schleust JavaScript ein, lädt die URL in einer Rendering-Umgebung und prüft, ob der eingeschleuste Code tatsächlich läuft.
• SQL-Injection: prüft anhand von Ausgabe oder Antwortzeit, ob sich Datenbankabfragen manipulieren lassen.
• Path Traversal: legt eine Datei an einem allgemein lesbaren Ort an und prüft, ob die Anwendung sie lesen kann.
• Remote Code Execution: versucht Techniken wie eine Verzögerung, das Schreiben einer Datei oder eine ausgehende DNS- oder HTTP-Anfrage.
• Server-Side Request Forgery: erkennt, ob die Anwendung eine Anfrage an einen internen Dienst stellt.

Google räumt ein, dass die Validatoren noch nicht alle Schwachstellentypen oder komplexen Szenarien abdecken, wodurch Lücken übersehen werden können. Unbestätigte Funde bleiben daher intern: Sie dienen als Ausgangspunkt für tiefere Prüfungen in späteren Durchläufen, zeigen, wo neue Validatoren nötig sind, und der Agent meldet, welche Fähigkeiten oder Zugänge ihm zur Bestätigung fehlten.

Lücken, die Menschen übersehen hatten

Google beschrieb zudem drei schwerwiegende Fälle, die PageBreak in Anwendungen fand, die zuvor von Googles Sicherheitsingenieuren und externen Bug-Huntern geprüft worden waren, ohne dass diese Lücken entdeckt wurden, berichtet iThome. In einem Fall fand der Agent eine XSS-Lücke auf admin.google.com, für deren Ausnutzung die Anfrage eine gültige Signatur brauchte; danach fand er einen anderen Endpunkt, der die Anwendung dazu brachte, für einen bösartigen Parameter eine gültige Signatur zu erzeugen, womit sich eine Angriffs-URL bauen ließ, die den Signaturschutz umging. Laut Google zeigen solche Fälle, dass Sprachmodelle zunehmend Schwachstellen finden, deren Ausnutzung mehrere Schritte erfordert.

Die technischen Details dieser Angriffe hat Google in einem Begleitbeitrag in seinem Bug-Hunters-Blog veröffentlicht. Darunter ist laut Unternehmen eine komplexe Cache-Poisoning-Lücke, verursacht durch die Fehlkonfiguration eines Dienstes, und ein Fall, in dem der Agent kryptografische Schutzmechanismen ganz allein umging. Diese Beispiele sind wichtig, weil sie über die einfachen Injektionsmuster hinausgehen, die klassische Scanner bereits erkennen.

Der Agent profitierte zudem von Google-spezifischen Vorteilen, so das Unternehmen: einem einzigen Code-Repository mit Milliarden Zeilen, Sicherheitssignalen, die echten HTTP-Verkehr Quellcodezeilen zuordnen, und einem vorhandenen Scanner, der sich bei fast jeder Google-Webanwendung anmelden kann. Um die Trefferchancen zu erhöhen, lässt Google Agenten mit identischen Startwerten über viele Iterationen laufen.

Was sichere Frameworks verändert haben

Das auffälligste Ergebnis betrifft Anwendungen, die auf Googles hochgesicherten Web-Frameworks laufen, die ausnutzbare Web-Schwachstellen standardmäßig ausschließen sollen. Bis zum 4. September 2026 fand PageBreak in Hunderten solcher Anwendungen nur 2 XSS-Lücken, beide beschränkt auf interne Anwendungen oder Debug-Endpunkte mit Härtungslücken, schreibt Google. Selbst bestätigte Meldungen kommen in beispielloser Zahl, deshalb arbeitet PageBreak mit anderen Agenten wie CodeMender zusammen, die automatische Korrekturen erzeugen; Ziel ist, dass Produktteams künftig nur noch vorgeschlagene Patches prüfen.

Was das für Unternehmen in Deutschland bedeutet

Für Softwarehäuser und interne Sicherheitsteams, die inzwischen KI-generierte Schwachstellenmeldungen erhalten, liefert Googles Ansatz eine praktische Regel: nicht auf den Verdacht eines Modells reagieren, bevor ein deterministischer Test den Angriff reproduziert hat. Ebenso nützlich ist das Framework-Ergebnis: Der günstigste Weg, automatisierten Angreifern standzuhalten, ist, Webanwendungen auf Frameworks zu bauen, die ganze Fehlerklassen standardmäßig verhindern, statt Fehler nachträglich einzeln zu jagen.