Exploatkedjan ”wp2shell” utgör en allvarlig säkerhetsincident som riktar sig mot den grundläggande arkitekturen i WordPress-ekosystemet. Det rör sig om en sårbarhet för fjärrkörning av kod (RCE) före autentisering som helt och hållet finns inbyggd i WordPress Core. För att utnyttja sårbarheten krävs varken plugins eller teman från tredje part, och inte heller autentiserad åtkomst. En enda specialkonstruerad HTTP-förfrågan riktad mot en standardinstallation kan leda till att en oautentiserad angripare får fullständig kontroll över systemet.

Allvarlighetsgraden hos detta hot återspeglas i dess CVSS-poäng på 9,8. CISA lade till båda CVE:erna i sin katalog över kända utnyttjade sårbarheter (KEV) efter att utnyttjandeaktivitet observerats kort efter offentliggörandet. Data visar att cirka 60 % av de organisationer som använder WordPress initialt var sårbara vid tidpunkten för offentliggörandet, och att en betydande andel av dessa hade sina servrar direkt exponerade mot internet.

Ett framgångsrikt utnyttjande kan leda till fullständig kompromettering av databasen, bestående åtkomst till webbservern via förklädda webshells samt skapande av obehöriga administratörskonton.

Översikt över sårbarheten

Exploitkedjan wp2shell kombinerar flera sårbarheter i WordPress Core för att uppnå obehörig utökning av behörigheter. Attacken utnyttjar först en brist i REST API:s batchbearbetning av förfrågningar för att kringgå validering av förfrågningar och behörighetskontroller. Denna åtkomst används sedan för att utnyttja en SQL-injektionssårbarhet i WP_Query:s hantering av parametern author_exclude.

Med hjälp av SQL-injektionen kan en angripare manipulera cachade WordPress-objekt och utnyttja oEmbed-cachemekanismen för att skriva skadlig data tillbaka till databasen. Exploiten utnyttjar sedan funktionen för ändringsuppsättningar i Customizer för att tillfälligt ärva behörigheterna för ett administratörskonto, vilket i slutändan skapar en permanent administratörsanvändare.

Sammanfattningsvis genomförs attacken i fyra steg:

1. Omgång av REST API-validering genom desynkronisering av batchförfrågningar.
2. SQL-injektion genom felaktig sanering av parametrar.
3. Förgiftning av objektcache och databasmanipulation med hjälp av oEmbed-återskrivningsbeteende.
4. Privilegieeskalering och persistens genom skapande av administratörskonton.

När dessa sårbarheter kombineras kan de göra det möjligt för en icke-autentiserad angripare att få fullständig administrativ kontroll över en sårbar WordPress-installation.

Följande sårbarheter i WordPress-kärnan utnyttjas i denna attack:

• CVE-2026-63030 (REST API Batch Route Confusion): Ett logikfel i WP_REST_Server::serve_batch_request_v1() där ett misslyckande med att hantera WP_Error-objekt orsakar en desynkronisering mellan interna arrayer för begäranhantering, vilket gör att ogiltiga begäranden kan ärva behörigheter från ofarliga hanterare.
• CVE-2026-60137 (SQL-injektion i WP_Query): En brist i typhanteringen i WP_Query-motorn. När vissa parametrar tar emot en rå sträng istället för en förväntad array kringgås saneringen av heltal, vilket leder till interpolering av råa strängar i SQL WHERE-satser.

Berörda respektive korrigerade versioner

Strategisk bedömning: WordPress-risk

Historiskt sett har säkerheten i WordPress fokuserat på ”plugin-gränsen”. Denna attack visar att betydande säkerhetsrisker kan ha sitt ursprung i WordPress-kärnan och inte enbart genom tillägg från tredje part. Organisationer bör se till att WordPress-installationer ingår i formella program för hantering av sårbarheter och uppdateringar.

WordPress bör betraktas som ett högvärdigt mål ur ett defensivt perspektiv. Dess omfattande användning i miljöer som är anslutna till internet gör det till en attraktiv plattform för hotaktörer, vilket ökar sannolikheten för sårbarhetsforskning, automatiserad skanning och exploateringsförsök.

