# Waarom een WordPress-update niet helpt tegen PHP2Shell

> Waarom een WordPress-update niet helpt tegen het PHP-lek PHP2Shell, welke laag echt telt en wat WordPress-beheerders in plaats daarvan moeten controleren.

Bron: https://phpsos.de/nl/blog/warum-wordpress-update-nicht-hilft/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Een WordPress-update helpt niet tegen het PHP-lek PHP2Shell, omdat de fout niet in WordPress zit maar in PHP, de software op de server die WordPress uitvoert. Volgens Dr. Web plant WordPress.org daarom ook geen eigen update. Beschermen kan alleen een PHP-update op de server met herstart van alle PHP-processen. Die speelt in de regel uw hostingprovider of serverbeheerder in.

## Het begin: „We hebben toch alles bijgewerkt”

Na de eerste krantenkoppen over PHP2Shell hebben veel beheerders het voor de hand liggende gedaan: het WordPress-dashboard openen, op „Nu bijwerken” klikken, plug-ins en thema's meteen mee. Daarna is alles groen, en het gevoel zegt: klaar.

Bij dit lek bedriegt het gevoel. Dat ligt niet aan WordPress, maar aan de plek waar de fout zit. Ook Cloudflare wijst er in zijn melding op dat een update van toepassingscode of plug-ins de lekken niet verhelpt.

## WordPress-update en PHP-lek: het lagenmodel

Een WordPress-website bestaat uit meerdere lagen die op elkaar voortbouwen. Elke laag heeft eigen updates en vaak eigen verantwoordelijken:

| Laag | Voorbeeld | Wie werkt typisch bij | Getroffen door PHP2Shell? |
|---|---|---|---|
| Besturingssysteem | Debian, Ubuntu, AlmaLinux | hostingprovider of serverbeheerder | nee, maar levert vaak het PHP-pakket |
| Webserver | Apache, Nginx, LiteSpeed | hostingprovider of serverbeheerder | uitvoeringsmodus beïnvloedt het risico |
| PHP-runtime | PHP-FPM, mod_php | hostingprovider of serverbeheerder | ja, hier zit het lek |
| WordPress-kern | WordPress | beheerder of bureau | nee |
| Plug-ins en thema's | WooCommerce, pagebuilder | beheerder of bureau | nee |

