Seks zero-days på otte måneder, en dusør på 1.000 dollar

Googles Chrome-team udsendte builds 152.0.7977.82 og .83 til Windows og macOS samt 152.0.7977.82 til Linux den 3. og 4. september 2026 for at rette CVE-2026-85046, en type confusion-fejl i V8-motoren til JavaScript og WebAssembly, som Google bekræftede allerede blev udnyttet i praksis. Fejlen gør det muligt for en manipuleret webside at narre V8's compiler til at give en angriber vilkårlig læse- og skriveadgang til browserens heap, hvilket åbner en vej til fjernkørsel af kode inden for Chromes sandkasse. Forskeren Salvatore Gulizia rapporterede fejlen den 4. august 2026 og fik udbetalt en dusør på 1.000 dollar. Google tilbageholdt tekniske detaljer, indtil rettelsen havde nået de fleste brugere, hvilket er standardpraksis ved en aktivt udnyttet sårbarhed. Dette er den sjette aktivt udnyttede zero-day i Chrome, der er blevet rettet i 2026, og hver eneste af dem fik en CVSS-score på 8.8 og krævede en akut rettelse uden for den normale udgivelsesplan i stedet for at vente på Chromes almindelige opdateringscyklus.

Måned (2026)CVEKomponentCVSS
FebruarCVE-2026-2441CSS (use-after-free)8.8
MartsCVE-2026-3909Skia (out-of-bounds write)8.8
MartsCVE-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

Otte dage før uret begyndte at tikke

Googles egen tidslinje viser det afgørende hul: virksomheden offentliggjorde og rettede CVE-2026-85046 den 3. og 4. september, otte dage før ikrafttrædelsesdatoen for den artikel i EU's Cyber Resilience Act, som ville have krævet en formel indberetning af netop denne type hændelse. Fra den 11. september 2026 behandler artikel 14 software som Chrome som et produkt med digitale elementer, og så snart en leverandør bliver opmærksom på, at en sårbarhed bliver aktivt udnyttet, skal virksomheden sende en tidlig advarsel til et nationalt kontaktpunkt og til ENISA, EU's agentur for cybersikkerhed, inden for 24 timer, en mere udførlig underretning inden for 72 timer og en endelig rapport inden for 14 dage efter, at rettelsen er blevet tilgængelig. Havde Google opdaget og offentliggjort den samme fejl den 12. september i stedet for den 3. september, ville den identiske forløbsrække - en forsker rapporterer en V8-fejl, Google bekræfter udnyttelse i praksis, og Google udsender en akut rettelse - være blevet Cyber Resilience Act's første reelle testcase i stedet for en rutinemæssig advarsel. Seks udnyttede zero-days i Chrome fordelt over otte måneder i 2026 gør en syvende, der ankommer efter at loven for alvor har fået tænder, til et spørgsmål om hvornår snarere end om.

Beslutningsreglen for den, der ejer patch-politikken

Den praktiske lære for enhver EU-virksomhed er, at man ikke skal vente på en myndighedsindberetning for at høre om den næste zero-day i Chrome, for Googles egne udgivelsesnoter sagde, at de rettede builds ville rulle ud over de kommende dage og uger, selv efter at rettelsen fandtes - hvilket betyder, at det er hastigheden på autoopdateringen, ikke hastigheden på offentliggørelsen, der afgør, hvor længe en flåde af bærbare computere forbliver eksponeret. Den, der ejer endpoint-politikken, bør behandle årets sjette zero-day som en grundrate og ikke som en anomali: med seks hændelser, der er landet med cirka seks til syv ugers mellemrum gennem 2026, er den korrekte holdning en fast proces, der tjekker installerede Chrome-versioner op mod den nyeste stabile build på ugentlig basis, i stedet for at stole på, at hver eneste maskine opdaterer sig selv efter planen. Når Cyber Resilience Act's ur først kører, får et EU-baseret IT-team desuden et nyt signal at holde øje med: en leverandørs historik over indberetninger til ENISA bliver en grov indikator for, hvor ofte dens produkter bliver aktivt angrebet - mere konkret end et marketingudsagn om enterprise-sikkerhed, og værd at tjekke før en fornyelse frem for efter en hændelse.