BragJack: Eine Browser-Erweiterung kapert die KI-Agenten in fünf großen Browsern

Am 16. September 2026 veröffentlichte Gal Weizman, Sicherheitsforscher bei Forever Security, BragJack: einen Proof of Concept, bei dem eine gewöhnliche Browsererweiterung – kein Zero-Day, kein gejailbreaktes Modell, kein kompromittierter Anbieterserver – die Kontrolle über die KI-Agenten übernahm, die in fünf auf Chromium basierenden Produkten integriert sind: Gemini Live in Google Chrome, Copilot in Microsoft Edge, Opera Neon, Perplexity Comet und Claude in Chrome. Die Erweiterung verlangte nichts Exotisches. Sie nutzte Content-Scripts und die declarativeNetRequest-API von Chromium – dieselben zwei Berechtigungen, die in den meisten Werbeblockern vorhanden sind –, um den privaten Kanal zu erreichen, den die eigene Website jedes Anbieters nutzt, um seinem Agenten Anweisungen zu senden. Weizman berichtet, dass Comet die umfassendste Kompromittierung war, dass Google und Microsoft Korrekturen ausgeliefert und CVE-2026-0628 sowie CVE-2026-55945 zugewiesen haben und dass keine Angriffe in freier Wildbahn beobachtet wurden. Es ist als Schwachstelle mit hohem Schweregrad katalogisiert in dem KI-Vorfallarchiv, wo jeder Eintrag seine Quellen, seine Vertrauensstufe und sein Kennzeichen für bestrittene Angaben enthält.

Die Erweiterung hat das Modell nicht kaputt gemacht. Sie hat den Kanal kaputt gemacht.

Alle fünf Produkte sind auf dieselbe Weise aufgebaut – laut einem technischen Begleitdokument, das Forever Security am selben Tag veröffentlichte. Jedes hat einen „Körper“ im Browser, der Tabs öffnen, lokale Dateien lesen, Screenshots aufnehmen und auf Seiten klicken kann, sowie ein „Gehirn“ außerhalb des Browsers, das entscheidet, was der Körper tun soll: Googles Gemini-Server für Chrome, die perplexity.ai-Web-App für Comet, copilot.microsoft.com für Edge, Anthropics Backend für Claude in Chrome. Der Körper ist so konzipiert, dass er Anweisungen von genau einer Origin akzeptiert: der eigenen Website des Anbieters. Diese eine vertrauenswürdige Origin ist das gesamte Sicherheitsmodell. Sie ist auch das, was eine Browsererweiterung berühren darf.

Chromium gewährt jeder installierten Erweiterung zwei Fähigkeiten, die nahezu universell sind. Ein Content-Script ermöglicht es ihr, JavaScript innerhalb einer Seite auszuführen. Die declarativeNetRequest-API, kurz DNR, ermöglicht es ihr, Netzwerkverkehr umzuschreiben – einen Antwort-Header zu entfernen, eine Skriptanfrage auf einen anderen Server umzuleiten. Browser betreiben echten Aufwand, diese beiden Fähigkeiten von privilegierten Oberflächen fernzuhalten, und vier der fünf Anbieter hatten einen Teil dieser Arbeit bereits erledigt. Was Weizman in jedem Fall fand, war eine Lücke in dem Teil, den sie offen gelassen hatten.

Er nennt die allgemeine Technik DinNeR Serving: DNR verwenden, um die Sicherheitsheader einer vertrauenswürdigen Seite zu schwächen, und dann DNR erneut verwenden, um eine der Skriptanfragen dieser Seite auf einen vom Angreifer kontrollierten Server umzuleiten. Die Seite führt nun Angreifercode aus, glaubt aber weiterhin, die Seite des Anbieters zu sein, und der Agent glaubt weiterhin, vom Anbieter zu hören. In Chrome berichtet Weizman, dass Erweiterungen korrekt daran gehindert wurden, ein Content-Skript oder einen Debugger an die eingebettete Gemini-App anzuhängen, und dass DNR der einzige Mechanismus war, auf den Chromium denselben Schutz innerhalb einer WebView nicht ausgedehnt hatte. Das Entfernen der Content-Security-Policy und das Lockern der Dokumentisolationsrichtlinie reichte aus, um ein von gstatic.com ausgeliefertes Skript durch sein eigenes zu ersetzen, und von innerhalb von chrome://glic konnte er dann die eigenen Nachrichtentypen des Browser-Agenten direkt senden – einen Tab unter einer file:///-Adresse erstellen, ihn als Text, PDF oder Screenshot auslesen und die E-Mail-Adresse und das Bild des angemeldeten Profils abrufen.

