Tencent BrowserSkill prüfte nur, ob eine Erweiterungs-ID echt aussah – jede Erweiterung konnte dem Agenten gefälschte Seiten unterschieben

Am 17. September 2026 eröffnete ein GitHub-Nutzer unter dem Namen carfeii Issue #273 gegen das Open-Source-BrowserSkill-Projekt von Tencent mit einer eng gefassten Behauptung: Der lokale Daemon, der die Browsererweiterung mit einem KI-Agenten verbindet, prüfte nicht, welche Erweiterung sich verband, sondern nur, ob die Verbindung überhaupt wie eine Erweiterung aussah. Drei Tage später, am 20. September, veröffentlichte VulnCheck den Befund als CVE-2026-94111 und beschrieb einen Daemon, der „jeden chrome-extension-Ursprung mit 32 Zeichen im Bereich a-p akzeptiert“, ordnete ihn als CWE-346 (Ursprungsvalidierungsfehler) ein und nannte George Chen als Melder. Die Advisory bewertet ihn mit CVSS 4.0 6.9, mittel, wobei die Auswirkung auf die Integrität als hoch und die auf Vertraulichkeit sowie Verfügbarkeit als niedrig eingestuft werden. Nichts in den Aufzeichnungen deutet darauf hin, dass die Schwachstelle ausgenutzt wurde: Das Archiv verzeichnet keine Ausnutzung und vergibt dem Eintrag die Konfidenzstufe A, mit real_harm false. Dies ist ein Eintrag in dem AI-Incident-Archiv, in dem jeder Eintrag seine eigenen Quellen, Schweregrad, Konfidenzstufe und Disputed-Flag trägt.

Eine Formatprüfung, die nie die Identität prüfte

Der Code im Zentrum des Eintrags ist klein. In crates/bsk-cli/src/daemon/ws.rsdie Funktion origin_allowed() nimmt den Origin-Header des WebSocket-Handshakes, entfernt die Zeichenkette chrome-extension:// und gibt true zurück, wenn der Rest genau 32 Zeichen lang ist und jedes Zeichen zwischen a und p liegt. Das ist der vollständige Test. Er wird einmal ausgeführt, innerhalb des HTTP-Upgrade-Callbacks, und ein Fehlschlag liefert einen 403, dessen Meldung "Origin not in chrome-extension allow-list" lautet – obwohl es, wie veröffentlicht, keine Liste gab, in der man stehen konnte.

Das Muster ist nicht willkürlich. Die Erweiterungs-IDs von Chrome Manifest V3 bestehen aus 32 Zeichen, die genau aus diesen sechzehn Buchstaben stammen, sodass die Prüfung die Form eines echten Erweiterungsursprungs korrekt erkennt. Der Fehler besteht darin, dass jede Erweiterung diese Form hat. Die Prüfung fragt, ob der Aufrufer wie eine Browser-Erweiterung aussieht, nie aber, ob er diese Browser-Erweiterung des Projekts ist, und die Kennung, mit der sie hätte verglichen werden müssen, war bereits öffentlich: Die README des Projekts verlinkt die Chrome-Web-Store-Listung, deren ID hhcmgoofomhgciiibhipgmgkgnoenaoi lautet, und die Edge-Add-ons-ID daneben. Keine der beiden Zeichenfolgen kommt irgendwo in der Prüfung vor.

Der Daemon lauscht auf einem festen lokalen Port, 52800, der in der CLI als DEFAULT_WS_PORT deklariert und im lokalen Verbindungspfad ohne Abweichung verwendet wird. Der Port ist dokumentiert, konstant und für alles erreichbar, was bereits im Browserprofil des Benutzers läuft. Die Lokalität ist der Grund, warum der Vektor des Advisories mit AV:L beginnt — der Angreifer benötigt einen Einstiegspunkt auf dem Rechner, und PR:L hält fest, dass ein solcher mit geringen Privilegien ausreicht. Eine im selben Profil installierte Erweiterung ist genau ein solcher Einstiegspunkt.

Was der Sitz wert ist und wie viel davon gesichert ist

