Kort sagt: En WordPress-bakdörr hittar ni snabbast genom att jämföra kärna och tillägg med de officiella kontrollsummorna via WP-CLI och därefter gå igenom mu-plugins, uppladdningar, wp-config.php, adminkonton och databas riktat. Viktigt efter PHP2Shell: En WordPress-uppdatering stänger inte PHP-sårbarheten och tar inte bort någon befintlig bakdörr.
Varför WordPress-ägare bör titta närmare nu
Med PHP2Shell har två kritiska sårbarheter i själva PHP blivit kända i oktober 2026, CVE-2026-109618 och CVE-2026-109619. De gör det möjligt att köra skadlig kod utan inloggning, oavsett hur välskött er WordPress-installation är. Patchar finns sedan den 21 oktober 2026, men enligt mediarapporter observerades ett första angreppsförsök redan den 17 oktober.
Den som var sårbar under den perioden bör söka efter spår. WordPress är ett typiskt mål, eftersom många installationer är uppbyggda på liknande sätt och angripare känner till gömställena. Vad driftansvariga allmänt behöver göra kring PHP2Shell står på sidan WordPress och PHP2Shell.
Gå helst igenom följande kontroller på en kopia eller efter en säkerhetskopiering. Kommandona läser bara och ändrar ingenting.
Hur ni märker en bakdörr i vardagen
En bakdörr är konstruerad för att vara oansenlig. Ändå finns tecken som syns även utan teknisk kunskap. Dit hör omdirigeringar till främmande sidor som bara uppträder för besökare från Google-sökningen eller bara på mobila enheter. Lika misstänkta är nya sidor med reklam för läkemedel, spel om pengar eller kopior av märkesvaror som syns i sökindexet men inte i WordPress backend.
Fler tecken är varningar från Google eller webbläsaren, klagomål från kunder över skräppost från er domän, plötsligt kraftigt ökad förbrukning av beräkningstid hos webbhotellet eller administratörer som ingen i teamet känner till. Inget av dessa tecken bevisar ensamt en bakdörr. Uppträder flera tillsammans bör ni inte skjuta upp de följande kontrollerna.
Omvänt gäller: Om inget av detta sticker ut betyder det inte att installationen är ren. Just bakdörrar som bara lagts upp för senare åtkomst visar ofta ingen effekt utåt alls.
Hitta en WordPress-bakdörr: kontrollera kärna och tillägg
WP-CLI kan jämföra filerna i WordPress-kärnan och tilläggen från den officiella katalogen med de publicerade kontrollsummorna. Varje avvikelse är ett konkret kontrolluppdrag.
cd /var/www/meine-seite
# Kärnfiler mot de officiella kontrollsummorna
wp core verify-checksums
# Tillägg från den officiella katalogen
wp plugin verify-checksums --all
# Installerade versioner och status
wp plugin list
wp theme list
Kommersiella tillägg och teman går inte att kontrollera på det här sättet. För dem hjälper bara en jämförelse med ett nyligen nedladdat originalpaket från leverantören. Okända tillägg som ingen i teamet har installerat är alltid misstänkta, även om de verkar vara avaktiverade.
Typiska gömställen i filsystemet
Vissa platser dyker upp om och om igen i komprometterade WordPress-installationer:
wp-content/mu-plugins/: läses in automatiskt och visas inte i den vanliga tilläggslistan.wp-content/uploads/: där hör bilder och dokument hemma, inga PHP-filer.wp-config.php: extrainclude- ellerrequire-rader i början eller slutet..htaccessoch.user.inii webbkatalogen och undermappar: oväntade omdirigeringar eller automatiskt förladdade filer.- Filer i huvudkatalogen vars namn påminner om WordPress-kärnfiler men som inte hör dit.
# PHP-filer i uppladdningsmappen
find wp-content/uploads -type f -name "*.php*"
# Innehåll i must-use-tilläggen
ls -la wp-content/mu-plugins/
# Alla .htaccess- och .user.ini-filer med ändringsdatum
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Nyligen ändrade PHP-filer
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Allmänna sökmönster för förvrängd kod beskrivs i guiden Upptäcka och ta bort webshell.
Granska användare, databas och schemalagda uppgifter
Många bakdörrar finns inte alls i filsystemet. Ett extra administratörskonto räcker ofta för angripare för att komma tillbaka senare.
# Alla administratörer med registreringsdatum
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Schemalagda uppgifter i WordPress
wp cron event list
# Webbplatsens adress (manipulationer leder till omdirigeringar)
wp option get siteurl
wp option get home
# Inlägg med inbäddade skript
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Granska också alternativ med ovanligt stort innehåll och widgets med främmande kod. Träffar betyder inte automatiskt ett angrepp, eftersom spårningskoder eller inbäddade kartor också använder skript. Avgörande är om någon i teamet känner till innehållet.
Byt efter ett fynd alla lösenord och säkerhetsnycklarna i wp-config.php. Annars förblir angriparnas befintliga inloggningar giltiga.
Stänga bakdörrar och förhindra återkomst
Har ni hittat en bakdörr är en nyinstallation oftast säkrare än att reparera enskilda filer. Den här ordningen har visat sig fungera:
- Säkra spår: spara loggar, misstänkta filer och en databasexport med datum.
- Uppgradera PHP till en åtgärdad nivå och starta om alla PHP-processer.
- Installera WordPress-kärna, tillägg och teman på nytt från originalkällor.
- Ta över uppladdningar och databas efter granskning, ta bort främmande konton och byt alla åtkomstuppgifter.
- Förhindra PHP-körning i uppladdningsmappen på servernivå.
För Nginx räcker ett block i serverkonfigurationen:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
Under Apache uppnår ni samma sak med en regel i serverkonfigurationen för uppladdningsmappen. En .htaccess i själva uppladdningsmappen är svagare, eftersom en angripare med skrivrättigheter kan ändra den igen.
Planera in några veckors närmare övervakning efter saneringen. Nya administratörer, nya PHP-filer och ändringar i wp-config.php bör under den tiden synas direkt, till exempel genom en regelbunden kontroll med WP-CLI eller en filövervakning på servern.
Hur ni därefter sätter filrättigheterna så att WordPress bara får skriva där det behövs visar guiden Filrättigheter på webbservern.
Hur hjälper PHP SOS konkret?
- Vi säkrar installationens tillstånd innan något ändras.
- Vi kontrollerar kärna, tillägg, teman, databas, konton och serverkonfiguration efter bakdörrar.
- Vi sätter upp WordPress på nytt från rena källor och tar bara över granskat innehåll.
- Vi härdar server och installation och dokumenterar vad som hittats och åtgärdats.
Förloppet vid en sanering beskrivs i tjänsten Låt ta bort skadlig kod och webshells.
Vanliga frågor
Stänger en WordPress-uppdatering sårbarheten PHP2Shell?
Nej. PHP2Shell finns i PHP-tolken, inte i WordPress. En uppdatering av WordPress, teman eller tillägg ändrar ingenting; det avgörande är serverns PHP-nivå och en omstart av alla PHP-processer.
Hittar ett säkerhetstillägg alla bakdörrar?
Inte tillförlitligt. Ett tillägg körs inne i den komprometterade installationen och kan självt vara manipulerat. Komplettera det med kontroller utifrån, till exempel WP-CLI-kontrollsummor och en jämförelse med rena originalfiler.
Vad är mu-plugins och varför är de misstänkta?
Must-use-tillägg i mappen wp-content/mu-plugins läses in automatiskt och visas inte i den vanliga tilläggslistan. Angripare utnyttjar gärna det, eftersom driftansvariga sällan tittar i den mappen.
Kan en bakdörr också finnas i databasen?
Ja. Skadlig kod eller omdirigeringar läggs ofta i alternativ, inlägg eller widgets. Dessutom skapar angripare ofta egna administratörskonton, som ni hittar i användartabellen.