Googles PageBreak findet 500 XSS-Lücken – Prüfcodes bremsen Fehlalarme

Google hat in seinem PageBreak-Bericht vom 24. September 2026 mehr als 500 Cross-Site-Scripting-Schwachstellen (XSS) in eigenen Webanwendungen gemeldet und die Fehlalarmquote nach der Prüfung als nahezu null beschrieben. Der interne Sicherheitsagent lässt dafür mögliche Angriffe durch separate, nicht von der KI geschriebene Prüfcodes gegen laufende Anwendungen testen.

Die Zahl beschreibt Funde in Googles eigenen Anwendungen und seiner Infrastruktur. Sie ist keine gemessene Erfolgsquote für fremde Websites. Der Kern der Veröffentlichung ist die Trennung zwischen einer plausiblen Angriffsidee und einem Test, der zeigt, dass die eingeschleuste Nutzlast tatsächlich ausgeführt wird.

Wie aus einem XSS-Verdacht ein bestätigter Fund wird

PageBreak sucht nach Wegen, auf denen Eingaben einer Webanwendung als ausführbarer Code im Browser ankommen könnten. Ein verdächtiges Codemuster ist zunächst nur eine Hypothese: Der betreffende Pfad könnte unerreichbar sein, eine Schutzfunktion könnte die Eingabe verändern oder das eingeschleuste Skript könnte aus einem anderen Grund nicht laufen. Würde ein KI-Agent solche Vermutungen ungeprüft weitergeben, müssten Produktteams auch überzeugend formulierte Fehlalarme untersuchen.

Für XSS übergibt der Agent den Kandidaten an einen spezialisierten Validator. Dieser setzt eine konkrete JavaScript-Testnutzlast ein, lädt die betroffene Seite mithilfe einer Testumgebung oder vorhandener Scan-Infrastruktur und beobachtet, ob der Code im Ausführungskontext der Seite läuft. Erst das beobachtete Ergebnis liefert den Beleg für den Fund. Der Prüfcode bewertet damit nicht bloß, ob ein Angriff denkbar klingt, sondern ob die entscheidende Wirkung eintritt.

Die Validatoren unterscheiden sich je nach Fehlerklasse. Bei einer möglichen SQL-Injection prüfen sie beispielsweise die Ausgabe oder Laufzeit einer manipulierten Datenbankabfrage; bei einem vermuteten unerlaubten Dateizugriff testen sie, ob die Anwendung eine zuvor angelegte Datei lesen kann. Für andere Klassen kommen wiederum andere beobachtbare Ergebnisse infrage. Gemeinsam ist diesen Prüfungen, dass der KI-Agent die Hypothese liefert, während ein gesondertes Werkzeug ihren praktischen Effekt misst.

Auch dieser Filter hat Grenzen. Ein komplexer Angriff kann unbestätigt bleiben, wenn ein passender Validator fehlt oder dem Agenten der nötige Zugriff auf die Testumgebung fehlt. Solche Kandidaten gehen nicht als bestätigte Schwachstellen an Produktteams; sie können weitere Suchläufe oder die Entwicklung neuer Prüfwerkzeuge anstoßen. Weniger Fehlalarme bei gemeldeten Treffern bedeuten deshalb nicht, dass PageBreak jede vorhandene Lücke findet.

Eine Signaturkette zeigt den Unterschied zur bloßen Mustersuche

Ein Fall auf admin.google.com macht deutlich, warum ein ausführbarer Test wichtig ist. Die Darstellung von iThome beschreibt einen XSS-Pfad, für dessen Ausnutzung eine gültige Signatur erforderlich war: PageBreak fand einen weiteren Endpunkt, der einen manipulierten Parameter gültig signieren konnte. Mit dieser Signatur ließ sich anschließend eine URL erzeugen, die den XSS-Pfad auslöste.

Die Signaturprüfung selbst war damit nicht ausgeschaltet. Vielmehr lieferte eine andere Funktion der Anwendung genau die Voraussetzung, die der geschützte Pfad verlangte. Wer nur die einzelne Ausgabestelle betrachtet, könnte den Angriff deshalb verwerfen, weil dort eine Signatur gefordert wird. Erst die Verbindung der beiden Endpunkte ergibt eine funktionsfähige Angriffskette; der Test muss zeigen, dass diese Verbindung in der Anwendung tatsächlich gelingt.

