Kort sagt: En WordPress-bagdør finder I hurtigst ved at sammenholde kerne og plugins via WP-CLI med de officielle kontrolsummer og derefter målrettet gennemgå mu-plugins, uploads, wp-config.php, admin-konti og database. Vigtigt efter PHP2Shell: En WordPress-opdatering lukker ikke PHP-sårbarheden og fjerner ingen eksisterende bagdør.
Hvorfor WordPress-driftsansvarlige bør se nærmere efter nu
Med PHP2Shell blev der i oktober 2026 kendt to kritiske sårbarheder i selve PHP, CVE-2026-109618 og CVE-2026-109619. De muliggør kørsel af skadelig kode uden login, uafhængigt af hvor velplejet jeres WordPress-installation er. Rettelser findes siden 21.10.2026, men ifølge medierapporter blev et første angrebsforsøg allerede observeret den 17.10.
Den, der var sårbar i dette tidsrum, bør lede efter spor. WordPress er her et typisk mål, fordi mange installationer er bygget ens op, og angribere kender gemmestederne. Hvad driftsansvarlige i almindelighed skal gøre ved PHP2Shell, står på siden WordPress og PHP2Shell.
Gennemgå de følgende kontroller helst på en kopi eller efter en sikkerhedskopi. Kommandoerne læser kun og ændrer intet.
Hvordan I opdager en bagdør i hverdagen
En bagdør er lavet til at forblive upåfaldende. Alligevel findes der tegn, som også opdages uden teknisk viden. Det gælder omdirigeringer til fremmede sider, der kun optræder for besøgende fra Google-søgning eller kun på mobile enheder. Lige så mistænkelige er nye sider med reklame for medicin, spil om penge eller kopier af mærkevarer, som optræder i søgeindekset, men ikke i WordPress-backend.
Yderligere tegn er advarsler fra Google eller browseren, kunders klager over spam-mails fra jeres domæne, et pludseligt kraftigt øget forbrug af regnetid hos hosteren eller administratorer, som ingen i teamet kender. Intet af dette beviser i sig selv en bagdør. Optræder flere sammen, bør I ikke udskyde de følgende kontroller.
Omvendt gælder: Hvis intet af dette falder i øjnene, betyder det ikke, at installationen er ren. Netop bagdøre, der kun er lagt ind til en senere adgang, viser udadtil ofte slet ingen virkning.
Find WordPress-bagdør: kontrollér kerne og plugins
WP-CLI kan sammenligne filerne i WordPress-kernen og i plugins fra det officielle bibliotek med de offentliggjorte kontrolsummer. Enhver afvigelse er en konkret kontrolopgave.
cd /var/www/meine-seite
# Kernefiler mod de officielle kontrolsummer
wp core verify-checksums
# Plugins fra det officielle bibliotek
wp plugin verify-checksums --all
# Installerede versioner og status
wp plugin list
wp theme list
Kommercielle plugins og temaer kan ikke kontrolleres på den måde. For dem hjælper kun en sammenligning med en frisk downloadet originalpakke fra udbyderen. Ukendte plugins, som ingen i teamet har installeret, er altid mistænkelige, også selv om de ser deaktiverede ud.
Typiske gemmesteder i filsystemet
Nogle steder dukker op igen og igen ved kompromitterede WordPress-installationer:
wp-content/mu-plugins/: indlæses automatisk og optræder ikke i den almindelige pluginliste.wp-content/uploads/: dér hører billeder og dokumenter hjemme, ikke PHP-filer.wp-config.php: ekstrainclude- ellerrequire-linjer i begyndelsen eller enden..htaccessog.user.inii webmappen og i undermapper: uventede omdirigeringer eller automatisk forudindlæste filer.- Filer i hovedmappen, hvis navne minder om WordPress-kernefiler, men ikke hører til.
# PHP-filer i upload-mappen
find wp-content/uploads -type f -name "*.php*"
# Indhold af Must-Use-plugins
ls -la wp-content/mu-plugins/
# Alle .htaccess- og .user.ini-filer med ændringsdato
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Nylig ændrede PHP-filer
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Almindelige søgemønstre for tilsløret kode beskriver vejledningen Opdag og fjern webshells.
Kontrollér brugere, database og planlagte opgaver
Mange bagdøre ligger slet ikke i filsystemet. En ekstra administratorkonto er ofte nok for angribere til senere at vende tilbage.
# Alle administratorer med registreringsdato
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Planlagte opgaver i WordPress
wp cron event list
# Sidens adresse (manipulationer fører til omdirigeringer)
wp option get siteurl
wp option get home
# Indlæg med indlejrede scripts
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Kontrollér også indstillinger med usædvanligt stort indhold og widgets med fremmed kode. Fund betyder ikke automatisk et angreb, for sporingskoder eller indlejrede kort bruger også scripts. Afgørende er, om nogen i teamet kender indholdet.
Skift efter et fund alle adgangskoder og sikkerhedsnøglerne i wp-config.php. Ellers forbliver angribernes eksisterende logins gyldige.
Luk bagdøre og forhindr gentagelse
Har I fundet en bagdør, er en nyinstallation som regel sikrere end at reparere enkelte filer. Denne rækkefølge har vist sit værd:
- Sikr spor: læg logs, mistænkelige filer og en database-eksport med dato til side.
- Bring PHP til en rettet status, og genstart alle PHP-processer.
- Installér WordPress-kerne, plugins og temaer friskt fra originalkilder.
- Overtag uploads og database efter kontrol, slet fremmede konti, skift alle adgange.
- Forhindr PHP-kørsel i upload-mappen på serverniveau.
For Nginx er en blok i serverkonfigurationen nok:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
Under Apache opnår I det samme med en regel i serverkonfigurationen for upload-mappen. En .htaccess i selve upload-mappen er svagere, fordi en angriber med skriverettigheder kan ændre den igen.
Planlæg efter oprydningen nogle ugers tættere overvågning. Nye administratorer, nye PHP-filer og ændringer i wp-config.php bør i den tid straks falde i øjnene, f.eks. via en regelmæssig kontrol med WP-CLI eller en filovervågning på serveren.
Hvordan I derefter sætter filrettighederne, så WordPress kun må skrive, hvor det er nødvendigt, viser vejledningen Filrettigheder på webserveren.
Hvordan hjælper PHP SOS konkret?
- Vi sikrer installationens tilstand, før noget ændres.
- Vi kontrollerer kerne, plugins, temaer, database, konti og serverkonfiguration for bagdøre.
- Vi opsætter WordPress på ny fra rene kilder og overtager kun kontrolleret indhold.
- Vi hærder server og installation og dokumenterer, hvad der blev fundet og udbedret.
Forløbet af en oprydning beskriver ydelsen Lad malware og webshells fjerne.
Ofte stillede spørgsmål
Lukker en WordPress-opdatering PHP2Shell-sårbarheden?
Nej. PHP2Shell sidder i PHP-fortolkeren, ikke i WordPress. En opdatering af WordPress, temaer eller plugins ændrer intet ved det; afgørende er serverens PHP-status og en genstart af alle PHP-processer.
Finder et sikkerhedsplugin alle bagdøre?
Ikke pålideligt. Et plugin kører inde i den kompromitterede installation og kan selv være manipuleret. Supplér det med kontrol udefra, f.eks. via WP-CLI-kontrolsummer og en sammenligning med rene originalfiler.
Hvad er mu-plugins, og hvorfor er de mistænkelige?
Must-Use-plugins i mappen wp-content/mu-plugins indlæses automatisk og optræder ikke i den almindelige pluginliste. Angribere benytter gerne det, fordi driftsansvarlige sjældent ser på den mappe.
Kan en bagdør også sidde i databasen?
Ja. Skadelig kode eller omdirigeringer lægges ofte i indstillinger, indlæg eller widgets. Desuden opretter angribere ofte egne administratorkonti, som I kan finde i brugertabellen.