Was dieselbe Erweiterung bewirkte – Browser für Browser

Die Erweiterung bestand nicht aus fünf Tools. Sie bestand aus einem Manifest, das declarativeNetRequest und breiten Host-Zugriff anforderte, plus einer separaten Regelsdatei für jedes Ziel; zwischen den Angriffen änderten sich nur die Regeln. Die eigene Tabelle von Forever Security ist die klarste Zusammenfassung dessen, was jede Kette erreichte, und ist unten wiedergegeben. Die wichtigste Zeile ist Agent hijack: In vier der fünf Fälle war das demonstrierte Ergebnis nicht Datendiebstahl, sondern die Kontrolle über einen Agenten, der im Namen des Nutzers innerhalb angemeldeter Sitzungen handeln konnte.

Diese browserspezifischen Ketten sind der Teil von BragJack, den keine zweite Partei überprüft hat. BleepingComputer, Cyber Security News, die Cloud Security Alliance und Thailands nationales CERT haben alle über die Offenlegung berichtet, und alle beschreiben die Mechanismen auf dieselbe Weise, doch jede dieser Stellen beschreibt Forever Securitys Bericht, statt ihn zu testen. Die ThaiCERT-Mitteilung vom 21. September 2026 nennt BleepingComputer als ihre Quelle. Was folgt, ist daher Weizmans Darstellung seines eigenen Proof of Concept – was eine Offenlegung eben ist – und kein unabhängig reproduziertes Ergebnis.

Perplexity Comet: eine Testdomäne, die noch auf der Vertrauensliste steht

Comet schnitt nach der eigenen Rangliste des Forschers am schlechtesten von den fünf ab, und der Grund ist struktureller Natur und nicht ein Programmierfehler. Perplexity hat einen Browser gebaut, in dem der Agent die eigenen Berechtigungen des Browsers innehat, sodass ein gekaperter Agent alle davon erbt. Perplexity hatte außerdem die Abwehrarbeit geleistet, die die anderen übersprungen hatten: Erweiterungen werden vollständig daran gehindert, auf perplexity.ai zu laufen, weshalb Weizman sagt, dass Werbeblocker dort nicht funktionieren.

Die Lücke bestand in der Liste der Ursprünge, von denen die Agent-Erweiterung Befehle annehmen würde. Laut der technischen Beschreibung enthielt diese Liste zehn Einträge, nicht einen – perplexity.ai und seine www-Variante sowie Testing-, Staging- und Preview-Hosts sowohl auf perplexity.com als auch auf perplexity.ai. Nur die Produktions-Hosts waren gehärtet worden. testing.perplexity.com akzeptierte weiterhin Content-Skripte. Das verbleibende Hindernis war, dass jede dieser Domains mit einer 302-Weiterleitung zu perplexity.ai antwortete, sodass der Browser nie lange genug auf der Testseite landete, damit sich ein Skript anhängen konnte. Eine DNR-Regel, die den Location-Header löscht, beseitigt dieses Hindernis, und das Content-Skript kann dann direkt über den Runtime-Messaging-Kanal, den die Agent-Erweiterung bereitstellt, mit ihr kommunizieren.

Was der Agent auf Anfrage laut Weizman tun würde, war: den Browserverlauf auflisten, beliebige URLs einschließlich file:///-Pfaden öffnen und Screenshots sichtbarer Tabs aufnehmen – und dann über einen Befehl, der einen Agentenlauf aus einem bereitgestellten Prompt startet, fast alles tun, was ein Nutzer tun könnte. Sein Demonstrationsprompt forderte Comet auf, perplexity.ai zu besuchen, die letzten fünf E-Mails zusammenzufassen und die Zusammenfassung an eine zweite Adresse zu senden. Er berichtet außerdem, dass file:///-Zugriff in einer früheren Comet-Offenlegung behandelt worden sei, die Korrektur aber groß-/kleinschreibungssensitiv gewesen sei, sodass FiLe:///etc/hosts weiterhin funktioniert habe. Nichts davon erscheint in einem Perplexity-Advisory; das Unternehmen zahlte eine Bug-Bounty und hat laut Forever Security das ihm gezeigte Verhalten behoben.