De updateknop in het dashboard bereikt alleen de onderste twee regels. De PHP-runtime ligt daaronder en is voor WordPress onzichtbaar. Hoe andere systemen op PHP voortbouwen, beschrijft de bijdrage [CMS en webshops op PHP](https://phpsos.de/nl/php/cms-und-shops-auf-php/).

## Waarom WordPress het lek niet kan dichten

Men zou kunnen denken dat WordPress er „omheen kan programmeren”. Dat werkt bij PHP2Shell om twee redenen niet.

Ten eerste liggen beide fouten in de manier waarop PHP verzoeken verwerkt en daarna opruimt. Dat gebeurt los van welk programma er in PHP draait. Ten tweede heeft het PHP-team voor Apache met mod_php een exploit getoond die werkt voordat er zelfs maar toepassingscode wordt uitgevoerd. WordPress, zijn plug-ins en elke beveiligingsplug-in komen dan niet eens aan bod.

Om dezelfde reden helpt ook geen „hardening-plug-in” die instellingen via `ini_set()` wijzigt. php.net raadt uitdrukkelijk af tussentijdse maatregelen op die manier in te stellen.

### En bij managed WordPress?

Bij managed-WordPress-aanbiedingen zorgt de aanbieder vaak niet alleen voor WordPress-updates, maar ook voor de server eronder. Dat is voor PHP2Shell een voordeel, maar geen automatisme. Vraag concreet of de PHP-update is ingespeeld en alle PHP-processen zijn herstart. De uitspraak „Wij houden uw WordPress actueel” beantwoordt die vraag niet.

### Veel websites, één PHP-installatie

Bureaus en bedrijven met meerdere websites moeten een bijzonderheid kennen: op een server delen vaak veel WordPress-installaties dezelfde PHP-versie. Is die ongepatcht, dan zijn ze allemaal getroffen, ongeacht hoe goed elke afzonderlijke website wordt onderhouden. Omgekeerd beschermt een PHP-update alle installaties in één keer, mits daarna alle bijbehorende PHP-processen worden herstart. Wie meerdere PHP-versies naast elkaar draait, moet elke versie afzonderlijk bijwerken.

> **Belangrijk:**
> Een groen WordPress-dashboard zegt niets over PHP2Shell. Beslissend is de patchstatus van PHP op de server en de herstart van alle PHP-processen.

## De PHP-versie in WordPress juist lezen

WordPress toont de PHP-versie: in het dashboard onder Hulpmiddelen, Gezondheid van de site, in het gedeelte Rapport bij de sectie Server. Dat is een goede eerste aanwijzing, maar geen bewijs.

Staat daar een tak zoals 8.1 of ouder, dan is dat een duidelijk waarschuwingssignaal, want daarvoor zijn er geen officiële updates meer. Staat daar 8.2.35, 8.3.36, 8.4.27 of 8.5.12, dan is de verholpen stand geïnstalleerd. Staat daar een ouder nummer van een ondersteunde tak, dan kan toch een backport zijn ingespeeld. Distributies en hostingproviders wijzigen het nummer daarbij vaak niet. Duidelijkheid geeft alleen de bevestiging van de hostingprovider of een blik in de pakket-changelog. Hoe dat gaat, staat onder [PHP-versie en patchstatus controleren](https://phpsos.de/nl/php2shell/php-version-pruefen/).

## Wat WordPress-beheerders in plaats daarvan moeten doen

1. **Hostingprovider of serverbeheerder vragen:** Is PHP gepatcht, wanneer, en zijn alle PHP-processen herstart? Antwoord schriftelijk.
2. **PHP-tak controleren:** Draait de website op 8.1 of ouder, plan dan de overstap naar een ondersteunde tak. Welke versie uw WordPress-versie ondersteunt, staat in de systeemvereisten op wordpress.org. De overstap in het klantenmenu beschrijft [PHP-versie wijzigen in het klantenmenu van de hosting](https://phpsos.de/nl/blog/php-version-hosting-aendern/).
3. **Op sporen controleren:** nieuwe PHP-bestanden in `wp-content/uploads`, onbekende beheerdersaccounts, vreemde vermeldingen in `mu-plugins`. De typische schuilplaatsen beschrijft de pagina [WordPress en PHP2Shell](https://phpsos.de/nl/plattformen/wordpress/).
4. **WordPress toch actueel houden:** Kern, plug-ins en thema's dichten andere lekken. Dat blijft verplicht, alleen een andere verplichting.
5. **Verantwoordelijkheid regelen:** Als een bureau de website beheert, leg dan vast of het ook voor PHP verantwoordelijk is of alleen voor WordPress.

Juist het laatste punt zorgt vaak voor gaten. Het bureau onderhoudt WordPress, de hostingprovider de server, en ieder denkt dat de ander PHP2Shell in het oog heeft.

## Hoe helpt PHP SOS concreet?

- **Lagen ophelderen:** Wij stellen vast wie bij uw WordPress-website voor welke laag verantwoordelijk is.
- **PHP bijwerken:** Op eigen of beheerde servers spelen wij de PHP-update in en herstarten alle processen.
- **WordPress controleren:** Wij zoeken naar sporen van een aanval in bestanden, database en accounts.
- **Bewijs:** U ontvangt de patchstatus schriftelijk, ook om door te geven aan bureau of klanten.

Het verloop beschrijft de [PHP-patchservice](https://phpsos.de/nl/leistungen/php-patch-service/).

## Conclusie

De WordPress-update is goed onderhoud, maar tegen PHP2Shell de verkeerde laag. Het lek zit een verdieping lager, in PHP op de server. Wie dat begrijpt, stelt de juiste vraag aan de juiste instantie: is PHP gepatcht, herstart en aangetoond?


## Veelgestelde vragen

**Komt WordPress met een beveiligingsupdate tegen PHP2Shell?**  
Volgens Dr. Web plant WordPress.org geen update tegen PHP2Shell, omdat het lek in de PHP-interpreter op de server zit. Alleen een PHP-update door de hostingprovider of serverbeheerder helpt.

**Waar zie ik in WordPress de PHP-versie?**  
In het dashboard onder Hulpmiddelen, Gezondheid van de site, in het gedeelte Rapport bij de sectie Server. Het getoonde nummer zegt echter niet zeker of de patch is ingespeeld, omdat hostingproviders correcties vaak als backport zonder nieuw versienummer inbouwen.

**Beschermt een beveiligingsplug-in tegen PHP2Shell?**  
Maar zeer beperkt. Een plug-in draait zelf in PHP en wordt pas actief als WordPress is geladen. Bij Apache met mod_php is volgens het PHP-team een exploit getoond voordat er zelfs maar toepassingscode draait. Daar kan een plug-in niet ingrijpen.

**Moet ik WordPress toch bijwerken?**  
Ja. Actuele versies van WordPress, thema's en plug-ins dichten andere lekken en horen bij goed onderhoud. Ze lossen het probleem PHP2Shell alleen niet op.

## Bronnen

- [Dr. Web: PHP2Shell, update van de PHP-versies](https://www.drweb.de/php2shell-update-php-versionen/)
- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [WordPress.org](https://wordpress.org/)
- [Cloudflare-blog: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)