Der Auswirkungssatz des Advisories ist weit gefasst: Ein Angreifer, der eine bösartige Erweiterung als Browser-Client registriert, kann „Seiteninhalte, DOM und an den KI-Agenten zurückgegebene Screenshots abfangen und manipulieren“. Das ist die Beschreibung, die die CVE, der GitHub-Advisory-Eintrag GHSA-x6f2-qp26-2xrh und das Archiv allesamt enthalten, und sie erklärt die hohe Integritätsbewertung im CVSS. Es handelt sich zudem um eine Zusammenfassung der Stelle, die die CVE vergeben hat, nicht um einen Bericht über einen nachgewiesenen Angriff.

Eine sorgfältigere Darstellung erreichte dieselbe Woche, im Issue-Thread selbst. Am 20. September schrieb ein Kommentator unter dem Namen bb6894, er habe den Code gegen main bei Commit fa953dc6 (18. September) erneut geprüft und nachvollzogen, was ein fremder Client nach dem Handshake tatsächlich erreichen kann. Die meisten eingehenden Tool-Methoden, so heißt es in dem Kommentar, liefern einem WebSocket-Peer UnknownMethod zurück; Audit-Anfragen sind auf die eigenen Datensätze des Clients beschränkt; und sitzungsübergreifende Aktionen wie window_closed, user_interrupt und update_interaction sind gegen Sitzungen abgesichert, die einem anderen Browser gehören. Was diesen Filter übersteht, ist enger gefasst und für einen Agenten wohl schlimmer als eine Abfangaktion: Eine fremde Erweiterung kann unter einer vom Angreifer gewählten instance_id einen Browser-Slot belegen, und wenn sie der einzige registrierte Browser ist — ein Kaltstart oder ein Daemon-Neustart —, empfängt sie die Tool-Anfragen des Agenten und beantwortet sie mit fabrizierten Seiteninhalten, DOM oder Screenshots. Der Kommentator nennt dies „Ergebnis-Fälschung gegenüber dem Agenten“ und „einen Kanal in die Wahrnehmung des Agenten“. Ein zweiter Effekt ist ein Denial-of-Service: Wenn zusätzlich ein echter Browser online ist und kein Selektor angegeben wird, kann der Sitzungsstart mit MultipleBrowsersOnline fehlschlagen.

Keine der beiden Darstellungen wurde öffentlich nachgewiesen. Der Reporter beschrieb einen Proof of Concept als „auf Anfrage erhältlich“; niemand hat einen veröffentlicht, und es ist keine Ausnutzung dokumentiert. Der Unterschied zwischen den beiden Darstellungen ist also ein Unterschied zwischen zwei Lesarten derselben Quelldatei, nicht zwischen einer Theorie und einem funktionierenden Exploit – und der Beitrag berichtet über beide, statt sich zu entscheiden. Was sich ohne Einschränkung sagen lässt, ist, dass es nach dem Handshake nie eine zweite Identitätsprüfung gab, sodass alles, was das Gate durchgelassen hat, für die gesamte Lebensdauer der Verbindung durchgelassen blieb.

Der Code wusste es bereits

Das unangenehmste Dokument in dieser Akte ist nicht der Sicherheitshinweis. Es ist der Kommentar direkt über der Funktion, der im getaggten Release ausgeliefert wurde, auf das der Hinweis verweist. Er markiert die Lücke als TODO(M10/M12), benennt die Allow-List, die er aufbauen will – ein DaemonConfig::allowed_extension_ids-Set, das aus einer Konfigurationsdatei oder einem Pairing-Flow befüllt wird – und nennt dann den Grund für die Zurückstellung: „eine derzeit akzeptable Defense-in-Depth-Lücke, weil das Pairing über das Popup erfolgt, aber eine per Sideload installierte Erweiterung auf derselben Maschine derzeit das Gate passiert.“

Nüchtern gelesen wussten die Maintainer, welchen Aufrufer das Gate durchgelassen hatte, hielten schriftlich fest, dass sie es wussten, und lieferten aus. Das macht die Exposition nicht größer, als der Sicherheitshinweis angibt; es macht sie weniger überraschend und verschiebt die Frage von „Wie ist das durch das Review gekommen“ zu „Was hätte den aufgeschobenen Fix dringend gemacht“. Die entschärfende Designannahme ist real und ebenfalls dokumentiert: Die lokale Verbindung ist Opt-in. Laut README installiert der Nutzer die Erweiterung, öffnet ihr Popup und aktiviert die lokale Verbindung, und der Daemon muss laufen, damit irgendetwas davon erreichbar ist. Ein Profil, bei dem die Erweiterung installiert, aber der Schalter aus ist, oder bei dem kein bsk-Daemon läuft, ist kein lauschendes Ziel.