Strategiska styrningspelare

• Kartläggning av attackytan: Inventera kontinuerligt alla WordPress-tillgångar. De flesta intrång sker på bortglömda, opatchade testmiljöer.
• Kontinuerlig validering: Lita inte på statusen ”automatisk uppdatering”. Implementera automatiserad versionskontroll för att säkerställa att patchar faktiskt är aktiva.
• Lita på men verifiera: Även om WordPress.org möjliggör tvingade uppdateringar måste administratörer verifiera att de har slutförts på varje värdkonfiguration.
• Rotation av inloggningsuppgifter och salt: Vid misstänkt sårbarhet i kärnan är rotation av databassalter i wp-config.php ett obligatoriskt strategiskt försvar för att ogiltigförklara befintliga sessioner.

Hotjakt och indikatorer på intrång (IoC)

Nätverkssignaler

• HTTP 207 Multi-Status: Detta är en mycket tillförlitlig signal på framgångsrika exploateringsförsök via batch-API:et.
• Medvetenhet om WAF-kringgående: Angripare kan använda %2F-escapetecken i parametern ?rest_route= för att kringgå enkel strängmatchning. WAF:er måste konfigureras för att avkoda URL:er innan matchning sker.
• Användaragenter: Övervaka efter wp2shell, rezwp2shell eller cve-2026-63030/1.0.

Värdbaserade artefakter

• Filmarkörer: Sök efter temp-write-test- i katalogen wp-content/, vilket används av exploit-kit för att verifiera skrivbehörigheter.
• Skadliga plugins: Leta efter kataloger med ett hex-suffix, till exempel wp-content/plugins/wp2shell_/.
• Skillnad mellan CMSmap: Forensiska team måste skilja mellan det legitima CMSmap-verktyget på 11 KB och den förvrängda plattformen på 150 KB som observerats i aktuella kampanjer.

Kända IOC:er

Avhjälpande åtgärder och sanering

Organisationer måste omedelbart uppdatera WordPress Core till versionerna 7.0.2, 6.9.5 eller 6.8.6. Även om WordPress.org har genomfört tvingande uppdateringar måste administratörer följa principen ”lita på men verifiera” när det gäller dessa installationer, eftersom det inte kan garanteras att automatiska uppdateringar slutförs på alla värdkonfigurationer. Prioritet måste ges åt instanser i grenarna 6.9.x och 7.0.x, som är utsatta för hela RCE-kedjan.

Tillfälliga åtgärder

Om det inte är möjligt att omedelbart installera en patch bör administratörer implementera WAF-regler för att blockera oautentiserad åtkomst till de drabbade REST API-batch-ändpunkterna. URL-avkodning bör utföras före regelmatchning för att upptäcka kodade förfrågningar.

Blockerade slutpunkter:

• /wp-json/batch/v1
• ?rest_route=/batch/v1 (inklusive URL-kodade varianter såsom %2Fbatch%2Fv1)

Åtgärder efter intrång

Om det finns skäl att tro att ett intrång har skett rekommenderas följande åtgärder:

• Kontrollera kärnfilernas integritet: Kör wp core verify-checksums för att identifiera modifierade eller obehöriga WordPress-kärnfiler.
• Byta inloggningsuppgifter: Återställ databasens inloggningsuppgifter och generera om autentiseringssalterna och säkerhetsnycklarna i wp-config.php.
• Granska användarkonton: Granska tabellen wp_users för att upptäcka obehöriga konton, särskilt konton som använder namngivningskonventionen w2s_.
• Leta efter IOC:er: Sök igenom webbserverloggar, filsystem och säkerhetsövervakningsverktyg efter de indikatorer på intrång som anges i detta meddelande.

Om du är orolig för något av de hot som beskrivs i detta meddelande eller behöver hjälp med att avgöra vilka åtgärder du bör vidta för att skydda dig mot de mest allvarliga hoten som din organisation står inför, vänligen kontakta din kundansvarige eller hör av dig till oss för att ta reda på hur du kan skydda din organisation.