wp2shell: Dette må du vite om den kritiske WordPress-sårbarheten

Følgende versjoner er berørt:

• 6.9.0 til og med 6.9.4
• 7.0.0 og 7.0.1

Sjekk versjonen i kontrollpanelet under Dashboard → Updates, eller i filen wp-includes/version.php.

To CVE-numre – én angrepskjede

wp2shell er ikke én enkelt feil, men en kombinasjon av to sårbarheter :

• CVE-2026-63030: En forvekslingsfeil i rutehåndteringen til REST API-ets batch-endepunkt. Sårbarheten er klassifisert som kritisk og er oppgitt med en CVSS-score på 9,8 . En tidlig kilde oppga 7,5, men flere sikkerhetsleverandører har senere oppjustert scoren .
• CVE-2026-60137: En SQL-injeksjon uten krav om autentisering i parameteren author__not_in i WP_Query. Denne er vurdert som alvorlig.

Slik fungerer angrepet

Angrepet utnytter de to feilene i rekkefølge:

1. En angriper sender spesiallagde HTTP-forespørsler til author__not_in og injiserer SQL-kommandoer i WordPress-databasen – uten å logge inn.
2. Feilen i REST API-ets batch-endepunkt, /wp-json/batch/v1, gjør det mulig å omgå begrensninger for hvilke ruter som kan kalles. Endepunktet er laget for å behandle flere delvis forespurte API-kall i én forespørsel. En feil i parsingen kan føre til at interne lister kommer ut av takt, slik at kall som normalt ikke er tillatt, kan lenkes sammen .
3. Når feilene kombineres, kan SQL-injeksjonen eskaleres til full fjernkjøring av kode. Det kan blant annet skje ved å skrive vilkårlige data, for eksempel et PHP-basert webshell, til filsystemet gjennom MySQL-kommandoen INTO OUTFILE, eller ved å endre WordPress-innstillinger som senere kjører PHP-kode .

Angrepet krever ingen innlogging, ingen plugins og ingen spesiell konfigurasjon. Det kan i utgangspunktet ramme en standardinstallasjon av WordPress .

Per 18. juli 2026 var det publisert en offentlig sjekketjeneste på wp2shell.com, og et fungerende proof-of-concept-angrep var i omløp . Det er samtidig ikke bekreftet masseutnyttelse i det fri. En offentlig demonstrasjon gjør likevel at risikoen for automatisert skanning øker.

Et viktig forbehold er at vedvarende objektbuffer, for eksempel Redis eller Memcached, kan endre eller delvis begrense angrepsforløpet. Det fjerner ikke selve sårbarheten .

Dette bør administratorer gjøre nå

1. Oppdater umiddelbart. Installer WordPress 6.9.5, 7.0.2 eller 6.8.6. Nettsteder som støtter automatiske bakgrunnsoppdateringer, kan allerede ha fått den tvungne oppdateringen .
2. Bekreft versjonen manuelt. Ikke stol på at oppdateringen har gått gjennom uten å kontrollere kontrollpanelet eller wp-includes/version.php.
3. Bruk midlertidig beskyttelse hvis oppdatering må vente. En virtuell patch eller en regel i en webapplikasjonsbrannmur (WAF) kan redusere risikoen. Cloudflare har publisert WAF-regler som blokkerer angrepsvektoren .
4. Se etter tegn på kompromittering. Kontroller blant annet uventede filer i wp-content/uploads/, ukjente administratorbrukere og uvanlige oppføringer i databasen.
5. Begrens databasetilgangen. Kontroller at WordPress-databasebrukeren ikke har MySQL-rettigheten FILE. Det kan begrense veien fra SQL-injeksjon til kjøring av kode gjennom INTO OUTFILE.

Hvorfor åpen kildekode gjør situasjonen mer akutt

WordPress’ åpne kildekode er i utgangspunktet en styrke: Feil kan oppdages, granskes og rettes av et stort miljø. Men ved en alvorlig sårbarhet kan den samme åpenheten gi angripere et kort forsprang.

Når en sikkerhetsoppdatering publiseres, kan hvem som helst sammenligne den nye koden med den sårbare versjonen. Ved å studere forskjellene – såkalt diffing – kan angripere i mange tilfeller rekonstruere den konkrete angrepsveien i løpet av timer. Sikkerhetsleverandører har bekreftet at slik kildekodeanalyse raskt kan avsløre den sårbare koden .

Det forkorter tiden forsvarere har til å oppdatere nettsteder. Samtidig driver WordPress en svært stor og uensartet installasjonsbase. Plattformen brukes på rundt 43 prosent av alle nettsteder, og installasjonene driftes med svært ulik sikkerhetskompetanse. Mange nettsteder er ikke godt vedlikeholdt, bruker utdaterte PHP-versjoner eller mangler automatiske oppdateringer .

I wp2shell-saken ble både en offentlig sjekketjeneste og exploit-kode gjort tilgjengelig innen 24 timer etter oppdateringen . Når angrepet heller ikke krever innlogging, en sårbar plugin eller spesielle innstillinger, blir terskelen lav for å automatisere søk etter utsatte nettsteder.

Det betyr ikke at alle WordPress-nettsteder er kompromittert. Men det betyr at perioden mellom publisert oppdatering og faktisk installert patch er spesielt risikofylt. For administratorer er konklusjonen enkel: Oppdater først, og kontroller deretter at oppdateringen faktisk ble gjennomført.