wp2shell: Det skal du vide om den kritiske WordPress-sårbarhed

Den 17. juli 2026 udsendte WordPress hastende sikkerhedsopdateringer for at lukke wp2shell – en kritisk sårbarhedskæde, der kan føre til uautoriseret fjernkørsel af kode, også kaldet RCE (remote code execution).\n\nDet usædvanlige er, at problemet findes i selve WordPress’ kernekode – ikke i et plugin eller et tema. Et standardinstalleret WordPress-site uden plugins kan derfor være sårbart. Angriberen behøver hverken en brugerkonto eller interaktion fra en bruger.\n\n## Hvad blev rettet?\n\nWordPress udgav version 6.9.5 og 7.0.2 den 17. juli 2026. På grund af sårbarhedens alvor aktiverede WordPress.org tvungne automatiske opdateringer for berørte websites .\n\nSårbarheden blev fundet og ansvarligt rapporteret af Adam Kues fra Assetnote, som er en del af .\n\n## To CVE-numre står bag wp2shell\n\nWp2shell er ikke én enkelt fejl, men en kæde bestående af to sårbarheder :\n\n- – en fejl i routingen af WordPress’ REST API-batch-endpoint. Den er klassificeret som kritisk og har af flere sikkerhedsleverandører fået en CVSS-score på . En tidlig rapport angav scoren 7,5.\n- – en uautoriseret SQL-injektionssårbarhed i parameteren i . Den er vurderet som alvorlig .\n\n## Hvilke WordPress-versioner er berørt?\n\nFølgende versioner er berørt:\n\n- \n- \n- Den ældre fik en bagudporteret rettelse i .\n\nDe relevante rettede versioner er dermed , og .\n\n## Sådan fungerer angrebet\n\nAngrebskæden udnytter først SQL-injektionsfejlen . Ved at sende specialkonstruerede HTTP-forespørgsler til parameteren kan en angriber indsætte SQL-kode i WordPress-databasen uden at logge ind.\n\nDen anden del, , findes i REST API’ens batch-endpoint: . Endpointet er designet til at behandle flere underforespørgsler i én samlet forespørgsel. En fejl i fortolkningen kan få interne datastrukturer til at komme ud af takt. Det gør det muligt at omgå begrænsninger for bestemte routes og kæde API-kald sammen, som normalt ikke ville være tilladt .\n\nNår fejlene kombineres, kan angriberen bruge batch-endpointet til at ramme SQL-injektionen og eskalere angrebet til fuld fjernkørsel af kode. Det kan blandt andet ske ved at:\n\n- skrive vilkårlige data, eksempelvis en PHP-webshell, til filsystemet via MySQL-kommandoen , eller\n- ændre WordPress-indstillinger, der senere får PHP-kode til at blive kørt .\n\nAngrebet kræver , og . Et standard-WordPress-site kan derfor være i fare . Den 18. juli 2026 blev der desuden offentliggjort en kontroltjeneste på , og et fungerende proof-of-concept-udnyttelsesprogram cirkulerede .\n\nEt persistent object cache-system som Redis eller Memcached kan i nogle tilfælde ændre eller delvist begrænse angrebsvejen, men det fjerner ikke selve sårbarheden .\n\n## Det bør du gøre nu\n\n1. Opgradér til WordPress , eller . Websites med automatiske opdateringer kan allerede være blevet opdateret af WordPress’ tvungne opdateringssystem .\n2. Gå til , eller se versionsnummeret i .\n3. En virtuel patch eller en regel i en WAF () kan begrænse angrebsforsøg. Cloudflare har udsendt WAF-regler specifikt mod angrebsvektoren .\n4. Kontrollér blandt andet for ukendte filer i , nye administratorer og uventede databaseposter. Der er ikke bekræftet masseudnyttelse, men offentliggørelsen af et PoC betyder, at scanning efter sårbare sites sandsynligvis er begyndt.\n5. WordPress-databasebrugeren bør ikke have -rettigheden, som blandt andet muliggør . Det kan begrænse vejen fra SQL-injektion til fjernkørsel af kode.\n\n## Hvorfor open source-modellen øger risikoen\n\nDer er ikke bekræftet udnyttelse i stor skala, men wp2shell skaber alligevel et akut risikovindue. WordPress’ open source-model betyder, at den rettede kode er offentligt tilgængelig. Angribere kan derfor sammenligne den nye og den gamle version og reverse-engineere den præcise angrebsvej få timer efter en patchudgivelse. Sikkerhedsleverandører har bekræftet, at en sådan sammenligning hurtigt kan afsløre den sårbare kode .\n\nDet har flere konsekvenser:\n\n- I proprietær software kræver udviklingen af et exploit ofte selvstændig sårbarhedsforskning. I et open source-projekt kan patchen i praksis fungere som en detaljeret beskrivelse af fejlen.\n- WordPress driver omtrent 43 procent af alle websites. Installationerne administreres med meget forskellig sikkerhedspraksis, og nogle kører forældede komponenter eller mangler automatiske opdateringer .\n- Kontrolværktøjet og exploit-koden blev offentliggjort inden for 24 timer efter patchen . En angriber med moderate tekniske evner kan derfor tilpasse koden til automatiseret scanning.\n- Angriberen behøver hverken gyldige legitimationsoplysninger, et sårbart plugin eller en særlig konfiguration .\n\nKort sagt kan selve sikkerhedsopdateringen afsløre, hvordan sårbarheden fungerer. Kombineret med WordPress’ enorme og uensartede installationsbase betyder det, at risikoen kan være høj, selv før den første bekræftede udnyttelse i praksis.