php2shell (CVE-2026-109618 en CVE-2026-109619): wat is het en wat moet je doen?

Controleer alleen systemen waarvan je zelf eigenaar of beheerder bent. Deze pagina en onze checker werken met het versienummer dat je zelf intypt. Er wordt niets getest, afgetast of gescand op een server. Onafhankelijke site, niet verbonden aan de PHP Group.

Kort antwoord

“php2shell” is de bijnaam die Wiz Research gaf aan twee kritieke PHP-kwetsbaarheden: CVE-2026-109618 en CVE-2026-109619. De PHP Group geeft beide een CVSS v4.0-score van 9.2 (kritiek) en zegt dat ze kunnen leiden tot remote code execution zonder inloggen: iemand op internet kan dan mogelijk code op je server laten draaien. Draait je server een lagere PHP-versie dan 8.2.35, 8.3.36, 8.4.27 of 8.5.12? Update dan nu en herstart PHP. Zit je op een oudere tak zoals 8.1 of 7.4, lees dan eerst het stuk over verouderde PHP-takken. De PHP Group schrijft in zijn eigen melding: “There are no complete mitigations, updating is the only safe choice.” Oftewel: de PHP Group kent geen volledige tijdelijke maatregel en wijst de update zelf aan.

Wat is php2shell in gewone taal?

• Twee kwetsbaarheden, één oplossing. De PHP Group noemt ze “RCE via OOM corruption” (GHSA-w8hw-w9fx-j79w) en “RCE via stale global state” (GHSA-6wmf-4rv5-p3rp). Dezelfde PHP-releases verhelpen allebei. Hoe ze precies werken leggen we niet uit, en dat hoef je ook niet te weten om te patchen.
• Ernst. Beide scoren CVSS v4.0 9.2, toegekend door de PHP Group zelf. NVD heeft er inmiddels een eigen score bij gezet: CVSS v3.1 9.8 (kritiek) voor CVE-2026-109618 en, sinds 22 oktober, 8.1 (hoog) voor CVE-2026-109619 (eerder 9.8). De score van de PHP Group (CVSS v4.0 9.2) blijft daarnaast staan.
• De naam. “php2shell” staat niet in de melding van php.net of in de CVE-records. De naam komt uit de blog van Wiz Research, waar NVD naar verwijst. CERT-EU en het NCSC gebruiken de naam ook in hun overzicht op GitHub.
• Wordt het misbruikt? De bronnen zeggen niet hetzelfde, dus per organisatie. De PHP Group ziet het hoogste risico bij mod_php en meldt dat daar een werkende aanval is aangetoond; die uitspraak gaat specifiek over mod_php. CERT-EU meldt dat de eerste proof-of-concepts (voorbeeldcode) rondgaan, wat volgens CERT-EU de kans vergroot dat aanvallers de kwetsbaarheden al misbruiken; bevestigd misbruik meldt CERT-EU niet. De PHP Foundation schrijft dat er proofs of concept rondgingen, maar dat het PHP-beveiligingsteam bij de release geen werkende exploits herkende. Het Canadese Cyber Centre meldt dat in open bronnen een PoC beschikbaar zou zijn en dat het geen actief misbruik zag, “maar dat kan snel veranderen”. Het Japanse IPA schreef in zijn melding van vóór de release dat het op dat moment geen aanval had bevestigd. Bij onze controle stonden de CVE’s niet in de KEV-lijst van CISA (de Amerikaanse lijst van bekend misbruikte kwetsbaarheden; de uitgave van 21 oktober, 14:04 UTC, was op 22 oktober rond 04:00 UTC nog de actuele en bevatte de CVE’s niet). De beoordeling van CISA in NVD gaf “exploitation: none”, maar die is van 21 oktober, 14:34 UTC (de releasedag) en dus ouder dan de berichten over rondgaande proof-of-concepts. Behandel het toch als spoedeisend.

Wat zegt het NCSC?

Het Nederlandse NCSC publiceerde op 21 oktober 2026 de melding NCSC-2026-0443, “Kwetsbaarheden verholpen in PHP”, met prioriteit “Hoog”. De kernzin: “Alle PHP-installaties die webverzoeken verwerken zijn getroffen.” Op de nieuwspagina kopt het NCSC: “Ernstige kwetsbaarheden in PHP: bereid je voor op patchen”. Het NCSC heeft ook een overzicht van producten met een PHP-afhankelijkheid op GitHub gezet. In het overzicht van het CSIRTs Network (ENISA) wordt het NCSC geciteerd met de waarschuwing dat minstens alle versies vanaf PHP 5 getroffen zijn.

Wie moet actie ondernemen?

Iedereen met een server die PHP gebruikt om webverzoeken te beantwoorden. De PHP Group schrijft: “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.” Dat geldt dus ook voor WordPress, WooCommerce, Laravel, Drupal en elk ander PHP-programma. Het gaat om de PHP-versie op de server, niet om de versie van je website of plugins.

Gepatchte PHP-versies per tak

