Tencent BrowserSkill kontrollerade bara att ett tilläggs-ID verkade äkta – vilket tillägg som helst kunde mata agenten med förfalskade sidor

Den 17 september 2026 öppnade en GitHub-användare som postade under namnet carfeii issue #273 mot Tencent's öppna källkodsprojekt BrowserSkill med ett snävt påstående: den lokala daemon som ansluter webbläsartillägget till en AI-agent kontrollerade inte vilket tillägg som anslöt, utan bara att anslutningen överhuvudtaget såg ut som ett tillägg. Tre dagar senare, den 20 september, publicerade VulnCheck fyndet som CVE-2026-94111, där en daemon beskrivs som "accepterar vilket chrome-extension-origin som helst med 32 tecken i intervallet a–p", klassificerar det som CWE-346 (fel i ursprungsvalidering) och tillskriver George Chen. Rådgivningen ger det CVSS 4.0 6.9, medel, med integritetspåverkan bedömd som hög och konfidentialitet och tillgänglighet som låg. Inget i protokollet tyder på att bristen utnyttjades: arkivet loggar ingen exploatering och betygsätter postens konfidens till A, med real_harm false. Detta är en post i AI-incidentarkivet, där varje post har sina egna källor, allvarlighetsgrad, konfidensbetyg och flagga för omstridd status.

En formatkontroll som aldrig kontrollerade identitet

Koden i centrum av posten är liten. I crates/bsk-cli/src/daemon/ws.rs, funktionen origin_allowed(), tar WebSocket-handskakningens Origin-huvud, tar bort strängen chrome-extension:// och returnerar true om det som återstår är exakt 32 tecken långt och varje tecken ligger mellan a och p. Det är hela testet. Det körs en gång, inne i callbacken för HTTP-uppgraderingen, och ett misslyckande returnerar en 403 vars meddelande lyder "Origin not in chrome-extension allow-list" — även om det, i den publicerade versionen, inte fanns någon lista att tillhöra.

Mönstret är inte godtyckligt. Chromes Manifest V3-tilläggs-ID:n består av 32 tecken hämtade från exakt dessa sexton bokstäver, så kontrollen känner korrekt igen formen hos ett verkligt tilläggs-origin. Defekten är att varje tillägg har den formen. Kontrollen frågar om anroparen ser ut som ett webbläsartillägg, aldrig om det är detta projekts webbläsartillägg, och identifieraren som den borde ha jämfört mot var redan offentlig: projektets README länkar till Chrome Web Store-listan, vars ID är hhcmgoofomhgciiibhipgmgkgnoenaoi, och Edge Add-ons-ID:t bredvid det. Ingen av strängarna förekommer någonstans i grinden.

Daemonen lyssnar på en fast lokal port, 52800, som deklareras som DEFAULT_WS_PORT i CLI:t och används utan variation i den lokala anslutningsvägen. Porten är dokumenterad, konstant och nåbar för allt som redan körs i användarens webbläsarprofil. Det lokala läget är anledningen till att rådets vektor börjar med AV:L — angriparen behöver ett fotfäste på maskinen, och PR:L anger att ett med låg behörighet räcker. Ett tillägg som är installerat i samma profil är precis ett sådant fotfäste.

Vad sätet är värt, och hur mycket av det som är etablerat

Säkerhetsmeddelandets mening om påverkan är bred: en angripare som registrerar ett skadligt tillägg som en webbläsarklient kan "avlyssna och manipulera sidinnehåll, DOM och skärmbilder som returneras till AI-agenten." Det är beskrivningen som CVE:n, GitHub-rådgivningsposten GHSA-x6f2-qp26-2xrh och arkivet alla innehåller, och den förklarar det höga integritetsbetyget i CVSS. Det är också en sammanfattning skriven av den part som tilldelade CVE:n, inte en rapport om en demonstrerad attack.

En mer noggrann redogörelse kom samma vecka, i själva ärendetråden. Den 20 september rapporterade en kommentator som skrev under namnet bb6894 att hen hade dubbelkollat koden mot main vid commit fa953dc6 (18 september) och spårat vad en främmande klient faktiskt kan nå efter handskakningen. De flesta inkommande verktygsmetoder, säger kommentaren, returnerar UnknownMethod till en WebSocket-peer; granskningsförfrågningar begränsas till klientens egna poster; och åtgärder mellan sessioner som window_closed, user_interrupt och update_interaction skyddas mot sessioner som ägs av en annan webbläsare. Det som överlever filtret är snävare och, för en agent, möjligen värre än avlyssning: ett främmande tillägg kan ta en webbläsarplats under ett av angriparen valt instance_id, och om det är den enda registrerade webbläsaren — vid en kallstart eller omstart av daemonen — tar det emot agentens verktygsförfrågningar och besvarar dem med påhittat sidinnehåll, DOM eller skärmbilder. Kommentatorn kallar detta "resultatförfalskning gentemot agenten" och "en kanal in i agentens perception". En andra effekt är en överbelastningsattack: när en äkta webbläsare också är online och ingen väljare finns kan sessionsstart misslyckas med MultipleBrowsersOnline.