Microsoft Edge: eine Marketingseite, ein synthetischer Klick und ein Wettlauf

Edge war das einzige Ziel, das sich zur Wehr setzte, und es ist das lehrreichste der fünf. Microsoft hatte seinen Agenten in einen „Think“-Modus, der Prompts entgegennimmt, und einen „Do“-Modus, der auf Seiten agiert, aufgeteilt, wobei die beiden absichtlich nicht gleichzeitig ausgeführt werden können – ein echter Sicherheitsmechanismus und einer, der Prompt-Forcing konstruktionsbedingt unterbindet. Microsoft hatte außerdem die Marketingseite unter microsoft.com/edge, die den Agenten demonstriert, gehärtet und ihre privilegierte Funktion zum Senden von Prompts an drei separate Bedingungen geknüpft: eine Content-Security-Policy, die nicht einfach gelöscht werden konnte, weil das privilegierte Objekt nie erstellt wird, wenn der Header fehlt, ein frisches User-Gesture-Token und eine Funktion, die das Prompt-Feld befüllt, statt es zu senden.

Weizmans Darstellung zufolge wurde jede Bedingung durch einen anderen Trick erfüllt. Statt die CSP zu löschen, erweiterte er ihre frame-ancestors-Direktive, sodass jede .com-Website einbetten durfte. Für das Gesten-Token fügte er die debugger-Berechtigung zum Manifest hinzu und löste einen synthetischen Klick aus, den Chromium als organische Geste akzeptiert. Für das Race deaktivierte er das Agent-Tools-Flag, rief die Funktion zum Senden des Prompts auf und aktivierte das Flag dann wieder, während der Agent noch entschied, ob er handeln durfte. Die Einstellung war aus, in dem Moment, als der Prompt erzwungen wurde, und an, in dem Moment, als die Berechtigungsprüfung lief. Dafür hat Microsoft CVE-2026-55945 vergeben.

Das Geld entspricht der Arbeit: Forever Security verbucht 3.000 US-Dollar für den Edge-Chromium-Fund und 2.000 US-Dollar für die Race Condition, insgesamt 5.000 US-Dollar – Dritter von fünf, hinter den jeweils 7.000 US-Dollar von Google und Perplexity.

Opera Neon und Claude in Chrome: die beiden Einfachen

Opera Neon erforderte von den fünf am wenigsten Aufwand. Sein Agent nimmt Befehle von opera.com entgegen, und anders als Google und Perplexity, die beide verhinderten, dass Erweiterungen Content-Scripts an den vertrauenswürdigen Origin ihres Agenten anhängen, hatte Opera nicht verhindert, dass Erweiterungen ein Content-Script an diese Domain anhängen; daher konnte Weizmans Erweiterung dort ein Script injizieren und den Nachrichtenkanal des Agenten direkt mit einem beliebigen Prompt aufrufen. Durch das Entfernen der CSP ließ sich derselbe Angriff in einem unsichtbaren Frame auf jeder Seite einbetten. Sein Bericht ergänzt ein Detail, das in keiner anderen Berichterstattung vorkommt: Opera teilte ihm mit, dass man den Fehler etwa zur selben Zeit unabhängig gefunden habe, und zahlte die Prämie von 900 US-Dollar trotzdem. Das ist eine Herstellerangabe, die der Forscher wiedergibt, kein Befund, für den eine der beiden Parteien Belege veröffentlicht hat.

Claude in Chrome ist der Sonderfall, denn es ist eine Erweiterung und kein Browser, und Forever Security sagt es ganz offen: Dass eine Erweiterung eine andere ausnutzt, ist ein geringeres Risiko, als wenn eine Erweiterung den Browser ausnutzt, in dem sie läuft. Der Mechanismus war eine Marketingseite auf claude.ai, die beliebige Prompts an die Seitenleiste übergeben konnte, kombiniert mit einem Content-Script, das bei Klicks auf einen Onboarding-Button ausgelöst wurde und den Prompt aus einem Datenattribut auslas. Weizman setzte die ID und das Attribut des Body der Seite selbst, löste über die Debugger-Berechtigung einen synthetischen Klick aus, und die Seitenleiste öffnete sich mit seinem Prompt darin. Anthropic stufte dies als mittleren Schweregrad ein, zahlte eine Bug-Bounty und erkannte das Unternehmen laut Forever Security als ersten Melder dieses konkreten Fundes an. Die beiden Forever-Beiträge weichen bei der Höhe leicht voneinander ab – 600 $ in der Haupttabelle, 500 $ im technischen Begleitbeitrag.

