Sex zero-days på åtta månader, en belöning på 1 000 dollar

Googles Chrome-team släppte byggena 152.0.7977.82 och .83 för Windows och macOS samt 152.0.7977.82 för Linux den 3 och 4 september 2026 för att åtgärda CVE-2026-85046, en type confusion-brist i V8-motorn för JavaScript och WebAssembly som Google bekräftade redan utnyttjades i praktiken. Felet gör det möjligt för en manipulerad webbsida att lura V8:s kompilator att ge en angripare godtycklig läs- och skrivåtkomst till webbläsarens heap, vilket öppnar en väg till fjärrkörning av kod inuti Chromes sandlåda. Forskaren Salvatore Gulizia rapporterade felet den 4 augusti 2026 och fick en belöning på 1 000 dollar. Google höll tillbaka tekniska detaljer tills fixen hade nått de flesta användare, vilket är standardpraxis för en aktivt utnyttjad sårbarhet. Detta är den sjätte aktivt utnyttjade zero-dayn i Chrome som patchats under 2026, och var och en av dem fick en CVSS-poäng på 8.8 och krävde en akut patch utanför den ordinarie utgivningscykeln i stället för att vänta på Chromes vanliga uppdateringståg.

Månad (2026)CVEKomponentCVSS
FebruariCVE-2026-2441CSS (use-after-free)8.8
MarsCVE-2026-3909Skia (out-of-bounds write)8.8
MarsCVE-2026-3910V88.8
AprilCVE-2026-5281Dawn / WebGPU (use-after-free)8.8
JuniCVE-2026-11645V8 (out-of-bounds access)8.8
SeptemberCVE-2026-85046V8 (type confusion)8.8

Åtta dagar innan klockan började ticka

Googles egen tidslinje visar det avgörande glappet: bolaget avslöjade och patchade CVE-2026-85046 den 3 och 4 september, åtta dagar innan ikraftträdandet av den artikel i EU:s Cyber Resilience Act som skulle ha krävt en formell rapport om exakt denna typ av händelse. Från den 11 september 2026 behandlar artikel 14 programvara som Chrome som en produkt med digitala element, och så snart en leverantör får kännedom om att en sårbarhet aktivt utnyttjas måste den skicka en tidig varning till en nationell kontaktpunkt och till ENISA, EU:s cybersäkerhetsmyndighet, inom 24 timmar, en fylligare anmälan inom 72 timmar och en slutrapport inom 14 dagar efter att fixen blivit tillgänglig. Hade Google upptäckt och avslöjat samma fel den 12 september i stället för den 3 september, skulle exakt samma händelsekedja - en forskare rapporterar ett V8-fel, Google bekräftar utnyttjande i praktiken, och Google släpper en akut patch - ha blivit Cyber Resilience Act's första riktiga testfall i stället för en rutinmässig varning. Sex utnyttjade zero-days i Chrome under åtta månader 2026 gör en sjunde, som dyker upp efter att lagens tänder sitter på plats, till en fråga om när snarare än om.

Beslutsregeln för den som äger patchpolicyn

Den praktiska lärdomen för alla EU-företag är att inte vänta på en myndighetsanmälan för att få veta om nästa zero-day i Chrome, eftersom Googles egna versionsanteckningar sa att de patchade byggena skulle rullas ut under de kommande dagarna och veckorna även efter att patchen fanns tillgänglig, vilket betyder att det är hastigheten på den automatiska uppdateringen, inte hastigheten på avslöjandet, som avgör hur länge en flotta av bärbara datorer förblir exponerad. Den som äger endpoint-policyn bör betrakta årets sjätte zero-day som en grundfrekvens, inte en avvikelse: med sex incidenter som landat med ungefär sex till sju veckors mellanrum under 2026 är den korrekta hållningen en stående process som kontrollerar installerade Chrome-versioner mot den senaste stabila byggen varje vecka, i stället för att lita på att varje maskin uppdaterar sig själv enligt schema. När Cyber Resilience Act's klocka väl går igång får ett EU-baserat IT-team dessutom en ny signal att hålla koll på: en leverantörs historik av anmälningar till ENISA blir en grov indikator på hur ofta dess produkter aktivt attackeras, mer konkret än ett marknadsföringspåstående om säkerhet i företagsklass, och värt att kontrollera före en förnyelse, inte efter en incident.