Bron: php.net en ondersteunde versies. De GitHub-advisory noemt 8.2.* onder 8.2.35, 8.3.* onder 8.3.36, 8.4.* onder 8.4.27 en 8.5.* onder 8.5.12 als getroffen. De gegevens van NVD rekenen daarnaast elke PHP-versie onder 8.2.35 mee, dus ook 8.1 en ouder. PHP 8.2 krijgt nog maar tot eind 2026 beveiligingsupdates: plan dus een stap naar 8.3 of hoger. PHP 8.6.0 RC4 bevat de fixes, maar is een testversie die php.net niet voor productie aanbeveelt. De volledige lijst met distributiepakketten staat bij opgeloste versies.

Pakketten van Linux-distributies houden een oud nummer

Ubuntu, Debian en andere distributies verwerken de fix in hun bestaande versie (een zogeheten backport), dus het nummer blijft “oud” ogen terwijl je wel gepatcht bent. Vergelijk daarom met het opgeloste pakketnummer van je leverancier, niet met het nummer van php.net. Voorbeelden uit onze bronnen:

• Ubuntu 24.04 LTS: 8.3.6-0ubuntu0.24.04.13, Ubuntu 22.04 LTS: 8.1.2-1ubuntu2.28 (Ubuntu).
• Debian 13 (trixie): 8.4.27-1~deb13u1 (DSA-6574-1). Debian 12 (bookworm): 8.2.35-1~deb12u1 (DLA-4848-1).
• Red Hat heeft opgeloste pakketten voor RHEL 10 (php 8.3 en php8.4), RHEL 9 (php 8.0, php:8.2 en php:8.3) en RHEL 8 (php:7.4 en php:8.2); voor php:8.4 op RHEL 9 is er nog geen opgelost pakket (Red Hat). Rocky Linux en Oracle Linux volgden met eigen adviezen voor een deel van die pakketten (op versie 8 voor php:7.4 en php:8.2; Oracle Linux 9 ook voor php:8.2 8.2.35-1.module+el9.8.0+91079+4ad1bd7f en php:8.3 8.3.36-1.module+el9.8.0+91082+c865dc1a). AlmaLinux heeft adviezen voor AlmaLinux 10 (php 8.3 8.3.36-1.el10_2 en php8.4 8.4.27-1.el10_2), AlmaLinux 9 (php:8.3 8.3.36-1.module_el9.8.0+330+fdc30075) en AlmaLinux 8 (php:7.4 7.4.33-8.module_el8.10.0+4321+cf5fd4bb); voor andere builds is er geen bevestiging. Alpine 3.24 heeft opgeloste pakketten in de repository; ook voor Alpine 3.23 (php83 tot en met php85, bijvoorbeeld php84 8.4.27-r0), Alpine 3.22 (php82 tot en met php84, bijvoorbeeld php84 8.4.27-r0) en Alpine 3.21 (php82, 8.2.35-r0) staan inmiddels opgeloste pakketten, al had de community-repository van die releases volgens Alpine zijn einde van ondersteuning bereikt. Amazon Linux 2023 heeft ze voor php8.2 tot en met php8.5; voor php8.1 op Amazon Linux 2023 en voor het kern-php-pakket van Amazon Linux 2 staat ‘No Fix Planned’ (geen oplossing gepland).
• Debian 11 krijgt de fix alleen via Freexians betaalde ELTS; Debian zelf heeft geen vermelding (niet bevestigd). De volledige pakketnummers per distributie staan op opgeloste versies.

Verouderde PHP-takken

PHP 8.1 en ouder krijgen geen updates meer van het PHP-project (8.1 stopte op 31 dec 2025, 8.0 op 26 nov 2023, 7.4 op 28 nov 2022). Voor 7.4, 8.0 en 8.1 publiceerde het beveiligingsteam alleen minimale back-ports in broncode, bedoeld voor wie zelf compileert. Er is geen downloadbare release en geen versienummer. Voor 7.3 en ouder kondigt php.net niets aan. Het Franse CERT-FR rekent alle versies van 5.x tot en met 8.1.x als getroffen. De echte oplossing is overstappen op een ondersteunde tak. Lukt dat nu niet, vraag je OS-leverancier of hoster dan om een gepatcht pakket. De tijdelijke instellingen die php.net noemt verkleinen volgens php.net alleen de blootstelling aan bepaalde aanvalsroutes (“do not make an installation safe”): gebruik ze hooguit als noodgreep.

De 3 stappen: controleren, updaten, verifiëren

Maak eerst een back-up of snapshot, zeker als je naar een nieuwe PHP-tak gaat in plaats van een kleine update binnen je huidige tak.

Stap 1: controleren

Op een eigen server:

php -v                                  # PHP op de opdrachtregel; kan afwijken van PHP voor je website
ls /usr/sbin/php-fpm* 2>/dev/null       # FPM-programma's, daarna bijvoorbeeld: php-fpm8.3 -v
dpkg -l | grep -E '^ii +php'            # Debian / Ubuntu
rpm -qa | grep -i '^php'                # RHEL, AlmaLinux, Rocky

