Vad wp2shell faktiskt gör
När Adam Kues på Assetnote skickade en särskilt utformad begäran till en vanlig WordPress-installation körde servern hans kod. Inget konto, inget lösenord, inget plugin, ingen ovanlig inställning. Forskarna kallade kedjan wp2shell, WordPress tilldelade den CVE-2026-63030, och båda parter bedömde den som kritisk.
Utnyttjandet länkar samman två svagheter i REST-API:ets batch-rutt: en routningsförvirring som låter en icke autentiserad anropare nå kodvägar som borde vara skyddade, och en SQL-injektion som nås genom den. Sammanlänkade förvandlar de en anonym HTTP-begäran till kodkörning, det allvarligaste utfall ett webbhål kan ha.
Varför den automatiska rättningen inte är mållinjen
WordPress släppte 6.9.5 och 7.0.2 den 17 juli 2026 och tvingade med tanke på allvaret fram uppdateringarna på berörda sajter i stället för att vänta på ett klick från ägaren. Det är rätt val, och de flesta sajter är nu stängda. Det döljer också den svårare frågan.
Ett hål utan autentisering betyder att vem som helst på internet kunde använda det innan du rättade, och att installera rättningen ändrar inte det. Var din sajt nåbar och orättad under exponeringsfönstret tog uppdateringen bort dörren men inte det som redan gått igenom: ett insmuget administratörskonto, en schemalagd uppgift, en webshell i uppladdningsmappen.
Varför nästan varje ägare omfattas
Detta låg i kärnan, mjukvaran som varje WordPress-sajt kör, så exponeringen berodde inte på ett nisch-plugin eller -tema. WordPress driver nästan 40 procent av webben, och därför är en enda kärnbrist av denna klass en masshändelse och inte ett särfall.
Versionerna 6.9.0 till 6.9.4 och 7.0.0 till 7.0.1 var sårbara för wp2shell. Den andra bristen, en SQL-injektion i parametern author__not_in i WP_Query med CVSS 9.1, sträcker sig tillbaka till 6.8, så en sajt som hoppade över uppdateringar i några månader bar det största av de två exponeringsfönstren.
Vad EU-regler gör det till
För ett europeiskt företag är hålet inte bara tekniskt. Ligger det persondata bakom den sajten ger GDPR dig 72 timmar att underrätta din tillsynsmyndighet så snart du får kännedom om ett intrång, och 'vi kan inte utesluta det' ligger närmare den kännedomen än lugnet.
För väsentliga och viktiga entiteter under NIS2 startar en incident av denna allvarsgrad sin egen klocka för tidig varning och rapportering, och tillsynsmyndigheter förväntar sig alltmer bevis på upptäckt, inte bara en patchlogg. En framtvingad automatisk uppdatering är ett försvar du inte valde; om du sedan kontrollerade för kompromettering står i din logg.
Kontrollen som måste ske nu
Bekräfta att sajten kör 6.9.5 eller 7.0.2, och behandla sedan exponeringsfönstret som det verkliga arbetet. Gå igenom administratörskonton och applikationslösenord som skapats i juli, granska schemalagda uppgifter och nyligen ändrade PHP-filer, och dra webbserverns loggar efter ovanliga POST-begäranden till REST-API:et kring datumet för offentliggörandet.
Kör du hanterad WordPress, fråga din värd skriftligen när rättningen kom och om den såg utnyttjandeförsök mot din sajt. Det ärliga svaret på 'blev vi träffade' kommer sällan direkt, men de ägare som frågar denna vecka är de som inte behöver förklara ett tyst intrång nästa kvartal.
Läs vidare: En död byggnad kostar mer än en lösensumma | Er sandbox angreps en månad före varningen
