Google zufolge hat ein interner KI-Agent mehr als 500 Cross-Site-Scripting-Schwachstellen in eigenen Webanwendungen aufgespürt.
Das System namens PageBreak kombiniert KI-generierte Sicherheitshypothesen mit separaten Validatoren, die versuchen, Payloads in laufenden Anwendungen auszuführen. Google zufolge soll diese Validierungsstufe verhindern, dass plausibel klingende KI-Ausgaben fälschlich als ausnutzbare Schwachstellen eingestuft werden.
Die gemeldete Zahl ist beachtlich, ihr Umfang muss jedoch eingeordnet werden. Sie bezieht sich auf Funde, nicht auf betroffene Nutzer. Aus den verfügbaren Angaben geht außerdem nicht hervor, ob alle gemeldeten Schwachstellen behoben wurden. Es fehlen auch CVE-Kennungen, CVSS-Werte, Belege für eine böswillige Ausnutzung oder bestätigte Auswirkungen auf Google-Kunden.
PageBreak wurde vom Pilotprojekt zum internen Produkt
PageBreak wurde von Googles Product-Security-Team entwickelt, um die eigenen Webanwendungen und Browser-Erweiterungen zu untersuchen. Der Informationssicherheitsingenieur Michał Bentkowski sagte, das System habe mehr als 500 XSS-Schwachstellen gefunden.
Dem Bericht über PageBreak und die Ergebnisse zufolge begann das Projekt im vergangenen November als Pilot und wurde im Januar zu einem vollständigen Produkt. Für diese beiden Meilensteine nennt die Quelle keine Jahreszahlen. Google stellte das System im vergangenen Monat in einem Unternehmensblog vor.
Diese Angaben beschreiben Entwicklungs- und Veröffentlichungsmeilensteine, nicht den Zeitpunkt, zu dem einzelne Schwachstellen eingeführt, entdeckt oder behoben wurden. Ein einzelnes Vorfallsdatum gibt es ebenfalls nicht, da PageBreak ein System für Sicherheitstests und kein gemeldeter Sicherheitsvorfall ist.
Zu den öffentlich genannten Beispielen von Google gehören drei unterschiedliche Funde:
- Eine Cache-Poisoning-Schwachstelle bei
apis.google.com - Eine XSS-Schwachstelle in
admin.google.com - Unsichere externe Handshakes bei Browser-Erweiterungen
Im zugehörigen Beitrag hieß es Google zufolge, diese drei Schwachstellen seien behoben worden. Daraus lässt sich jedoch nicht ableiten, dass auch die übrigen Funde behoben wurden – darunter die mehr als 500 XSS-Schwachstellen, die PageBreak zugeschrieben werden.
Der Bericht nennt außerdem keine externen Organisationen, die von den Schwachstellen betroffen waren. Demnach beschränkten sich die Tests auf eigene Google-Dienste und Browser-Erweiterungen.
KI schlägt Schwachstellen vor, doch separate Prüfungen müssen sie belegen
Die Architektur von PageBreak soll ein wiederkehrendes Problem KI-gestützter Sicherheitstests angehen: Ein Modell kann eine technisch überzeugende Erklärung liefern, ohne eine tatsächlich ausnutzbare Schwachstelle zu identifizieren.
Bentkowski zufolge untersucht der Agent zunächst eine Anwendung und formuliert eine Schwachstellenhypothese. Anschließend übergibt er den Kandidaten an einen spezialisierten Validator. Dieser versucht, in einer aktiven Umgebung eine echte Payload gegen die Anwendung auszuführen. PageBreak meldet das Problem erst, wenn dieser Versuch die Schwachstelle nachweist.
Laut der Beschreibung werden die Validatoren nicht von einer KI geschrieben. Ihre Logik und Schnittstellen unterscheiden sich je nach Schwachstellenkategorie und untersuchter Anwendungsoberfläche.
Für XSS, SQL-Injection und Remote Code Execution sind beispielsweise unterschiedliche Validierungsmethoden erforderlich. Auch die Prüfung einer HTTP-Anwendung unterscheidet sich von der eines gRPC-Dienstes. PageBreak nutzt daher weder einen universellen Prompt noch ein einheitliches Prüfverfahren für alle Ziele.
Diese Trennung ist wichtig, weil die KI-Komponente nicht selbst abschließend über ihre Funde entscheidet. Sie liefert Kandidaten, während ein anderer Mechanismus für den Ausführungsnachweis zuständig ist.
Google beschreibt das System als Kombination aus autonomer Suche und deterministischer Validierung. Bentkowski bezeichnete die Falsch-Positiv-Rate als „nahe null“. Das bleibt eine Angabe des Unternehmens: Der verfügbare Bericht enthält keine unabhängige Prüfung der Erkennungsgenauigkeit, der Falsch-Positiv-Rate oder der Abdeckung von PageBreak.
Gemini-Modelle übernehmen die Suche, nicht die abschließende Prüfung
PageBreak nutzt hauptsächlich Gemini 3.1 Pro und Gemini 3.5 Flash. Google zufolge kann das System jedoch auch mit anderen Modellen arbeiten.
Die Trennung zwischen Modellen und Validatoren ist ein zentraler Bestandteil des Konzepts. Gemini kommt bei der Suche zum Einsatz: Der Zugriff auf Quellcode und Sicherheitstools kann dem Agenten helfen, mögliche Angriffspfade zu formulieren. Der nicht KI-basierte Validator prüft anschließend, ob sich ein Kandidat am laufenden Zielsystem tatsächlich nachweisen lässt.
Bentkowski zufolge kann KI Schwachstellen schneller aufspüren als menschliche Forscher. Zugleich räumte er ein, dass es Aufwand bedeutet, echte Schwachstellen von überzeugend wirkenden Halluzinationen zu unterscheiden. Ohne wirksame Validierung führt eine schnellere Suche möglicherweise nur dazu, dass Produkt- und Entwicklungsteams mehr Arbeit mit der Prüfung haben.
Die verfügbaren Informationen enthalten keine Vergleichswerte zu menschlichen Forschern oder anderen automatisierten Scannern. Auch die Leistung der beiden genannten Gemini-Modelle in diesem Einsatzbereich ist nicht unabhängig belegt.
Externe Experten unterstützen die Trennung von Suche und Nachweis
Rickard Carlsson, CEO von Detectify, beschrieb ein allgemeines Kapazitätsproblem für Sicherheitsteams: KI-Tools können mehr mutmaßliche Schwachstellen melden, als sich realistisch von Menschen untersuchen lassen.
Carlsson zufolge sollte ein Agent seine eigenen Schlussfolgerungen nicht überprüfen. Seiner Einschätzung nach muss ein separater Validator eine echte Payload in der laufenden Anwendung ausführen, bevor ein gemeldeter Fund anerkannt wird. Das entspricht der beschriebenen Aufgabenteilung bei PageBreak: KI-gestützte Suche und Validierung ohne KI.
Darin Fredde, Senior Director of Technical Marketing Engineering bei Ridge Security, ordnete den Ansatz einem Wandel hin zu kontinuierlichen, autonomen und evidenzbasierten Sicherheitstests ein. Die Suche allein reiche nicht aus. Der Prozess müsse auch den Nachweis, die Behebung und die Überprüfung umfassen, ob die Korrektur funktioniert.
Diese Aussagen sind Einschätzungen aus der Branche und keine unabhängige Bestätigung der Leistungsfähigkeit von PageBreak. Sie belegen weder, wie umfassend der Agent Googles Anwendungen untersucht hat, noch, wie oft er Schwachstellen übersah oder ob alle validierten Funde anschließend behoben wurden.
Automatisierte Behebung ist weiterhin Zukunftsmusik
Google plant, PageBreak mit CodeMender, dem automatisierten System zur Behebung von Schwachstellen, zu verbinden. Im geplanten Ablauf würde PageBreak eine Schwachstelle validieren und CodeMender eine mögliche Codeänderung erstellen. Produktentwickler würden den vorgeschlagenen Fix anschließend prüfen, validieren und übernehmen.
Die Integration wird als Vorhaben für die Zukunft beschrieben, nicht als bereits laufende automatisierte Behebungspipeline. Die mehr als 500 Funde sollten daher nicht als mehr als 500 automatisch behobene Schwachstellen verstanden werden.
Für Googles Produktteams könnte PageBreak den Aufwand verringern, KI-generierte Meldungen manuell nachzustellen. Eine erfolgreiche Payload liefert Entwicklern einen stärkeren Beleg dafür, dass eine vermutete Schwachstelle geprüft werden sollte. Für sich genommen belegt sie jedoch weder den Schweregrad noch die Auswirkungen auf Nutzer oder die Korrektheit eines späteren Patches.
Für Nutzer und externe Administratoren enthält der Bericht keine produktspezifischen Patch-Anweisungen, Indicators of Compromise oder Workarounds. Ebenso gibt es keine Belege dafür, dass Angreifer die identifizierten Schwachstellen ausgenutzt haben. Die unmittelbare Verantwortung für die Behebung liegt daher bei Google und den Teams, die die untersuchten eigenen Dienste und Erweiterungen betreuen.
Aus Googles Darstellung geht hervor, dass PageBreak einem bestimmten internen Testmodell folgt: Ein KI-Agent sucht breit gefächert nach Schwachstellen, doch ein Ergebnis muss durch einen separaten ausführbaren Nachweis belegt werden, bevor es die Entwickler erreicht. Ob diese Architektur die behauptete niedrige Falsch-Positiv-Rate auch bei großem Umfang erreicht, ist bislang nicht unabhängig belegt.