Ingen av de två redogörelserna har demonstrerats offentligt. Reportern beskrev ett proof of concept som "tillgängligt på begäran"; ingen har publicerat något, och ingen exploatering finns dokumenterad. Skillnaden mellan de två redogörelserna är alltså en skillnad mellan två tolkningar av samma källfil, inte mellan en teori och en fungerande exploit – och artikeln redogör för båda i stället för att välja. Det som kan sägas utan förbehåll är att det aldrig gjordes någon andra identitetskontroll efter handskakningen, så vad porten än släppte in förblev insläppt under anslutningens livstid.

Koden visste redan

Det mest obehagliga dokumentet i det här underlaget är inte säkerhetsrådgivningen. Det är kommentaren direkt ovanför funktionen, som följde med i den taggade versionen som rådgivningen pekar på. Den markerar luckan som TODO(M10/M12), anger namnet på den tillåtelselista den avser att bygga – en mängd DaemonConfig::allowed_extension_ids som fylls från en konfigurationsfil eller ett parningsflöde – och anger sedan skälet till att den sköts upp: "acceptabel lucka i försvarsdjupet för närvarande eftersom parning sker via popupen, men ett sidoladdat tillägg på samma maskin passerar för närvarande grinden."

Läst rakt av visste underhållarna vilken anropare grinden släppte igenom, skrev ned att de visste det och släppte det. Det gör inte exponeringen större än vad säkerhetsmeddelandet säger; det gör den mindre överraskande, och det flyttar frågan från "hur kunde detta passera granskningen" till "vad skulle ha gjort den uppskjutna åtgärden brådskande". Det mildrande designantagandet är verkligt och också dokumenterat: den lokala anslutningen är opt-in. Enligt README installerar användaren tillägget, öppnar dess popup och aktiverar den lokala anslutningen, och daemonen måste köra för att något av detta ska vara åtkomligt. En profil med tillägget installerat men växeln avstängd, eller utan någon bsk-daemon som körs, är inte ett lyssnande mål.

Fem veckor senare är grinden oförändrad

Postens påverkade intervall är "till och med 0.3.0", och det är det intervall som CNA tilldelade. Det är inte slutet på historien i repot. CLI:s 0.3.0-version taggades den 17 september kl. 02:22 UTC; ärendet registrerades samma dag kl. 15:14 UTC, ungefär tretton timmar senare. Tre ytterligare CLI-versioner har släppts sedan dess – 0.3.1 den 23 september, 0.3.2 den 30 september, och 0.3.3 den 15 oktober – och funktionen origin_allowed() vid var och en av dessa taggar är samma kontroll som beskrivs ovan, med TODO fortfarande ovanför den. Huvudgrenen har den också från och med den 27 oktober.

Det finns en korrigering, men bara som ett förslag. Den 28 september, en bidragsgivare som publicerar under namnet dangzitou öppnade pull request #363 från en personlig fork, med titeln "fix(daemon): lås WS-origin-grinden till BrowserSkills egna tilläggs-ID:n." Den ersätter formtestet med en jämförelse mot de två butiks-ID:na och lägger till BSK_ALLOWED_EXTENSION_IDS som en explicit tillåtelseväg för sidoladdade och utvecklingsbyggen, vars uppackade ID:n härleds från installationssökvägen. Pull request-beskrivningen hävdar att den stänger både förfalskningsvägen och MultipleBrowsersOnlines överbelastningsattack. I skrivande stund den 27 oktober är den fortfarande öppen och inte sammanslagen, och ärendet är fortfarande öppet utan något leverantörsuttalande kopplat till det.

Den praktiska konsekvensen är att det inte finns någon version att uppgradera till som innehåller rättningen. Den som rekommenderar "uppgradera förbi 0.3.0" rekommenderar ett steg som ännu inte existerar: de senare utgåvorna är senare, inte rättade. Postens intervall bör läsas som det intervall CNA bedömde den 20 september, inte som ett påstående att 0.3.1 och senare är fria från problemet.