Was in den eigenen Unterlagen der Anbieter tatsächlich steht

Nur zwei der fünf führten zu einem öffentlichen Schwachstellendatensatz, und beide sind Monate älter als der BragJack-Bericht. Googles Versionshinweis für den Stable-Kanal vom 6. Januar 2026 listet „High CVE-2026-0628: Unzureichende Durchsetzung von Richtlinien im WebView-Tag. Gemeldet von Gal Weizman am 2025-11-23“ und nennt 143.0.7499.192/.193 für Windows und Mac sowie 143.0.7499.192 für Linux. Der Eintrag in der National Vulnerability Database, veröffentlicht am 7. Januar 2026, beschreibt die Schwachstelle als Möglichkeit für einen Angreifer, „der einen Benutzer dazu gebracht hat, eine bösartige Erweiterung zu installieren, über eine präparierte Chrome-Erweiterung Skripte oder HTML in eine privilegierte Seite einzuschleusen“, klassifiziert sie als CWE-862, fehlende Autorisierung, und weist einen CVSS-3.1-Score von 8.8 auf. Dieser Score stammt nicht von Google: Er kommt aus der Anreicherung des Datensatzes durch CISA, wie The Hacker News anmerkte, und Googles eigener Hinweis bewertet das Problem als High.

Microsofts Eintrag ist noch enger gefasst. CVE-2026-55945, veröffentlicht am 3. Juli 2026, ist eine CWE-362-Race-Condition mit einem CVSS-3.1-Score von 4.2, Schweregrad Mittel. Microsofts Auswirkungserklärung lautet „Information Disclosure“, und die eigene FAQ von Microsoft besagt, dass es sich bei den offengelegten Informationen um Dateiinhalte handelt. Der behobene Build ist 150.0.4078.48, veröffentlicht am selben Tag, und der Exploit-Status des Eintrags lautet „Publicly Disclosed: No; Exploited: No“. Nichts in diesem Dokument beschreibt, dass ein Agent über beliebige Websites gesteuert wird, was die von Weizman gemeldete Auswirkung ist. Beide Aussagen können gleichzeitig zutreffen – die CVE deckt die Race Condition ab, während die auf der Marketingseite beschriebene Fähigkeit ein zweiter, separat vergüteter Fund war –, doch kein bisher veröffentlichtes Herstellerdokument beschreibt die End-to-End-Kette.

„Null Klicks“ bedeutet nach der Installation der Erweiterung

Der Satz in der Tabelle von Forever Security ist korrekt und leicht misszuverstehen. BragJack ist kein Drive-by. BleepingComputer, die Cloud Security Alliance und ThaiCERT nennen alle zuerst dieselbe Voraussetzung: Die schädliche Erweiterung muss bereits installiert sein. Die Forschung zeigt: Sobald sie installiert ist, ist kein weiterer Klick nötig — die Erweiterung gelangt zum Agenten, egal auf welcher Seite der Nutzer sich gerade befindet, ohne dass etwas angezeigt wird. Bei Comet und Opera Neon war dafür überhaupt keine Interaktion erforderlich; bei Edge und Claude in Chrome wurde der vom Agenten verlangte Klick von der Erweiterung über die Debugger-Berechtigung synthetisiert, sodass ihn auch der Nutzer nicht lieferte.

Diese Unterscheidung bestimmt die tatsächliche Exposition in der Praxis. Der Angriff erfordert entweder einen Nutzer, der etwas Bösartiges installiert, oder eine im Store bereits vertrauenswürdige Erweiterung, die später bösartig wird, und beides ist keine hohe Hürde – deshalb konzentrieren sich die Empfehlungen von CSA auf ein Erweiterungsinventar und darauf, declarativeNetRequest- und debugger-Berechtigungen als privilegiert zu behandeln. Deshalb hat auch niemand einen Angriff gemeldet: Ein Proof of Concept, für den eine feindliche Erweiterung installiert sein muss, ist eine Demonstration einer Fähigkeit, keine Kampagne.

Prompt-Forcing und das damit verbundene Verkaufsargument