Fünf Wochen später ist das Tor unverändert.

Der betroffene Bereich des Datensatzes ist „bis einschließlich 0.3.0“, und das ist der Bereich, den die CNA zugewiesen hat. Damit ist die Geschichte im Repository nicht zu Ende. Das CLI-Release 0.3.0 wurde am 17. September um 02:22 UTC getaggt; das Issue wurde am selben Tag um 15:14 UTC eingereicht, etwa dreizehn Stunden später. Seitdem sind drei weitere CLI-Releases erschienen – 0.3.1 am 23. September, 0.3.2 am 30. September und 0.3.3 am 15. Oktober – und die Funktion origin_allowed() ist an jedem dieser Tags dieselbe oben beschriebene Prüfung, mit dem TODO nach wie vor darüber. Der Main-Branch enthält sie ebenfalls mit Stand vom 27. Oktober.

Eine Korrektur existiert, aber nur als Vorschlag. Am 28. September eröffnete ein Beitragender mit dem Namen dangzitou Pull Request #363 aus einem persönlichen Fork mit dem Titel „fix(daemon): pin WS origin gate to BrowserSkill's own extension ids“. Er ersetzt den Formtest durch einen Vergleich mit den beiden Store-IDs und fügt BSK_ALLOWED_EXTENSION_IDS als expliziten Zulassungspfad für Sideload- und Entwicklungs-Builds hinzu, deren entpackte IDs vom Installationspfad abgeleitet werden. Der Text des Pull Requests behauptet, er schließe sowohl den Fälschungspfad als auch den MultipleBrowsersOnline-Denial-of-Service. Mit Stand 27. Oktober ist er weiterhin offen und nicht gemergt, und das Issue bleibt offen, ohne dass eine Stellungnahme des Anbieters dazu vorliegt.

Die praktische Konsequenz ist, dass es keine Version gibt, auf die man aktualisieren könnte und die den Fix enthält. Wer dazu rät, „über 0.3.0 hinaus zu aktualisieren“, rät zu einem Schritt, den es noch nicht gibt: Die späteren Releases sind später, nicht behoben. Der Bereich im Datensatz sollte als der Bereich gelesen werden, den die CNA am 20. September bewertet hat, nicht als Aussage, dass 0.3.1 und später sauber sind.

Was gilt als gesichert und was nicht

• Festgestellt:Der veröffentlichte Quellcode unter dem Tag cli-v0.3.0 enthält eine Origin-Prüfung, die jede 32-stellige Chrome-Extension-Origin im Bereich a–p akzeptiert. Der Meldende, die CNA und die Datei selbst stimmen überein, und der Code ist öffentlich.

• Festgelegt: Die Prüfung erfolgte einmalig beim WebSocket-Upgrade, ohne spätere Identitätsprüfung, auf einem festen lokalen Port 52800.

• Festgestellt: Der eigene Quellcode-Kommentar des Projekts räumte ein, dass eine per Sideload installierte Erweiterung durchgelassen würde, und vertagte die Allowlist.

• Festgestellt: CVSS 4.0 6.9 und CVSS 3.1 6.6 sind beide Bewertungen von VulnCheck, die von NVD als sekundär erfasst wurden. Der eigene Status von NVD für den Eintrag ist „Deferred“, was bedeutet, dass NVD die Daten der CNA veröffentlicht hat, ohne eine von NVD verfasste Analyse hinzuzufügen.

• Festgestellt:Die SSVC-Bewertung von CISA vom 21. September verzeichnet Ausnutzung als „keine“, Automatisierbarkeit als „nein“ und technische Auswirkung als „teilweise“. Das EPSS von FIRST beziffert die Wahrscheinlichkeit einer Ausnutzung in den nächsten dreißig Tagen mit Stand 26. Oktober auf 0,00135, das 2,9. Perzentil.

