Hvad wp2shell faktisk gør

Da Adam Kues fra Assetnote sendte en særligt udformet forespørgsel til en almindelig WordPress-installation, kørte serveren hans kode. Ingen konto, intet kodeord, intet plugin, ingen usædvanlig indstilling. Forskerne kaldte kæden wp2shell, WordPress tildelte den CVE-2026-63030, og begge parter vurderede den som kritisk.

Udnyttelsen kæder to svagheder i REST-API'ens batch-rute sammen: en forvirring i routingen der lader en ikke-godkendt kalder nå kodestier der burde være afskærmede, og en SQL-injektion der kan nås gennem den. Kædet sammen forvandler de en anonym HTTP-forespørgsel til kørsel af kode, det værste resultat et web-hul kan have.

Hvorfor den automatiske rettelse ikke er målstregen

WordPress udgav 6.9.5 og 7.0.2 den 17. juli 2026 og gennemtvang i lyset af alvoren opdateringerne på berørte sider i stedet for at vente på et klik fra ejeren. Det er det rigtige valg, og de fleste sider er nu lukkede. Det skjuler også det sværere spørgsmål.

Et hul uden godkendelse betyder, at enhver på internettet kunne bruge det, før du rettede, og at installere rettelsen ændrer ikke det. Var din side nåelig og uopdateret i eksponeringsvinduet, fjernede opdateringen døren, men ikke det der allerede var gået igennem: en indsat administratorkonto, en planlagt opgave, en webshell i upload-mappen.

Hvorfor næsten enhver ejer er omfattet

Dette lå i kernen, den software som hver WordPress-side kører, så eksponeringen afhang ikke af et niche-plugin eller -tema. WordPress driver næsten 40 procent af nettet, og derfor er en enkelt kernefejl af denne slags en massebegivenhed og ikke et særtilfælde.

Versionerne 6.9.0 til 6.9.4 og 7.0.0 til 7.0.1 var sårbare over for wp2shell. Den anden fejl, en SQL-injektion i parameteren author__not_in i WP_Query med CVSS 9.1, rækker tilbage til 6.8, så en side der sprang opdateringer over i nogle måneder, bar det største af de to eksponeringsvinduer.

Hvad EU-regler gør det til

For en europæisk virksomhed er hullet ikke kun teknisk. Ligger der persondata bag den side, giver GDPR dig 72 timer til at underrette din tilsynsmyndighed, så snart du bliver bekendt med et brud, og 'vi kan ikke udelukke det' ligger tættere på den viden end på ro.

For væsentlige og vigtige enheder under NIS2 udløser en hændelse af denne alvor sit eget ur for tidlig varsling og indberetning, og myndigheder forventer i stigende grad bevis for opdagelse, ikke bare en patch-log. En gennemtvungen automatisk opdatering er et forsvar, du ikke valgte; om du derefter tjekkede for kompromittering, står i din log.

Kontrollen der skal ske nu

Bekræft at siden kører 6.9.5 eller 7.0.2, og behandl så eksponeringsvinduet som det egentlige arbejde. Gennemgå administratorkonti og applikationsadgangskoder oprettet i juli, undersøg planlagte opgaver og nyligt ændrede PHP-filer, og træk webserverens logge for usædvanlige POST-forespørgsler til REST-API'en omkring datoen for offentliggørelsen.

Kører du administreret WordPress, så spørg din udbyder skriftligt om, hvornår rettelsen kom, og om den så udnyttelsesforsøg mod din side. Det ærlige svar på 'blev vi ramt' kommer sjældent med det samme, men de ejere der spørger i denne uge, er dem der ikke skal forklare et stille brud næste kvartal.

Læs videre: En død bygning koster mere end en løsesum  |  Din sandbox blev ramt en måned før advarslen