Kort gezegd: Het WordPress-beveiligingslek waarover momenteel wordt bericht, zit niet in WordPress, maar in PHP op de server eronder. Een WordPress-update sluit PHP2Shell daarom niet. Beslissend zijn de patchstatus van PHP, de herstart van alle PHP-processen en een controle van typische schuilplaatsen zoals wp-content/uploads en mu-plugins.
Waarom een WordPress-update PHP2Shell niet verhelpt
WordPress is een applicatie die in PHP is geschreven. De kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 zitten een laag dieper, in de PHP-interpreter zelf. Volgens het PHP-team maken ze het mogelijk om op afstand en zonder inloggen schadelijke code uit te voeren. Bij Apache met mod_php is een exploit getoond voordat er zelfs maar WordPress-code draait.
Een website met een actuele core, actuele plug-ins en sterke wachtwoorden kan dus toch kwetsbaar zijn als de PHP eronder oud is. Omgekeerd bewijst een gepatchte PHP niet dat er daarvoor niets is gebeurd. De achtergronden leggen we uit onder Wat is PHP2Shell?.
| Laag | Wie werkt bij | Sluit PHP2Shell? |
|---|---|---|
| WordPress-core | U of uw bureau | Nee |
| Plug-ins en thema's | U of uw bureau | Nee |
| PHP op de server | Hostingprovider of serverbeheerder | Ja, samen met de herstart van alle PHP-processen |
WordPress-beveiligingslek in PHP: PHP-versie controleren
In het dashboard vindt u onder Hulpmiddelen > Websitegezondheid > Info in het onderdeel "Server" de PHP-versie waarmee uw website daadwerkelijk draait. Dat zegt meer dan php -v op de opdrachtregel, want de opdrachtregel gebruikt vaak een andere PHP-installatie dan de webserver.
Het getoonde nummer alleen volstaat toch niet. Verholpen upstreamversies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Veel hostingproviders voeren de correcties echter als backport door; dan blijft er een ouder nummer staan, terwijl er wel is gepatcht. Hoe u de echte status vaststelt, staat onder PHP-versie en patchstatus goed controleren. Welke PHP-versies uw WordPress-versie ondersteunt, controleert u volgens de systeemeisen op wordpress.org.
Waar schadelijke code zich in WordPress graag verbergt
Na een geslaagde aanval plaatsen daders meestal een achterdeur om ook na de patch terug te kunnen komen. WordPress kent daarvoor bekende plekken:
- wp-content/uploads/: bedoeld voor afbeeldingen en pdf's, niet voor PHP-bestanden.
- wp-content/mu-plugins/: "must-use"-plug-ins laden automatisch en zijn in het dashboard niet uit te schakelen.
- wp-config.php: bevat de databasetoegang en beveiligingssleutels; een ingevoegde regel valt hier nauwelijks op.
- .htaccess in de hoofdmap en in submappen: doorverwijzingen alleen voor zoekmachines of het uitvoeren van ongebruikelijke bestandsextensies.
- Thema's, vooral
functions.php, en uitgeschakelde, vergeten plug-ins. - Database: nieuwe beheerders in
wp_users, vreemd JavaScript inwp_optionsof in berichten.
Ongevaarlijke eerste controles met WP-CLI en standaardmiddelen:
# Core-bestanden vergelijken met de officiële controlesommen
wp core verify-checksums
# Plug-ins uit de map op wordpress.org controleren
wp plugin verify-checksums --all
# PHP-bestanden in de uploadmap weergeven
find wp-content/uploads -type f -name "*.php"
# Alle beheerders weergeven
wp user list --role=administrator
Een treffer is aanleiding voor nader onderzoek, maar nog geen bewijs. Commerciële plug-ins zijn op deze manier niet te controleren. Uitgebreider gaat het verder in de gids Backdoors in WordPress vinden.
Verwijder verdachte bestanden niet overhaast. Maak eerst een kopie van bestanden, database en serverlogs vanaf 20-10-2026. Zonder deze sporen is later niet vast te stellen of er gegevens zijn weggelekt.
Plug-ins, thema's en beheerderstoegang als extra risico
PHP2Shell heeft geen kwetsbaarheid in een plug-in nodig. In de dagelijkse praktijk blijven plug-ins en thema's echter de meest voorkomende toegangspoort tot WordPress-websites. Elke plug-in brengt eigen code, eigen uploadfuncties en eigen updatecycli mee. Ongebruikte plug-ins verwijdert u beter dan ze alleen te deactiveren, want gedeactiveerde bestanden blijven op de server staan.
Voor wp-login.php en wp-admin geldt: weinig beheerders, persoonlijke accounts in plaats van gedeelde toegang en tweestapsverificatie. Als u XML-RPC niet nodig hebt, kan het worden geblokkeerd. Bij een vermoeden moeten alle wachtwoorden en de beveiligingssleutels in wp-config.php worden vernieuwd. De bestandseditor in het dashboard schakelt u daar eveneens uit:
define( 'DISALLOW_FILE_EDIT', true );
Wat u als WordPress-beheerder nu moet doen
- Laat de PHP-patchstatus en de herstart van alle PHP-processen schriftelijk door uw hostingprovider bevestigen.
- Laat de serverlogs vanaf 20-10-2026 bewaren.
- Voer de bovenstaande controles uit of laat ze uitvoeren.
- Werk WordPress, plug-ins en thema's bij. Dat is juist, maar geen vervanging van stap 1.
- Zet de website bij opvallende bevindingen niet gewoon voort, maar laat hem reinigen.
Een platformupdate kan bekende kwetsbaarheden in WordPress en plug-ins dichten. Ze kan PHP niet repareren en geen binnengebrachte bestanden verwijderen die niet tot de core behoren.
Hoe helpt PHP SOS concreet?
- Wij stellen met u of uw hostingprovider de werkelijke PHP-status van uw WordPress-website vast, inclusief backports en herstart.
- Wij maken een kopie van logs, bestanden en database voordat er iets wordt gewijzigd.
- Wij controleren core, plug-ins, uploads, mu-plugins,
.htaccessen gebruikersaccounts op achterdeuren. - Bij vondsten neemt onze malwareverwijdering de reiniging over tot het incident is afgerond en gedocumenteerd; zonder vondsten beveiligen wij de installatie in het kader van de PHP2Shell-noodhulp.
Veelgestelde vragen
Moet ik WordPress vanwege PHP2Shell bijwerken?
Een actuele WordPress-versie is altijd verstandig, maar sluit PHP2Shell niet. De kwetsbaarheid zit in de PHP-interpreter van de server. Daarvoor is een PHP-update of een bevestigde backport van uw hostingprovider nodig, plus een herstart van alle PHP-processen.
Beschermt een beveiligingsplug-in tegen PHP2Shell?
Slechts in zeer beperkte mate. Een plug-in draait zelf als PHP-code binnen WordPress. Bij mod_php is een exploit getoond die werkt voordat applicatiecode zelfs maar start; een plug-in merkt zo'n aanval mogelijk helemaal niet.
Waarom toont WordPress nog een oude PHP-versie, terwijl de hostingprovider heeft gepatcht?
Veel hostingproviders en Linux-distributies voeren correcties als backport door in de bestaande versie. Het versienummer blijft dan gelijk. Laat de patchstatus schriftelijk door uw hostingprovider bevestigen.
Mag er in wp-content/uploads een PHP-bestand staan?
Normaal gesproken niet. De uploadmap is bedoeld voor media. Een PHP-bestand daar is een duidelijk waarschuwingssignaal en moet worden veiliggesteld en deskundig onderzocht voordat het wordt verwijderd.