wp2shell: kritisk sårbarhet i WordPress-kärnan patchad

WordPress-teamet släppte den 17 juli 2026 en akut säkerhetsuppdatering för en sårbarhetskedja som forskarna kallar wp2shell. Det handlar om en oautentiserad (ingen inloggning krävs) fjärrkodexekvering, förkortat RCE, som sitter i själva WordPress-kärnan. Ingen plugin behöver vara installerad och ingen ovanlig konfiguration krävs. En ren standardinstallation räcker för att en anonym begäran ska kunna köra kod på servern. Har du en WordPress-sajt är det enda som spelar roll just nu att kärnan är uppdaterad till 7.0.2, 6.9.5 eller 6.8.6 beroende på vilken version du kör.

Uppdaterat 22 juli: sårbarheten utnyttjas nu bekräftat i verkliga angrepp, och båda sårbarheterna finns sedan den 21 juli i den amerikanska myndigheten CISA:s katalog över kända utnyttjade sårbarheter. Avsnitten längre ned om exploateringsläget och om vad du gör med en sajt som stått opatchad är uppdaterade efter det.

Varför det här skiljer sig från vanliga WordPress-larm

Den vanligaste förklaringen till att WordPress drabbas av intrång brukar vara ett osäkert tredjepartsplugin. Den ursäkten håller inte den här gången. Sårbarheten sitter i kärnkoden, i funktioner som finns i varje WordPress-installation oavsett vilka plugins du kör. Det gör att ansvaret hamnar där det ska, hos kärnutvecklarna och hos webbhotellet som sköter uppdateringarna, snarare än hos den enskilda sajtägaren som installerat ett riskabelt plugin.

Bara ett par dagar tidigare skrev vi om WP-SHELLSTORM, en massattack som utnyttjade sårbara plugins på både WordPress och Joomla. Det är viktigt att hålla isär de två fallen. WP-SHELLSTORM handlade om tredjepartskod som sajtägare själva hade installerat. wp2shell är allvarligare i den meningen att det inte finns någon plugin att avinstallera eller uppdatera bort. Felet finns i grundinstallationen.

Två sårbarheter som kedjas ihop

Enligt forskarna på Searchlight Cyber, som upptäckte och rapporterade felet via WordPress egna HackerOne-program, består wp2shell av två separata brister som tillsammans blir farligare än var för sig.

• CVE-2026-60137 är en SQL-injektion med CVSS-poäng 9.1 (kritisk). Den sitter i parametern author__not_in i WP_Query och når bakåt till WordPress 6.8, vilket gör den till den mest spridda av de två.
• CVE-2026-63030 är en så kallad batch-route-förväxling i REST API:ets endpoint /wp-json/batch/v1, med CVSS-poäng 7.5 (hög).

Var för sig är sårbarheterna allvarliga men begränsade. Kedjade tillsammans, där SQL-injektionen routas genom batch-endpointen, eskalerar de till fullständig fjärrkodexekvering på WordPress 6.9 och senare. Forskarna har medvetet valt att inte publicera fullständiga tekniska detaljer ännu, för att ge sajtägare och webbhotell tid att hinna patcha innan någon bygger ett färdigt exploateringsverktyg.

Vilka versioner är drabbade

Här är det värt att vara precis, för exponeringen skiljer sig åt beroende på vilken av de två sårbarheterna man talar om. WordPress version 6.8 och senare påverkas av åtminstone en av de två bristerna. Den fullständiga RCE-kedjan, alltså den som ger en angripare kodexekvering, kräver dock version 6.9 eller senare. Konkret gäller det 6.9.0 till 6.9.4 samt 7.0.0 till 7.0.1. Versioner före 6.8 påverkas inte alls enligt WordPress egen formulering i släppnotisen för 7.0.2.

WordPress 6.9 släpptes den 2 december 2025, vilket betyder att varje sajt som är sårbar för själva RCE-kedjan kör en kärnversion som är yngre än åtta månader. Det är inte gammal, eftersatt programvara vi talar om, utan sajter som i de flesta fall har uppdaterats relativt nyligen men ändå hamnat i riskzonen.

Så vet du om din sajt redan är skyddad

På grund av allvarlighetsgraden har WordPress.org aktiverat tvingade automatiska uppdateringar för sajter på de påverkade versionerna. Det är ett ovanligt steg och sker bara vid de mest kritiska säkerhetshålen, en tydlig signal om hur allvarligt WordPress-teamet bedömer sårbarheten. För de flesta svenska WordPress-sajter innebär det att patchen redan har rullats ut utan att någon behövt göra något aktivt.

Men anta aldrig att din sajt är en av dem. Många byråer och utvecklare stänger medvetet av automatiska kärnuppdateringar, ofta genom konstanten WP_AUTO_UPDATE_CORE=false i wp-config.php, för att själva styra när uppdateringar sker. De sajterna får ingen automatisk räddning och står oskyddade tills någon manuellt uppdaterar dem. Kontrollera själv genom att logga in i wp-admin och titta i nedre högra hörnet på instrumentpanelen, där versionsnumret visas, eller gå till Verktyg > Webbplatshälsa som ger en tydligare bild av uppdateringsstatus. Står det 7.0.2, 6.9.5 eller 6.8.6 (eller senare) är din sajt redan skyddad. Står det något äldre bör du uppdatera omedelbart, gärna innan du läser resten av den här artikeln.

Driver du managed WordPress-drift genom ett svenskt webbhotell hanteras kärnsäkerhetspatchar ofta åt dig som en del av tjänsten, vilket är ett bra tillfälle att påminna sig om vad det faktiskt innebär i praktiken. Vill du jämföra hur olika leverantörer hanterar WordPress-drift kan du läsa mer på vår webbhotellshubb för WordPress.