Op shared hosting zie je de PHP-versie meestal in het klantenpaneel van je hoster. In WordPress staat hij onder Extra, Sitediagnose, tabblad Info, onder “Server”. Typ de versie daarna in de checker en vergelijk met opgeloste versies. Bij een distributiepakket vergelijk je met het opgeloste pakketnummer van je leverancier. Meer uitleg: PHP-versie controleren.

Stap 2: updaten via je gebruikelijke weg

Debian / Ubuntu (vervang 8.3 door jouw tak):

sudo apt update
sudo apt install --only-upgrade 'php8.3*'

RHEL-familie (controleer eerst het advies van je leverancier: voor sommige streams, zoals php:8.4 op RHEL 9, en voor andere AlmaLinux-builds is er nog geen opgelost of bevestigd pakket):

sudo dnf check-update 'php*'
sudo dnf upgrade 'php*'

Docker: bouw opnieuw vanaf een bijgewerkte basis-image en maak de container opnieuw aan.

docker build --pull --no-cache -t mijnapp:patched .
docker compose up -d --force-recreate

Bouw je vanuit broncode, gebruik dan 8.2.35, 8.3.36, 8.4.27 of 8.5.12 van php.net. De PHP Group meldde op de releasedag dat de door vrijwilligers beheerde Remi-repository nog geen updates had en raadde aan over te stappen op pakketten van je distributie of zelf te bouwen. Inmiddels staan er in de Remi-repository PHP-builds van 21 oktober voor PHP 8.2 tot en met 8.5 op Enterprise Linux 8, 9 en 10.

Op shared hosting of beheerde hosting kun je meestal alleen de PHP-versie kiezen in het paneel. Dat is pas een oplossing als de hoster aangeeft dat die build gepatcht is.

Stap 3: herstarten en verifiëren

Een update werkt pas nadat het draaiende PHP-proces is herstart.

sudo systemctl restart php8.3-fpm       # jouw FPM-service; op RHEL: php-fpm
sudo systemctl restart apache2          # alleen bij mod_php (RHEL: httpd)
php -v
dpkg -l | grep -E '^ii +php8.3'

Controleer drie dingen: de geïnstalleerde versie komt overeen met de opgeloste versie van je leverancier, de service is zonder foutmelding herstart (systemctl status php8.3-fpm) en je website laadt nog. Bij containers draai je docker exec <container> php -v op de nieuwe container. Voer daarna de versie nog eens in bij de checker.

Wat melden hosters?

Hosters publiceren hun oplossing in verschillend tempo. Dit konden we bevestigen op 22 oktober 2026:

• Hostnet: meldt op zijn statuspagina: “De PHP-beveiligingsupdate is op al onze systemen uitgerold en de kwetsbaarheden zijn verholpen. Ook oudere PHP-versies zijn bijgewerkt via PHP Extended Support.” De tijdelijke maatregelen zijn op 22 okt om 02:26 CEST ingetrokken.
• TransIP: op transip.nl/nieuws, de blog en de kennisbank vonden we geen melding over deze kwetsbaarheid, en de statuspagina’s waren niet bereikbaar. Dat betekent niet dat het niet is opgelost, alleen dat we niets konden bevestigen.
• Hostinger: meldt op zijn statuspagina om 06:44 UTC op 22 oktober dat de PHP-upgrades klaar zijn op alle servers van beheerde hosting. Sommige sites tonen PHP 8.5.11 in plaats van 8.5.12; volgens Hostinger klopt dat, omdat de fix aan de versie van de site is toegevoegd. Klanten met Web Hosting, Agency Hosting of cPanel Hosting hoeven volgens Hostinger niets te doen; VPS-klanten beheren PHP zelf.
• Antagonist, Vimexx, Strato en Combell: deze hosters hebben we niet onderzocht, dus we doen er geen uitspraak over. Bekijk hun statuspagina of vraag het via een ticket.

Gebruikt je hoster een beheerpaneel? Voor cPanel geldt volgens de release notes dat EasyApache 4 25.91 (21 oktober) gepatchte PHP 8.2 tot en met 8.5 bevat, plus backports voor de verouderde ea-php74, ea-php80 en ea-php81. Bij Plesk zijn opgeloste builds voor PHP 8.2 tot en met 8.5 beschikbaar (op Linux en Windows); voor 7.4.33, 8.0.30 en 8.1.34 op Linux blijft het nummer gelijk en bevatten de builds van 21 oktober de fixes. Plesk vraagt om Plesk zelf bij te werken. Bij DirectAdmin moet je zelf da update en da build php draaien. De actuele stand per hoster en paneel vind je op hostingstatus. Wat we niet konden bevestigen, noemen we niet als bevestigd. Een firewall (WAF) of een door de hoster toegepaste beperking is een extra laag en geen vervanging voor een PHP-update, tenzij de hoster zegt dat de update zelf klaar is.

Meer lezen: php2shell en WordPress en de gids voor hosting.

Tijdlijn van officiële meldingen

Hulp bij jouw situatie?

Liever niet zelf uitzoeken welke stappen bij jouw server of hosting passen? Wij bieden een persoonlijk patchplan voor US$ 49: schriftelijke stappen voor jouw exacte situatie, per e-mail binnen 24 uur. We loggen nooit in op je server. Meer info op /nl/fix-service/.