Vad som är fastställt, och vad som inte är det

• Fastställt: den släppta källkoden vid taggen cli-v0.3.0 innehåller en originkontroll som accepterar vilken 32-teckens a–p chrome-extension-origin som helst. Rapportören, CNA och själva filen är överens, och koden är offentlig.

• Etablerat: spärren kördes en gång, vid WebSocket-uppgraderingen, utan någon senare identitetskontroll, på en fast lokal port 52800.

• Fastställt: projektets egen källkommentar medgav att ett sidoladdat tillägg skulle godkännas och sköt upp tillåtelselistan.

• Fastställt:CVSS 4.0 6,9 och CVSS 3.1 6,6 är båda VulnCheck:s poäng, registrerade av NVD som sekundära. NVD:s egen status för posten är Deferred, vilket innebär att den har publicerat CNA:ns data utan att lägga till en analys författad av NVD.

• Fastställt: CISA:s SSVC-bedömning, daterad 21 september, anger exploatering som ingen, automatiserbar som nej och teknisk påverkan som delvis. FIRST:s EPSS sätter sannolikheten för exploatering under de kommande trettio dagarna till 0,00135, den 2,9:e percentilen, per den 26 oktober.

• Inte fastställt:någon användning i verkligheten. Ingen exploatering, inget publicerat proof of concept, inget antal påverkade installationer. Projektets repository-statistik är inte ett mått på antalet installationer, och ingen har publicerat något sådant.

• Ej fastställt:vilken påverkansbeskrivning som gäller. CNA:s "avlyssna och manipulera" och trådens "resultatförfalskning plus överbelastningsattack" beskriver olika övre gränser, och inget av dem har demonstrerats utanför kodläsning.

• Inte fastställt: att bristen upphör vid 0.3.0. Versionssträngen är CNA:s bedömning; koden är oförändrad i de tre versionerna efter den, och inget leverantörsuttalande frikänner dem.

• Motbevisat, ouppklarat: en aggregator, DevGuard, visar en signal om "försök till exploatering har upptäckts" för denna CVE utan att ange någon källa, IOC eller telemetrileverantör. Det står i motsats till CISA:s dokumenterade bedömning att ingen exploatering förekommer och till avsaknaden av någon offentlig rapport; arkivet registrerar inte heller någon exploatering. Behandla aggregatorns flagga som obestyrkt snarare än som en andra datapunkt.

Varför transporten är det intressanta målet

Merparten av vägledningen om prompt-injektion drar samma gräns: behandla hämtad sidtext som ej betrodd och behandla maskineriet som levererar den som betrott. Ett verktyg som läser en webbsida antas läsa sidan; frågan är vad sidan säger. Den här posten vänder på det. Det agenten tar emot som sidinnehåll, DOM och skärmbilder är vad klienten i andra änden av en lokal socket väljer att skicka, och den enda spärren på den socketen ställde en fråga som varje kandidat kunde svara rätt på. Om klienten är främmande har "verifiera vad sidan säger" inget kvar att verifiera mot.

Det är också därför allvarlighetsgraden hamnar där den gör i stället för högre. Attacken är lokal, den förutsätter ett tillägg som redan är installerat i profilen eller annan lokal kod, och den kräver att daemonen körs med den lokala anslutningen aktiverad. Dessa villkor är vanliga för verktygets avsedda användare och ovanliga för alla andra. Arkivets medelhöga allvarlighetsgrad och dess dokumenterade frånvaro av skada stämmer med den formen: en verklig utvidgning av förtroendet vid exakt den gräns som designen var tänkt att övervaka, utan några bevis för att någon har gått igenom den.

Det snäva praktiska råd som följer är inte någon motåtgärd som någon har publicerat, utan bara den gräns som koden lämnar kvar. Eftersom åtkomst avgörs en gång vid handskakningen på en publicerad port, bestäms den nåbara ytan av vilka tillägg som är installerade i den profil som kör daemonen, och av om den daemonen och tilläggets lokala anslutning är påslagna vid tillfället. Tills en tillåtelselista för tilläggs-ID:n finns utgör dessa två fakta hela kontrollen.

CVE-2026-94111 kommer att åldras på ett av två sätt. Antingen blir pull requesten mergad och posten blir en kort anteckning om en känd lucka som tog tid, eller så finns samma formkontroll kvar i trädet om ett år och posten citeras som ett tidigt exempel på den klass den tillhör: inte en sida som bär en fientlig instruktion, utan röret som avgör vilken sida agenten läser.