Die Terminologie ist wichtig, weil sie beschreibt, wo die Verteidigungslinien lagen. Prompt Injection versteckt Anweisungen in Inhalten, die ein Modell ohnehin liest; Training und Filter des Modells sind die vorgesehene Absicherung. Was Weizman tat, war, den gesamten Prompt zu schreiben, den Zeitpunkt seines Eintreffens zu wählen und weiterhin Follow-ups zu senden – von einer Quelle, der zu vertrauen der Agent konzipiert wurde. Sicherheitsfilterung auf Modellebene wird nie relevant, weil nichts in dem Austausch wie ein Angriff aussieht. Forever Security nennt dies Prompt Forcing.

Die Schlussfolgerung, die das Unternehmen daraus zieht, ist, dass Endpoint Detection es ebenfalls nicht sehen kann, da kein schädlicher Code ausgeführt wird: Legitimer Software wird gesagt, etwas zu tun, wozu sie berechtigt ist. Diese Behauptung ist mit einem Produktwerbungsargument verknüpft – Forever Security verkauft einen KI-nativen Endpoint-Agent, und beide Berichte enden mit einer Empfehlung dafür. Die Beobachtung, dass ein gekaperter Agent keine Malware-Signatur erzeugt, hängt nicht davon ab, etwas zu kaufen, aber sie ist das Argument des Forschers und kein gemessenes Ergebnis, und keine unabhängige Instanz hat getestet, ob irgendein Endpoint-Produkt diese Ketten erkennt.

Was ist gesichert, und was beruht auf einem einzigen Forscher?

Das Archiv führt diesen Eintrag als Schwachstelle, Schweregrad hoch, Region global, Konfidenz B – dokumentiert, aber aus einer Einzel- oder Sekundärquelle –, nicht umstritten und ohne dokumentierten tatsächlichen Schaden. Diese Einstufung beschreibt die Beweislage und nicht den Schweregrad der Fehler, und diese Trennung zieht sich klar durch die gesamte Darstellung.

Belegt – in dem Sinne, dass ein Anbieter oder eine First-Party-Aufzeichnung dies angibt:

• Google hat am 6. Januar 2026 einen Chrome-Fix in 143.0.7499.192 und .193 ausgeliefert und Gal Weizman als Melder eines auf den 23. November 2025 datierten Berichts genannt. Das steht in Googles eigenem Versionshinweis, nicht in der Schilderung des Forschers dazu.

{{1}}CVE-2026-0628{{/1}} existiert, wird von Google als „High“ und durch die CISA-Anreicherung im NVD-Eintrag mit 8,8 bewertet und ist als unzureichende Durchsetzung von Richtlinien in einem WebView-Tag eingestuft.

• Microsoft veröffentlichte CVE-2026-55945 am 3. Juli 2026 als mittelschwere Race Condition (4.2), die zur Offenlegung von Informationen führt, behoben in Edge 150.0.4078.48, wobei keine Ausnutzung verzeichnet wurde.

• Die SSVC-Bewertungen von CISA in beiden NVD-Einträgen lauten „exploitation: none“, und niemand – weder Hersteller, Forschende noch Berichterstattende – hat einen Angriff in freier Wildbahn behauptet. Das ist ein Fehlen von Meldungen, was nicht dasselbe ist wie ein Beweis für Abwesenheit, aber es ist der Stand der Aufzeichnungen sechs Wochen nach der Veröffentlichung.

Sich allein auf das Konto von Forever Security verlassen:

Jede browserspezifische Exploit-Kette, einschließlich der DNR-Regelsätze, der Entfernung der Weiterleitung von testing.perplexity.com, der Edge-Marketingseiten-Sequenz und des Klicks auf die Claude-Onboarding-Schaltfläche. Die CVEs beschreiben zwei Mechanismen; sie beschreiben diese Ketten nicht.

• Die vollständige Liste der Auswirkungen für Comet – Browserverlauf, lokale Dateizugriffe, Profildaten, Screenshots – und die konkrete Behauptung, dass einem gekaperten Comet-Agenten in einfachem Englisch gesagt werden könnte, E-Mails zusammenzufassen und weiterzuleiten. BleepingComputer berichtet dies als Demonstration des Forschers; keine Erklärung von Perplexity bestätigt oder bestreitet dies.

• Chromes Kamera- und Mikrofonzugriff, den BleepingComputer als „potenziell“ erreichbar beschreibt und den die Forever-Tabelle als erreicht aufführt.

