wp2shell: Den kritiska WordPress-sårbarheten som kan ge angripare full kontroll

Sårbarheternas identifierare

Wp2shell består av två sårbarheter som kan kedjas ihop :

• CVE-2026-63030 – en förväxlingsbugg i routningen för REST API:ts batch-endpoint. Den har klassats som kritisk och har av flera säkerhetsaktörer fått CVSS-poängen 9,8 . En tidig rapport angav 7,5, men bedömningen reviderades senare.
• CVE-2026-60137 – en oautentiserad SQL-injektion i parametern author__not_in i WP_Query. Den är klassad som en allvarlig sårbarhet .

Det är kombinationen av dessa två fel som kan leda från en vanlig HTTP-förfrågan till fullständig fjärrkörning av kod.

Vilka versioner är berörda?

Följande versioner behöver uppdateras:

• WordPress 6.9.x: versionerna 6.9.0 till och med 6.9.4
• WordPress 7.0.x: versionerna 7.0.0 och 7.0.1
• WordPress 6.8.x: uppdatera till den korrigerade versionen 6.8.6

De åtgärdade versionerna är 6.9.5, 7.0.2 och 6.8.6.

Så fungerar angreppskedjan

Wp2shell är inte ett enda isolerat fel, utan en kedja av två brister .

1. SQL-injektionen: Genom manipulerade HTTP-förfrågningar mot parametern author__not_in kan en angripare föra in skadlig SQL-kod i WordPress-databasen utan användarnamn eller lösenord.

2. Förväxlingen i REST API:t: Batch-endpointen /wp-json/batch/v1 kan hantera flera underförfrågningar i ett enda anrop. På grund av ett tolkningsfel kan interna arrayer hamna ur synk. Det kan göra det möjligt att kringgå begränsningar och kedja interna API-anrop som normalt inte får kombineras .

När felen kombineras kan angriparen använda batch-endpointen för att nå SQL-injektionen och därefter eskalera till full fjärrkörning av kod. Det kan exempelvis ske genom att:

• skriva godtyckliga data, som ett PHP-baserat webbskal, till filsystemet med MySQL-kommandot INTO OUTFILE, eller
• ändra WordPress-inställningar som senare kör PHP-kod .

Angreppet kräver ingen autentisering, inga tillägg och ingen särskild konfiguration. En standardinstallation av WordPress kan alltså vara utsatt . Den 18 juli 2026 hade dessutom en offentlig kontrolltjänst publicerats på wp2shell.com, samtidigt som fungerande proof-of-concept-kod cirkulerade .

Ett beständigt objektcachelager, exempelvis Redis eller Memcached, kan i vissa fall förändra eller delvis begränsa angreppsvägen. Det tar dock inte bort den underliggande sårbarheten .

Gör så här nu

1. Uppdatera omedelbart. Installera WordPress 6.9.5, 7.0.2 eller 6.8.6. Webbplatser som stöder automatiska uppdateringar kan redan ha fått den tvingade uppdateringen .
2. Kontrollera versionen manuellt. Öppna administrationspanelen och gå till Instrumentpanel → Uppdateringar, eller kontrollera versionsnumret i wp-includes/version.php.
3. Använd en tillfällig spärr om uppdatering dröjer. En virtuell patch eller en brandvägg för webbapplikationer, WAF, kan minska risken. Cloudflare har publicerat WAF-regler som blockerar den aktuella angreppsvägen .
4. Leta efter tecken på intrång. Kontrollera bland annat oväntade filer i wp-content/uploads/, okända administratörskonton och avvikande poster i databasen. Någon massutnyttjandevåg hade inte bekräftats den 18 juli, men den offentliga proof-of-concept-koden innebär att sökningar efter sårbara webbplatser sannolikt har inletts.
5. Granska databasbehörigheterna. WordPress-databasanvändaren bör inte ha privilegiet FILE, eftersom det bland annat möjliggör INTO OUTFILE. Det kan begränsa vägen från SQL-injektion till kodkörning.

Därför är öppen källkod en särskild risk här

Att WordPress är öppen källkod är i grunden en styrka: sårbarheter kan granskas öppet och korrigeringar kan spridas snabbt. Men i just det här läget innebär modellen också en akut risk.

• Patchen kan avslöja angreppsvägen. När den korrigerade källkoden publiceras kan angripare jämföra den med den sårbara versionen och återskapa den exakta sårbarheten på kort tid. Säkerhetsaktörer uppger att källkodsjämförelser snabbt kan avslöja den felaktiga koden .
• Försvararnas tidsfönster krymper. I sluten programvara krävs ofta egen sårbarhetsforskning för att utveckla ett angrepp. I ett öppet projekt kan patchen i praktiken fungera som ett detaljerat avslöjande. Webbplatsägare behöver därför agera inom timmar snarare än dagar.
• Angreppsytan är enorm. WordPress driver omkring 43 procent av alla webbplatser. Installationerna sköts av aktörer med mycket olika säkerhetsrutiner. Vissa webbplatser är övergivna, kör gamla PHP-versioner eller saknar automatiska uppdateringar – och blir lättare mål när angreppskod blir offentlig .
• Tröskeln för massutnyttjande är låg. En offentlig kontrolltjänst och exploitkod publicerades inom 24 timmar efter patchen . En angripare med måttliga tekniska kunskaper kan anpassa materialet för automatiserad skanning.
• Ingen inloggning krävs. Eftersom kedjan fungerar före autentisering behövs varken giltiga inloggningsuppgifter, ett sårbart tillägg eller en ovanlig konfiguration .

Kort sagt blir säkerhetspatchen i ett projekt med öppen källkod ofta också en karta över det som behöver angripas. Tillsammans med WordPress enorma och ojämnt underhållna installationsbas skapar det en farlig period – även innan någon bekräftad exploatering i stor skala har konstaterats.