Das Beispiel erklärt zugleich die Rolle des Validators. Eine KI kann eine mehrstufige Kette vorschlagen, aber ihre sprachliche Schlüssigkeit beweist noch keine Ausnutzbarkeit. Der Prüfcode muss eine passende Nutzlast durch den vorgesehenen Ablauf bringen und die Ausführung beobachten. So bleibt ein Kandidat, dem ein entscheidender Zwischenschritt fehlt, eine Hypothese statt einer bestätigten Sicherheitsmeldung.

Warum die Gesamtzahl und die Framework-Funde verschiedene Aussagen tragen

In Hunderten von Anwendungen mit Googles besonders abgesicherten Webframeworks fand PageBreak bis zum 4. September 2026 lediglich zwei XSS-Schwachstellen; beide betrafen interne Anwendungen oder Debug-Endpunkte mit Lücken bei der Absicherung. Die größere Fundzahl bezieht sich dagegen auf Googles eigene Webanwendungen insgesamt. Es handelt sich also um unterschiedlich abgegrenzte Gruppen, nicht um zwei Ergebnisse unter offengelegten, identischen Testbedingungen.

Der geringe Wert in der Framework-Gruppe ist mit dem Zweck dieser Schutzmechanismen vereinbar: Sie sollen bestimmte ausnutzbare Webfehler schon beim Bau der Anwendung verhindern. Aus den veröffentlichten Angaben lässt sich aber keine belastbare Wirksamkeitsquote errechnen. Dafür fehlen unter anderem vergleichbare Angaben zu Größe, Aufbau und Prüfbedingungen der Anwendungsgruppen. Auch ein rechnerisches Verhältnis der Fundzahlen würde diese Unterschiede nicht beseitigen.

Die Funde sind außerdem nicht mit beobachteten Angriffen auf Nutzer gleichzusetzen. Ebenso wenig belegt die Gesamtzahl, wie viele Lücken zum Zeitpunkt der Veröffentlichung noch ungepatcht waren oder welchen Schweregrad sie jeweils hatten. Die beschriebene niedrige Fehlalarmquote betrifft die Verlässlichkeit bestätigter Meldungen; sie misst nicht, wie viele tatsächlich vorhandene Schwachstellen der Agent übersehen hat.

Was sich übertragen lässt – und was an Google gebunden ist

Übertragbar ist das Prüfprinzip: Ein KI-System formuliert einen konkreten Verdacht, ein davon getrennter Test führt eine passende Nutzlast aus, und erst ein beobachtbares Ergebnis führt zu einer bestätigten Meldung. Welche Nutzlast geeignet ist und welches Ergebnis als Beleg zählt, hängt von der Anwendung und der vermuteten Fehlerklasse ab. Ein Sprachmodell allein ersetzt weder einen erreichbaren Testpfad noch die technische Messung des Resultats.

Die Reichweite der gemeldeten Suche hängt dagegen stark von Googles Umgebung ab. PageBreak kann Ausführungspfade durch einen gemeinsamen Codebestand verfolgen, Konfigurationen verschiedener Dienste berücksichtigen und Signale aus realem HTTP-Verkehr mit Quellcode verbinden. Hinzu kommt vorhandene Scan-Infrastruktur, die auch authentifizierte Tests interner Anwendungen ermöglicht. Ein Team mit Zugriff auf nur ein Repository oder einen öffentlichen Endpunkt hat eine andere Sicht auf mögliche Angriffsketten.

Der veröffentlichte Stand zeigt damit einen internen Einsatz mit überprüften Treffern, aber keinen unabhängigen Benchmark für KI-Scanner. Offen bleiben eine externe Überprüfung der Gesamtzahl, eine Aufschlüsselung nach Anwendungen und Schweregrad sowie vergleichbare Messungen außerhalb von Google. Gerade diese Daten wären nötig, um die Fundzahl über den beschriebenen Einsatz hinaus einzuordnen.

Lesen Sie auch:

• Cloud Storage Advisor findet Egress-Spitzen – Zugriffsrechte bleiben Pflicht
• Google Cloud ersetzt VM-Startskripte: Extension Manager ist jetzt allgemein verfügbar
• Mehrere KI-Agenten, neue Risiken – NIST sieht Lücken in heutigen Schutzmodellen