• Die Bounty-Gesamtsumme. Forever Security gibt über fünf Anbieter hinweg etwa 20.000 US-Dollar an; die eigenen produktbezogenen Zahlen summieren sich auf 20.500 US-Dollar – ein Punkt in der Rechnung, den auch The Hacker News anführte. Die Angabe zu Claude in Chrome unterscheidet sich zwischen den beiden Beiträgen des Unternehmens. Die Angabe „mehr als 20.000 US-Dollar“ von BleepingComputer ist mit beiden Lesarten vereinbar.

• Dass Prompt Forcing eine neue Angriffsklasse sei und nicht bloß ein Name für eine Familie von Autorisierungsfehlern. Das ist eine Deutungsbehauptung, und die Cloud Security Alliance – die diesen Begriff übernommen hat – beschreibt das zugrunde liegende Muster als eine architektonische Lücke, die sich durch alle Anbieter zieht, nicht als eine neue Technik mit eigenen Mechanismen.

Drei der fünf Anbieter veröffentlichten überhaupt nie einen Schwachstellendatensatz. CSA merkt an, dass Perplexity, Opera und Anthropic das spezifische Proof of Concept anerkannt und behoben haben, ohne Advisories, die mit denen von Google und Microsoft vergleichbar sind, und Forever Security nennt für diese drei keine Behebungsdaten. Es wurde keine unabhängige Reproduktion einer BragJack-Kette veröffentlicht; Cyber Security News und ThaiCERT geben beide die Offenlegung wieder, und ThaiCERT zitiert BleepingComputer.

Was hat sich nach der Offenlegung geändert?

Für Chrome- und Edge-Nutzer lautet die praktische Antwort, dass am 16. September nichts geändert werden musste: Die Korrekturen wurden im Januar und Juli ausgeliefert, und wer Chrome 143.0.7499.192 oder neuer bzw. Edge 150.0.4078.48 oder neuer nutzte, war bereits gepatcht. Diese zeitliche Abfolge sollte man sich vor Augen halten. Die Fehler waren bereits Monate behoben, bevor die Technik, die sie miteinander verband, einen Namen hatte – was die übliche Form koordinierter Offenlegung ist und auch der Grund dafür, warum die Schlagzeile schlimmer klingt als der Patch-Status.

Für Comet, Opera Neon und Claude in Chrome ist die Lage weniger klar. Jeder Anbieter zahlte ein Kopfgeld und hat laut Forever Security und CSA das gezeigte Verhalten adressiert. Keiner veröffentlichte einen versionsgebundenen Hinweis oder ein Datum, daher gibt es keine Build-Nummer, gegen die Nutzer prüfen könnten, sondern nur die allgemeine Anweisung, aktuell zu bleiben. CSAs Empfehlung für Organisationen lautet, Erweiterungen mit declarativeNetRequest- oder Debugger-Berechtigungen zu inventarisieren, agentische Browser auf Profile ohne authentifizierte Sitzungen für E-Mail, Code oder Finanzen zu beschränken und Anbieter zu fragen, wie sie synthetische von echten Nutzereingaben trennen. BleepingComputers Rat für Einzelpersonen ist einfacher: den Browser aktualisiert halten, Erweiterungen entfernen, die man nicht erkennt, und „alle Ihre Daten auf allen Websites lesen und ändern“ als das Warnsignal zu behandeln, das es ist.

Die ungelöste Frage ist nicht, ob fünf Bugs behoben wurden. Sie ist, ob die ihnen zugrunde liegende Designannahme korrigiert wurde. Jedes dieser Produkte behandelte einen First-Party-Web-Origin als vertrauenswürdigen Ort, an dem ein privilegierter lokaler Agent Befehle entgegennehmen kann – in einem Browser, in dem jede installierte Erweiterung umschreiben kann, was dieser Origin sagt. Forever Security argumentiert, die Lösung sei Endpoint-Level-Monitoring; CSA plädiert für Origin-Validierung, Least Privilege, isolierte Befehlskanäle und nicht fälschbare Eingabeherkunft. Keiner der fünf Anbieter hat öffentlich – in keinem der für diesen Beitrag geprüften Dokumente – gesagt, dass er die Architektur geändert habe statt nur den konkreten Weg, den Weizman ging.

Das Datum des Eintrags ist das Datum der Erklärung, nicht das Datum der Fehler – und genau diese Lücke ist die Geschichte. Eine einzige Erweiterung, zwei Berechtigungen, die Werbeblocker seit Jahren innehaben, und fünf Anbieter, die jeweils glaubten, ihre eigene Website sei der eine Ort, an dem ein Angreifer nicht Fuß fassen konnte.