WordPress PHP-sårbarhet PHP2Shell: det här måste driftansvariga göra

Kort sagt: Den PHP-sårbarhet som WordPress-drift just nu rapporteras om finns inte i WordPress, utan i PHP på servern under det. En WordPress-uppdatering stänger därför inte PHP2Shell. Det avgörande är PHP:s patchstatus, omstart av alla PHP-processer och en kontroll av typiska gömställen som wp-content/uploads och mu-plugins.

Varför en WordPress-uppdatering inte åtgärdar PHP2Shell

WordPress är en applikation skriven i PHP. Sårbarheterna CVE-2026-109618 och CVE-2026-109619 ligger ett steg djupare, i själva PHP-tolken. Enligt PHP-teamet gör de det möjligt att köra skadlig kod på distans utan inloggning. Med Apache och mod_php har en exploit visats innan någon WordPress-kod ens körs.

En webbplats med aktuell kärna, aktuella plugin och starka lösenord kan alltså ändå vara sårbar om PHP under den är gammalt. Omvänt bevisar inte ett patchat PHP att inget har hänt tidigare. Bakgrunden förklarar vi under Vad är PHP2Shell?.

WordPress PHP-sårbarhet: kontrollera PHP-versionen

I instrumentpanelen finns under Verktyg > Webbplatshälsa > Info i avsnittet ”Server” den PHP-version som er webbplats faktiskt körs med. Det är mer tillförlitligt än php -v på kommandoraden, eftersom kommandoraden ofta använder en annan PHP-installation än webbservern.

Det räcker ändå inte att titta på numret. Åtgärdade upstream-versioner är 8.5.12, 8.4.27, 8.3.36 och 8.2.35. Många webbhotell levererar dock rättningarna som backport; då står ett äldre nummer kvar trots att systemet är patchat. Hur ni tar reda på den verkliga statusen beskrivs i Kontrollera PHP-version och patchstatus på rätt sätt. Vilka PHP-versioner er WordPress-version stöder kontrollerar ni enligt systemkraven på wordpress.org.

Var skadlig kod gärna gömmer sig i WordPress

Efter en lyckad attack lämnar angriparna oftast en bakdörr för att kunna komma tillbaka även efter patchen. WordPress har välkända ställen för detta:

• wp-content/uploads/: avsedd för bilder och PDF-filer, inte för PHP-filer.
• wp-content/mu-plugins/: ”must-use”-plugin laddas automatiskt och kan inte stängas av i instrumentpanelen.
• wp-config.php: innehåller databasåtkomst och säkerhetsnycklar; en inskjuten rad syns knappast här.
• .htaccess i rotkatalogen och i underkataloger: omdirigeringar enbart för sökmotorer eller körning av ovanliga filändelser.
• Teman, framför allt functions.php, samt avaktiverade, bortglömda plugin.
• Databas: nya administratörer i wp_users, främmande JavaScript i wp_options eller i inlägg.

Ofarliga första kontroller med WP-CLI och inbyggda verktyg:

# Jämför kärnfilerna med de officiella kontrollsummorna
wp core verify-checksums
# Kontrollera plugin från katalogen på wordpress.org
wp plugin verify-checksums --all
# Lista PHP-filer i uppladdningsmappen
find wp-content/uploads -type f -name "*.php"
# Visa alla administratörer
wp user list --role=administrator

En träff är ett skäl till en noggrann undersökning, inte ett bevis. Kommersiella plugin går inte att kontrollera på det här sättet. En utförlig genomgång finns i guiden Hitta bakdörrar i WordPress.

Plugin, teman och administratörsåtkomst som extra risk

PHP2Shell kräver ingen plugin-sårbarhet. I vardagen är plugin och teman ändå den vanligaste ingången till WordPress-webbplatser. Varje plugin har egen kod, egna uppladdningsfunktioner och egna uppdateringscykler. Plugin som inte används bör ni radera i stället för att bara avaktivera, eftersom avaktiverade filer ligger kvar på servern.

För wp-login.php och wp-admin gäller: få administratörer, personliga konton i stället för delade åtkomster och tvåfaktorsinloggning. Om ni inte behöver XML-RPC kan det spärras. Vid misstanke bör alla lösenord och säkerhetsnycklarna i wp-config.php bytas. Filredigeraren i instrumentpanelen stänger ni av på samma ställe:

define( 'DISALLOW_FILE_EDIT', true );

Det här bör ni som WordPress-driftansvariga göra nu

1. Låt webbhotellet skriftligen bekräfta PHP-patchstatus och omstart av alla PHP-processer.
2. Be om att serverloggar från och med den 20 oktober 2026 bevaras.
3. Genomför kontrollerna ovan eller låt dem genomföras.
4. Uppdatera WordPress, plugin och teman. Det är rätt, men ingen ersättning för steg 1.
5. Vid avvikelser bör ni inte bara fortsätta driva webbplatsen, utan låta sanera den.

En plattformsuppdatering kan stänga kända sårbarheter i WordPress och plugin. Den kan varken reparera PHP eller ta bort insmugglade filer som inte hör till kärnan.

Hur hjälper PHP SOS konkret?

• Vi reder tillsammans med er eller ert webbhotell ut den faktiska PHP-statusen för er WordPress-webbplats, inklusive backports och omstart.
• Vi säkrar loggar, filer och databas innan något ändras.
• Vi kontrollerar kärna, plugin, uploads, mu-plugins, .htaccess och användarkonton med avseende på bakdörrar.
• Vid fynd tar vår skadlig kod-borttagning hand om saneringen tills incidenten är avslutad och dokumenterad; utan fynd härdar vi installationen inom ramen för PHP2Shell-akuthjälpen.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• PHP 8 ChangeLog
• WordPress.org
• BSI