WordPress-backdoor vinden: achterdeurtjes systematisch opsporen

Kort gezegd: Een WordPress-backdoor vindt u het snelst door kern en plug-ins met WP-CLI te vergelijken met de officiële controlesommen en daarna gericht mu-plugins, uploads, wp-config.php, beheerdersaccounts en database na te lopen. Belangrijk na PHP2Shell: een WordPress-update dicht de PHP-kwetsbaarheid niet en verwijdert geen bestaand achterdeurtje.

Waarom WordPress-beheerders nu nauwkeuriger moeten kijken

Met PHP2Shell zijn in oktober 2026 twee kritieke kwetsbaarheden in PHP zelf bekend geworden, CVE-2026-109618 en CVE-2026-109619. Ze maken het mogelijk om zonder aanmelding schadelijke code uit te voeren, ongeacht hoe goed uw WordPress-installatie is onderhouden. Patches zijn er sinds 21-10-2026, maar volgens mediaberichten werd al op 17-10. een eerste aanvalspoging waargenomen.

Wie in die periode kwetsbaar was, moet naar sporen zoeken. WordPress is daarbij een typisch doelwit, omdat veel installaties op elkaar lijken en aanvallers de schuilplaatsen kennen. Wat beheerders in het algemeen rond PHP2Shell moeten doen, staat op de pagina WordPress en PHP2Shell.

Doorloop de volgende controles bij voorkeur op een kopie of na een back-up. De opdrachten lezen alleen en veranderen niets.

Waaraan u een backdoor in het dagelijks gebruik merkt

Een achterdeur is erop gebouwd om onopvallend te blijven. Toch zijn er tekenen die ook zonder technische kennis opvallen. Daartoe horen doorverwijzingen naar andere sites die alleen optreden bij bezoekers uit Google of alleen op mobiele apparaten. Net zo verdacht zijn nieuwe pagina's met reclame voor medicijnen, gokken of namaak van merkproducten, die in de zoekindex staan maar niet in de WordPress-backend.

Verdere aanwijzingen zijn waarschuwingen van Google of de browser, klachten van klanten over spam van uw domein, een plotseling sterk gestegen verbruik van rekentijd bij de hoster of beheerders die niemand in het team kent. Geen van deze tekenen bewijst op zichzelf een backdoor. Komen er meerdere samen voor, stel de volgende controles dan niet uit.

Omgekeerd geldt: als niets hiervan opvalt, betekent dat niet dat de installatie schoon is. Juist achterdeurtjes die alleen voor latere toegang zijn aangelegd, hebben naar buiten vaak helemaal geen zichtbaar effect.

WordPress-backdoor vinden: kern en plug-ins controleren

WP-CLI kan de bestanden van de WordPress-kern en van plug-ins uit de officiële map vergelijken met de gepubliceerde controlesommen. Elke afwijking is een concrete controleopdracht.

cd /var/www/meine-seite
# Kernbestanden tegen de officiële controlesommen
wp core verify-checksums
# Plug-ins uit de officiële map
wp plugin verify-checksums --all
# Geïnstalleerde versies en status
wp plugin list
wp theme list

Commerciële plug-ins en thema's laten zich zo niet controleren. Daarvoor helpt alleen de vergelijking met een vers gedownload origineel pakket van de aanbieder. Onbekende plug-ins die niemand in het team heeft geïnstalleerd, zijn altijd verdacht, ook als ze gedeactiveerd lijken.

Typische schuilplaatsen in het bestandssysteem

Enkele plekken duiken bij gecompromitteerde WordPress-installaties steeds weer op:

• wp-content/mu-plugins/: wordt automatisch geladen en verschijnt niet in de gewone plug-inlijst.
• wp-content/uploads/: daar horen afbeeldingen en documenten, geen PHP-bestanden.
• wp-config.php: extra include- of require-regels aan het begin of einde.
• .htaccess en .user.ini in de webmap en in submappen: onverwachte doorverwijzingen of automatisch vooraf geladen bestanden.
• Bestanden in de hoofdmap waarvan de namen doen denken aan WordPress-kernbestanden, maar die er niet bij horen.

# PHP-bestanden in de uploadmap
find wp-content/uploads -type f -name "*.php*"
# Inhoud van de must-use-plug-ins
ls -la wp-content/mu-plugins/
# Alle .htaccess- en .user.ini-bestanden met wijzigingsdatum
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Onlangs gewijzigde PHP-bestanden
find . -type f -name "*.php" -newermt "2026-10-17" -ls

Algemene zoekpatronen voor versluierde code beschrijft de gids Webshells herkennen en verwijderen.

Gebruikers, database en geplande taken controleren

Veel achterdeurtjes liggen helemaal niet in het bestandssysteem. Een extra beheerdersaccount volstaat aanvallers vaak om later terug te keren.

# Alle beheerders met registratiedatum
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Geplande taken in WordPress
wp cron event list
# Adres van de site (manipulaties leiden tot doorverwijzingen)
wp option get siteurl
wp option get home
# Berichten met ingebedde scripts
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"

Controleer ook opties met ongewoon grote inhoud en widgets met vreemde code. Treffers wijzen niet automatisch op een aanval, want trackingcodes of ingebedde kaarten gebruiken ook scripts. Beslissend is of iemand in het team de inhoud kent.

Achterdeurtjes sluiten en terugkeer voorkomen

Hebt u een backdoor gevonden, dan is een nieuwe installatie meestal veiliger dan het repareren van afzonderlijke bestanden. Deze volgorde heeft zich bewezen:

1. Sporen veiligstellen: logs, verdachte bestanden en een database-export met datum bewaren.
2. PHP naar een verholpen stand brengen en alle PHP-processen herstarten.
3. WordPress-kern, plug-ins en thema's vers uit originele bronnen installeren.
4. Uploads en database gecontroleerd overnemen, vreemde accounts verwijderen, alle toegangen wijzigen.
5. PHP-uitvoering in de uploadmap op serverniveau verhinderen.

Voor Nginx volstaat daarvoor een blok in de serverconfiguratie:

location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
}

Onder Apache bereikt u hetzelfde met een regel in de serverconfiguratie voor de uploadmap. Een .htaccess in de uploadmap zelf is zwakker, omdat een aanvaller met schrijfrechten hem weer kan wijzigen.

Plan na de schoonmaak enkele weken nauwere bewaking in. Nieuwe beheerders, nieuwe PHP-bestanden en wijzigingen in wp-config.php moeten in die tijd meteen opvallen, bijvoorbeeld door een regelmatige controle met WP-CLI of bestandsbewaking op de server.

Hoe u de bestandsrechten daarna zo instelt dat WordPress alleen mag schrijven waar dat nodig is, laat de gids Bestandsrechten op de webserver zien.

Hoe helpt PHP SOS concreet?

• We stellen de toestand van de installatie veilig voordat er iets wordt gewijzigd.
• We controleren kern, plug-ins, thema's, database, accounts en serverconfiguratie op achterdeurtjes.
• We zetten WordPress opnieuw op vanuit schone bronnen en nemen alleen gecontroleerde inhoud over.
• We verharden server en installatie en documenteren wat is gevonden en verholpen.

Het verloop van een schoonmaak beschrijft de dienst Malware en webshells laten verwijderen.

Veelgestelde vragen

Bronnen

• WordPress.org
• php.net: beveiligingsmeldingen
• OWASP Cheat Sheet Series