Sinds de PHP2Shell-releases van 21 oktober 2026 heeft vrijwel elke hostingprovider een statusupdate gepubliceerd of een e-mail gestuurd. De meeste zeggen een variant van "onze servers zijn gepatcht". Dat klopt meestal, maar je kunt het niet controleren door de e-mail te lezen, en er gaan geregeld drie dingen mis: de patch wordt eerst op een deel van de servers uitgerold, het pakket is geïnstalleerd maar de PHP-workers zijn nooit herstart, of je eigen account wijst nog naar een end-of-life-versie die geen enkele patch dekt.
Zo controleer je elk van die drie punten, van het minst naar het meest technische.
1. Controleer de versie die je site echt gebruikt
Begin met wat je site zelf meldt: WordPress Gereedschap > Sitediagnose > Info > Server, een tijdelijke phpinfo-pagina of de PHP-keuze in je hostingpaneel. Onze handleiding voor de versiecheck loopt alle opties langs.
Vergelijk het resultaat met de gepatchte releases: 8.2.35, 8.3.36, 8.4.27 of 8.5.12. Zie je een van die versies of hoger, dan is de runtime gepatcht en kun je hier stoppen.
Is het nummer lager, raak dan nog niet in paniek. Er zijn twee mogelijke verklaringen: de host heeft niet gepatcht, of de host gebruikt een pakket dat de fix bevat zonder het nieuwe versienummer te dragen.
2. Begrijp waarom versienummers misleiden
Linux-distributies en diverse hostingplatformen porteren beveiligingsfixes terug. Ze passen de fix toe op de versie die ze al leveren en verhogen alleen de pakketrevisie. Ubuntu 24.04 levert bijvoorbeeld PHP 8.3.6 en blijft na de fix 8.3.6 melden. Hetzelfde geldt voor pakketten van Debian, Red Hat, AlmaLinux en Rocky, voor de EasyApache-builds van cPanel en voor de alt-php-builds van CloudLinux.
"8.3.6" op zichzelf zegt dus niets. Je moet weten of dat specifieke pakket de fix voor CVE-2026-109618 en CVE-2026-109619 bevat.
3. Stel de host de juiste vraag
Op shared of managed hosting kun je pakketten niet zelf inspecteren, maar je kunt wel precies vragen. Een goed supportticket luidt:
Welke PHP-pakketversie is geïnstalleerd op de server die mijn domein bedient, bevat dat pakket de fixes voor CVE-2026-109618 en CVE-2026-109619, en zijn de PHP-FPM- of Apache-processen herstart sinds het pakket is geïnstalleerd?
Een host die het werk heeft gedaan, beantwoordt alle drie in één regel. Vage antwoorden ("wij zijn beschermd", "onze firewall blokkeert het") zijn een signaal om door te vragen of de site te verhuizen.
Controleer ook de statuspagina van de host op een gedateerde melding. Hosts die voor pakketten afhankelijk zijn van een leverancier, zoals cPanel- of CloudLinux-partijen, publiceerden soms eerst een melding "wachten op builds van de leverancier", dus zorg dat je de laatste melding leest.
4. Controleer het zelf op een VPS of dedicated server
Met shell-toegang kun je alle drie de punten verifiëren.
De pakketversie en de changelog:
# Debian / Ubuntu
dpkg -s php8.3-fpm | grep Version
apt changelog php8.3-fpm | head -40
# RHEL / AlmaLinux / Rocky
rpm -q php-fpm
rpm -q --changelog php-fpm | head -20
dnf updateinfo list --cves | grep CVE-2026-1096
# cPanel EasyApache 4 en CloudLinux alt-php
/opt/cpanel/ea-php83/root/usr/bin/php -v
/opt/alt/php83/usr/bin/php -v
De changelog-regel hoort de CVE-nummers te noemen. Op Ubuntu en Debian kun je ook de beveiligingsmeldingen van de distributie (USN en DSA) doorzoeken op het php-pakket; is er nog geen melding voor jouw release, dan is het pakket niet gefixt, wat de versiestring ook zegt.
De herstart. Een bijgewerkt pakket vervangt geen code die al in draaiende processen is geladen. Vergelijk wanneer de service is gestart met wanneer het pakket is geïnstalleerd:
systemctl show php8.3-fpm --property=ActiveEnterTimestamp
ls -l --time-style=long-iso /usr/sbin/php-fpm8.3
Is de service gestart vóórdat het binaire bestand is weggeschreven, herstart hem dan (systemctl restart php8.3-fpm, of systemctl restart apache2 voor mod_php). Hetzelfde geldt voor containers: een opnieuw gebouwde image beschermt niets totdat de containers er opnieuw van zijn aangemaakt.
Je eigen versiekeuze. Op cPanel, Plesk en DirectAdmin kiest elk domein zijn eigen PHP-versie. De host kan elke ondersteunde reeks patchen en je site is nog steeds blootgesteld als de keuze op PHP 7.4 of 8.1 staat, omdat daar geen patch voor bestaat. Schakel over naar een ondersteunde reeks; ons end-of-life-artikel legt uit wat je kunt verwachten.
5. Wat externe scanners wel en niet kunnen zeggen
Verschillende online tools beloven een URL te scannen op PHP2Shell. Wees daar voorzichtig mee. Van buitenaf kan een scanner alleen lezen wat de server prijsgeeft, meestal de X-Powered-By-header, en de meeste goed geconfigureerde servers verbergen die (expose_php = Off). Een scanner die "niet kwetsbaar" zegt, bedoelt misschien alleen "kon de versie niet zien". Een scanner die de echte exploit op je site probeert, hoor je alleen te draaien met instemming van je host.
De betrouwbare controles zijn de bovenstaande: het pakket, de changelog, de herstart en je eigen versiekeuze.
Een korte checklist
- Site meldt 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 of hoger: klaar.
- Lager nummer op een distributie- of leverancierspakket: zoek de changelog of beveiligingsmelding die de CVE's noemt.
- Bevestig dat de PHP-processen zijn herstart nadat het pakket is geïnstalleerd.
- Bevestig dat je eigen domein niet vastzit op PHP 8.1 of ouder.
- Bewaar de schriftelijke bevestiging van de host bij je administratie.
Laat je dit liever door iemand anders nalopen, stuur ons dan je websiteadres en hostingprovider en we bevestigen waar je staat.