Batch-endpointen, en attackyta du kanske inte visste att du hade

Den andra halvan av kedjan, REST API:ets /wp-json/batch/v1, är intressant av ett annat skäl. Endpointen infördes redan i WordPress 5.6 och gör det möjligt att skicka flera API-anrop i en enda begäran. De allra flesta sajtägare har aldrig medvetet använt funktionen och känner förmodligen inte ens till att den finns. Det är själva poängen. wp2shell visar att kärnfunktioner man aldrig aktivt utnyttjar ändå kan fungera som en ingång för en angripare, eftersom de finns aktiverade som standard i varenda WordPress-installation. Det är ett bra argument för att inte tänka på attackytan enbart i termer av "vilka plugins har jag installerat", utan även "vilka standardfunktioner exponerar min sajt utan att jag tänkt på det".

Om du inte kan uppdatera direkt

Ibland går det inte att uppdatera på en gång, kanske på grund av anpassad kod som behöver testas mot en ny kärnversion först. Då finns det sätt att minska risken medan du väntar.

• Blockera anrop mot /wp-json/batch/v1 och ?rest_route=/batch/v1 på brandväggsnivå (WAF).
• Inaktivera WP REST API helt om du inte är beroende av det, till exempel via ett säkerhetsplugin eller en regel i webbservern.
• Cloudflare har rullat ut en hanterad WAF-regel som fångar upp trafikmönstret.
• Kör du hos ett webbhotell med virtuell patchning, till exempel via Imunify360 eller Patchstack, kan det ge ett visst skydd redan innan kärnuppdateringen är på plats.

Se de här åtgärderna som ett sätt att köpa tid, inte som en ersättning för den riktiga uppdateringen.

Är sårbarheten redan utnyttjad

Ja. Den 21 juli lade den amerikanska cybersäkerhetsmyndigheten CISA in båda sårbarheterna i sin katalog över kända utnyttjade sårbarheter. En sårbarhet hamnar där först när myndigheten har belägg för att den faktiskt utnyttjas, så noteringen är i praktiken ett kvitto på att det inte längre bara handlar om skanning och sondering. Amerikanska federala myndigheter fick fram till den 24 juli på sig att åtgärda kodexekveringshalvan, alltså tre dagars frist, vilket är kort även med katalogens mått mätt.

Två saker som stod i den här artikeln den 19 juli gäller inte längre. För det första cirkulerar färdig exploateringskod öppet. Flera oberoende proof of concept, alltså fungerande demonstrationskod, dök upp inom timmar efter att patchen släpptes, och de tidigaste varianterna som bara klarade SQL-injektionen har följts av versioner som når hela vägen fram till kodexekvering. För det andra är det inte längre oklart vad angriparna gör. Säkerhetsföretaget Wiz har dokumenterat lyckade övertaganden där de lagt in PHP-baserade bakdörrar, skadliga plugins som öppnar en egen väg in för fjärrkommandon, och nya administratörskonton.

Slutsatsen blir därför hårdare än den var. Har din sajt kört en sårbar version öppet mot internet någon gång efter den 17 juli räcker det inte att uppdatera kärnan och gå vidare. Då behöver du också utgå från att sajten kan ha blivit påverkad och faktiskt kontrollera den, vilket nästa avsnitt går igenom.

Om sajten redan har legat opatchad en tid

Det som gör wp2shell besvärligt att upptäcka är att bakdörren är byggd för att inte synas. Johannes Ullrich på SANS Internet Storm Center har publicerat ett fångat angrepp i sin helhet, och där skriver SQL-injektionen en PHP-fil rakt ut i mappen /wp-content/cache/ med ett slumpat filnamn. Filen svarar med en helt vanlig 404-sida till alla som inte skickar med rätt lösenord i webbadressen. Du kan alltså inte hitta den genom att surfa på din egen sajt, och en länkkontroll hittar den inte heller. Den syns bara om du listar filerna på disken, via FTP eller filhanteraren i webbhotellets kontrollpanel.

Tre saker är värda att kontrollera konkret:

• Filer i cache-mappen. Leta efter PHP-filer i /wp-content/cache/ som inte hör till ett cache-plugin du känner igen. Ullrichs eget städtips efter analysen är just den mappen.
• Nyskapade administratörskonton. I samma angrepp lade angriparen till en ny administratör när bakdörren väl var på plats.
• Uppgifterna i wp-config.php. Delar av angreppen har gått ut på att läsa ut just den filen, som innehåller både databasens inloggningsuppgifter och de säkerhetsnycklar WordPress signerar inloggningskakor med.

Den tredje punkten är den som oftast hoppas över vid sanering, och den väger tyngre här än vid ett vanligt plugin-intrång. Har någon fått ut innehållet i wp-config.php hjälper det inte att bara byta administratörslösenord, eftersom databasanvändaren och de åtta säkerhetsnycklarna fortfarande är kända. Byt då databaslösenordet och generera nya nycklar. Nyckelbytet loggar ut alla inloggade användare på en gång, vilket är precis vad du vill i det läget.

Vår guide om att sanera en hackad WordPress-sajt går igenom hela processen steg för steg.

Vad det betyder i praktiken

Att en kritisk kärnsårbarhet upptäcks, rapporteras ansvarsfullt genom WordPress egna kanaler och patchas inom rimlig tid är i grunden ett tecken på att säkerhetsprocessen fungerar som den ska. Det gör inte allvaret mindre, men det är värt att komma ihåg innan man drar slutsatsen att WordPress som plattform är otryggt. Det som återstår är en enkel åtgärd för varje sajtägare: kontrollera versionsnumret, se till att automatisk uppdatering faktiskt är påslagen, och om du styr det manuellt, uppdatera nu snarare än senare.