• Nicht belegt: jegliche reale Nutzung. Keine Ausnutzung, kein veröffentlichter Proof of Concept, keine Zahl betroffener Installationen. Die Repository-Metriken des Projekts sind keine Installationszahl, und niemand hat eine veröffentlicht.

• Nicht belegt: welche Impact-Bewertung zutrifft. Das „Abfangen und Manipulieren" der CNA und die „Ergebnisfälschung plus Denial of Service" des Threads beschreiben unterschiedliche Obergrenzen, und keines von beiden wurde außerhalb des Codelesens nachgewiesen.

• Nicht belegt: dass die Schwachstelle bei 0.3.0 endet. Der Versionsstring ist die Einschätzung der CNA; der Code ist in den drei darauffolgenden Releases unverändert, und keine Herstelleraussage entlastet sie.

• Widersprüchlich, ungeklärt:Ein Aggregator, DevGuard, zeigt für diese CVE ein Signal „Es wurden Ausnutzungsversuche festgestellt“ an, ohne eine Quelle, einen IOC oder einen Telemetrieanbieter zu nennen. Das steht im Widerspruch zu CISAs dokumentierter Einschätzung, dass keine Ausnutzung erfolgt sei, und zum Fehlen eines öffentlichen Berichts; auch das Archiv verzeichnet keine Ausnutzung. Behandeln Sie die Kennzeichnung des Aggregators als unbegründet statt als zweiten Datenpunkt.

Warum der Transport das interessante Ziel ist

Die meisten Leitlinien zur Prompt-Injection ziehen dieselbe Grenze: Abgerufener Seitentext gilt als nicht vertrauenswürdig, die Maschinerie, die ihn liefert, als vertrauenswürdig. Bei einem Tool, das eine Webseite liest, wird angenommen, dass es die Seite liest; die Frage ist, was auf der Seite steht. Dieser Eintrag kehrt das um. Was der Agent als Seiteninhalt, DOM und Screenshots erhält, ist das, was der Client am anderen Ende eines lokalen Sockets zu senden beschließt, und die einzige Zugangskontrolle an diesem Socket stellte eine Frage, die jeder Kandidat richtig beantworten konnte. Wenn der Client fremd ist, bleibt für „überprüfe, was auf der Seite steht“ nichts mehr, woran man es überprüfen könnte.

Das ist auch der Grund, warum die Schweregrad-Einstufung genau dort liegt, wo sie liegt, und nicht höher. Der Angriff ist lokal, er setzt eine bereits im Profil installierte Erweiterung oder anderen lokalen Code voraus und erfordert, dass der Daemon mit aktivierter lokaler Verbindung läuft. Diese Bedingungen sind für die vorgesehenen Nutzer des Tools normal und für alle anderen ungewöhnlich. Die mittlere Schweregrad-Einstufung des Archivs und die dokumentierte Abwesenheit von Schaden passen zu diesem Bild: eine tatsächliche Ausweitung des Vertrauens genau an der Grenze, die das Design eigentlich absichern sollte, ohne Belege dafür, dass jemand sie durchschritten hat.

Der folgende eng gefasste praktische Rat ist keine Maßnahme zur Risikominderung, die irgendjemand veröffentlicht hat, sondern nur die Grenze, die der Code bestehen lässt. Da die Zulassung einmalig beim Handshake an einem veröffentlichten Port entschieden wird, wird die erreichbare Angriffsfläche dadurch bestimmt, welche Erweiterungen in dem Profil installiert sind, das den Daemon ausführt, und dadurch, ob dieser Daemon und die lokale Verbindung der Erweiterung zu diesem Zeitpunkt aktiviert sind. Bis eine Allowlist für Erweiterungs-IDs verfügbar ist, sind diese beiden Tatsachen die gesamte Steuerung.

CVE-2026-94111 wird auf eine von zwei Arten altern. Entweder wird der Pull Request gemergt und der Eintrag wird ein kurzer Eintrag über eine bekannte Lücke, deren Schließung eine Weile dauerte, oder dieselbe Shape-Prüfung ist in einem Jahr noch im Tree und der Eintrag wird als frühes Beispiel für die Klasse zitiert, zu der er gehört: nicht eine Seite, die eine feindliche Anweisung trägt, sondern die Pipe, die entscheidet, welche Seite der Agent liest.