HTTP2Shell: kritisk sikkerhetshull i Brotli. Er nettsiden din rammet?

Først PHP2Shell, nå HTTP2Shell. Det nye hullet sitter i Brotli, et komprimeringsbibliotek som ligger på serveren under nettsiden. 2. november skrev sikkerhetsselskapet Wordfence at de har fått angrepskoden til å kjøre egen kode gjennom en helt vanlig WordPress-side, uten innlogging, i et lukket testmiljø.

Det spesielle med denne saken er at du ikke kan fikse den selv i WordPress. Det er webhotellet eller den som drifter serveren, som må gjøre jobben. Her er hva hullet er, og hva du bør be leverandøren om å sjekke.

Hva er HTTP2Shell?

HTTP2Shell er et av flere uoffisielle navn på CVE-2026-111497. Det kalles også Node2Shell og Brotli2Shell. Navnet er litt misvisende: hullet har ingenting med protokollen HTTP/2 å gjøre. Det sitter i Brotli, Googles bibliotek for å pakke sammen og pakke ut data, som brukes for å gjøre nettsider raskere å sende.

Feilen gjør at en spesiallaget komprimert fil kan få Brotli til å skrive utenfor minneområdet sitt når den pakkes ut. Det kan føre til krasj, lekkasje av data fra minnet, eller at angriperen får kjøre egen kode. Hullet har en CVSS-score på 9,2 av 10. Brotli kom med rettede versjoner 21. oktober, og Google publiserte sårbarheten dagen etter.

Hvorfor angår det webhoteller og WordPress-sider?

Brotli følger som regel med operativsystemet, webhotellets plattform eller serveroppsettet. Du ser det aldri i WordPress. Når WordPress henter noe fra en annen nettside, kan serveren bruke Brotli til å pakke ut svaret.

Den kjente angrepsveien går gjennom xmlrpc.php og pingback-funksjonen i WordPress: angriperen ber siden sjekke en lenke, siden henter adressen, og angriperens server svarer med en ødelagt Brotli-fil. Jeg har gått gjennom den i detalj, med hvordan du stenger den, i artikkelen om sårbarheten i xmlrpc.php.

Wordfence fikk koden til å kjøre i et testmiljø med WordPress 7.1.3, Debian 13, Apache og PHP 8.3.36. Etter at bare Brotli ble oppdatert, virket ikke angrepet lenger. På PHP 8.3.35 kjørte koden ikke, men PHP krasjet i ett av oppsettene. Angrepskoden må altså passe til akkurat den serveren den treffer. Wordfence påpeker at det gjør tilfeldige masseangrep mindre pålitelige, men at koden kan gjenbrukes mot servere som er satt opp likt.

Blir det utnyttet nå?

Den amerikanske sikkerhetsetaten CISA la hullet på listen over sårbarheter som utnyttes i angrep 27. oktober, uten å si hvilken programvare det gjaldt. Flere sikkerhetsselskaper ser angrepsforsøk, også 2. november. Per 2. november hadde Wordfence ikke funnet noen offentlig dokumentert sak der en side faktisk er tatt over, verken generelt eller gjennom WordPress. Men som Wordfence skriver: at ingen sak er offentlig, betyr ikke at ingen har skjedd.

Spør leverandøren om dette

Versjonsnummeret i WordPress, eller i Verktøy og Helsesjekk, kan ikke svare på om du er rammet. Send heller disse spørsmålene til webhotellet eller den som drifter siden:

1. Er Brotli oppdatert på serveren som kjører siden vår? Wordfence foreslår å spørre nettopp om prosessen som serverer siden bruker en versjon av Brotli som er rettet for CVE-2026-111497.
2. Er tjenestene startet på nytt etter oppdateringen? Programmer som allerede kjører, kan fortsatt bruke den gamle versjonen til de startes på nytt. Kjører siden i en container, må den bygges på nytt, ikke bare startes på nytt.
3. Er alle kopier av Brotli oppdatert? En server kan ha flere kopier: i operativsystemet, i webserveren og i PHP. Å oppdatere én er ikke nødvendigvis nok.
4. Gjelder det også testsider og gamle installasjoner? Testmiljøer og eldre kopier av siden blir ofte glemt.
5. Har dere tatt vare på loggene? Wordfence anbefaler å beholde logger fra før hullet ble kjent og fram til serveren ble oppdatert, i tilfelle noe må undersøkes.
6. Bruker vi xmlrpc.php og pingbacks? Hvis ikke, kan de stenges. Det fjerner den kjente veien inn via WordPress, men retter ikke selve hullet.

En liten ting for deg som bruker Wordfence-tillegget: valget «Disable XML-RPC authentication» stopper ikke pingbacks. Det gjør heller ikke filteret xmlrpc_enabled, som mange tips anbefaler.

Når leverandøren ikke svarer

Mange små bedrifter har en WordPress-side som ble laget for noen år siden, på et webhotell ingen i bedriften helt vet hvem som følger med på. Da er det ofte ingen som får dette varselet i det hele tatt. Det er ikke noe galt med deg som bedriftseier, men det er et problem når sikkerhetshullene kommer tettere og tettere: PHP2Shell, WordPress 7.1.4 og nå Brotli, i løpet av et par uker, mens NSM har hevet cyberrisikonivået til «høyt».

Slik håndteres det med Website-vaktmester

Med Website-vaktmester bygger jeg siden statisk, med Astro. Sidene ligger ferdig som filer, uten PHP, uten xmlrpc.php og uten et publiseringsverktøy på serveren. Den kjente veien inn via WordPress finnes rett og slett ikke.

Hosting er inkludert, hos Vercel. Brotli-hullet rammer også Node.js, som kjører de små serverfunksjonene mange moderne sider bruker til for eksempel skjemaer. Vercel la inn brannmurregler mot angrepet samme dag som det ble kjent, og oppdaterer Node.js-versjonene i miljøene sine selv. Min jobb er å følge med på slike varsler og sjekke at sidene står på et miljø som får fiksen. Du trenger ikke å vite hva Brotli er.

Det koster fra 2 450 kr/mnd eks. mva. ved årsbetaling, med 30 dagers oppsigelse. Vil du vite hvordan siden din står seg i dag, kan du kjøre den gjennom den gratis nettsjekken.

Kilder

• Wordfence: HTTP2Shell: What the Critical Brotli Vulnerability Means for WordPress Sites
• Patchstack: WordPress doesn't ship Brotli. It's still exposed to CVE-2026-111497
• Canadian Centre for Cyber Security: Critical vulnerability impacting Google Brotli
• Vercel: Node.js security advisory (CVE-2026-111497)