PHP2Shell (CVE-2026-109618 en CVE-2026-109619): Wat het is en hoe je je servers kunt patchen en beschermen

Op 21 oktober 2026 heeft het PHP-project noodbeveiligingsupdates uitgebracht voor twee kritieke kwetsbaarheden die onauthentieke externe code-uitvoering (RCE) kunnen toestaan. De problemen zijn bijgenaamd PHP2Shell en worden gevolgd als CVE-2026-109618 en CVE-2026-109619. Beide zijn beoordeeld als CVSS v4.0 9.2 (Kritiek).

Beveiligingsonderzoekers bij watchTowr melden dat ze al actieve exploitatiepogingen zien, en het National Cyber Security Centre (NCSC) van het VK heeft een waarschuwing uitgegeven. Als je WordPress, WooCommerce, Magento, Drupal, Laravel of een andere PHP-toepassing draait, beschouw dit dan als een noodsituatie.

Deze gids legt uit wat er wordt beïnvloed en geeft stapsgewijze instructies voor het patchen van de meest voorkomende configuraties. Het behandelt ook wat te doen als je vandaag niet kunt patchen en hoe je kunt controleren of een server is gecompromitteerd.

Korte versie: update PHP naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 (of het gepatchte pakket van je distributie), en herstart elke PHP-werknemer. Alleen configuratiewijzigingen maken een server niet veilig.

Wat is PHP2Shell?

PHP2Shell is de naam voor twee gerelateerde geheugenveiligheidsfouten in de PHP-engine. Beide zijn opgelost in dezelfde releases.

	CVE-2026-109618	CVE-2026-109619
PHP naam	RCE via OOM-corruptie	RCE via verouderde globale status
Advies	GHSA-w8hw-w9fx-j79w	GHSA-6wmf-4rv5-p3rp
Ernstigheid	CVSS v4.0 9.2, Kritiek	CVSS v4.0 9.2, Kritiek
Hoofdoorzaak	Out-of-memory verwerking kan PHP onderbreken terwijl interne aanvraaggegevens slechts gedeeltelijk zijn geïnitialiseerd, en het opruimen van aanvragen kan die ongeldige gegevens dan als geldig behandelen.	De interne staat die behoort tot één verzoek kan overleven nadat het geheugen is vrijgegeven, en een later verzoek dat door dezelfde worker wordt afgehandeld, kan het gebruiken (use-after-free)
Resultaat	Mogelijke externe code-uitvoering met de privileges van de webserver/werknemer	Mogelijke externe code-uitvoering met de privileges van de webserver/werknemer

Het belangrijke deel voor site-eigenaren: deze bugs bevinden zich in PHP zelf, niet in WordPress, Magento of uw plugins. PHP verwerkt het verzoek van de aanvaller, dus zelfs een volledig bijgewerkte applicatie is blootgesteld als de PHP-runtime eronder kwetsbaar is. Volgens de PHP-adviezen werd een exploit gedemonstreerd tegen Apache mod_php waarbij een niet-geauthenticeerd verzoek de aanval activeert voordat er enige applicatiecode wordt uitgevoerd.

Welke versies zijn getroffen?

PHP tak	Kwetsbaar	Vastgelegd in
8.5	voor 8.5.12	8.5.12
8.4	voor 8.4.27	8.4.27
8.3	voor 8.3.36	8.3.36
8.2	voor 8.2.35	8.2.35
8.1, 8.0, 7.4	Ja	Geen officiële release. Minimale source backports van het PHP-beveiligingsteam, of vendor/LTS backports
Oudere (7.3 en lager, 5.x)	Neem aan dat ja	Geen oplossing. Upgrade.

Let op dat PHP 8.2 op 31 december 2026 het einde van zijn levenscyclus bereikt, dus plan een upgrade naar 8.4 of 8.5 na het patchen.

Welke configuraties lopen risico?

Volgens de PHP-adviezen zijn alle PHP-installaties die webverzoeken bedienen in gevaar. Dit omvat:

Apache met mod_php: hoogste risico, met een aangetoonde pre-applicatie exploit
PHP-FPM (Nginx, Apache met proxy_fcgi, Caddy en anderen)
php-cgi
FrankenPHP
LiteSpeed (LSAPI)

Gedeelde hosting, beheerde WordPress-hosting, VPS’en, containers en Windows-servers vallen allemaal binnen de reikwijdte als ze een kwetsbare PHP-versie voor webverzoeken draaien.

Stap 1: Zoek elke PHP-installatie

Je kunt niet patchen wat je niet kent. Maak een lijst van alle servers, containers en hostingaccounts die PHP draaien, te beginnen met de internetgerichte.

Controleer de PHP-versie op de opdrachtregel:

php -v

De CLI-versie kan verschillen van de versie die uw website bedient. Controleer ook de PHP van de webserver:

PHP-FPM: php-fpm8.3 -v (Debian/Ubuntu naamgeving), of php-fpm -v
Lijst geïnstalleerde PHP-pakketten (Debian/Ubuntu): dpkg -l | grep -E '^ii\s+php'
Lijst geïnstalleerde PHP-pakketten (RHEL/Alma/Rocky): rpm -qa | grep -i php
In WordPress: Gereedschappen → Sitegezondheid → Informatie → Server toont de PHP-versie die door de site wordt gebruikt
In Magento: controleer bij uw host of op de server, aangezien verschillende PHP-versies vaak naast elkaar zijn geïnstalleerd

Vergeet de staging servers, oude testsites, interne tools, monitoring dashboards en vergeten subdomeinen niet. Aanvallers vinden die ook.

Stap 2: Update PHP

Linux-distributies en LTS-leveranciers hebben de patches van tevoren ontvangen, dus gepatchte pakketten zouden beschikbaar moeten zijn of binnenkort arriveren. Controleer altijd de beveiligingstracker van uw leverancier voor de exacte pakketversie die de oplossing bevat. Distributiepakketten behouden vaak het oude versienummer en voegen een patch-suffix toe. Bijvoorbeeld, Ubuntu of Debian kan een gefixt “8.3.x” pakket leveren dat niet 8.3.36 zegt. Controleer het changelog of de beveiligingsmelding van uw distributie voor de CVE-ID’s.

Debian en Ubuntu

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php
sudo apt install --only-upgrade 'php*'

Bevestig dat het geïnstalleerde pakket CVE-2026-109618 / CVE-2026-109619 in zijn changelog vermeldt:

apt changelog php8.3-fpm | head -40

(Vervang php8.3-fpm door de naam van uw pakket.)

Als je een externe PHP-repository gebruikt (bijvoorbeeld een PPA of een Sury-repository), controleer dan ook die repository op bijgewerkte pakketten.

RHEL, AlmaLinux, Rocky Linux, CentOS Stream

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

Belangrijk als je de Remi-repository (rpms.remirepo.net) gebruikt: het PHP-project stelt dat deze door vrijwilligers onderhouden repository geen updates op de releasedatum zal hebben. Ze raden aan over te schakelen naar distributiepakketten of zelf te bouwen, zodat je onmiddellijk kunt patchen. Controleer of Remi sindsdien gefixte pakketten heeft gepubliceerd. Als dat niet het geval is, wacht dan niet.

Docker en containers

Het bijwerken van de host lost PHP binnen containers niet op. Je moet de afbeeldingen opnieuw bouwen:

Werk de basis afbeeldings-tag bij naar een gepatchte versie, bijvoorbeeld php:8.3.36-fpm of php:8.4.27-apache (of de 8.x tag zodra deze naar de gefixte release verwijst)
Herbouw zonder cache zodat de nieuwe basis wordt opgehaald:

docker build --pull --no-cache -t your-app:patched .

Herdeploy elke container en controleer de versie binnenin:

docker exec <container> php -v

Controleer ook afbeeldingen die je zelf niet bouwt, zoals officiële WordPress-, Nextcloud- of leverancierafbeeldingen, en werk ze bij zodra gepatchte versies worden gepubliceerd.

Gedeeld en beheerd hosting

Controleer uw hosting controlepaneel (cPanel, Plesk, DirectAdmin) voor de PHP-versie per site
Vraag je host rechtstreeks of hun PHP-builds de fixes voor CVE-2026-109618 en CVE-2026-109619 bevatten, en wanneer deze zijn uitgerold.
Als je site draait op PHP 8.1 of ouder, schakel dan nu over naar een ondersteunde versie (test op staging als je kunt, maar stel het niet wekenlang uit)

cPanel/EasyApache, Plesk en andere panels

Panelleveranciers verzenden hun eigen PHP-builds. Voer het normale updateproces van het paneel uit en controleer de aankondiging van de leverancier voor de gepatchte buildversies.

Windows

Download de gepatchte Windows-builds van de officiële PHP-downloadpagina, vervang de PHP-directory (houd je php.ini), en herstart IIS of de PHP-service.

Bouwen vanuit de bron

Download 8.5.12, 8.4.27, 8.3.36 of 8.2.35 van php.net. Voor PHP 7.4, 8.0 en 8.1 heeft het PHP-beveiligingsteam minimale source backport branches gepubliceerd die zijn gelinkt vanuit de officiële advies. Gebruik ze alleen als een tijdelijke brug naar een ondersteunde versie.

Stap 3: Herstart elke PHP-werknemer

Dit is de stap die mensen vergeten. PHP-FPM-pools, Apache met mod_php en andere langdurige PHP-processen houden de oude code in het geheugen totdat ze opnieuw worden opgestart.

# PHP-FPM (Debian/Ubuntu, adjust the version)
sudo systemctl restart php8.3-fpm

# PHP-FPM (RHEL family)
sudo systemctl restart php-fpm

# Apache with mod_php
sudo systemctl restart apache2   # Debian/Ubuntu
sudo systemctl restart httpd     # RHEL family

# LiteSpeed
sudo systemctl restart lsws

Als je meerdere PHP-versies naast elkaar draait (bijvoorbeeld php8.2-fpm en php8.3-fpm), patch en herstart dan alle versies.

Stap 4: Verifiëren

Voer php -v uit en de FPM-binaire -v opnieuw.
Maak een tijdelijke phpinfo() pagina op een niet-publieke locatie, controleer de versie en verwijder deze onmiddellijk
In de WordPress Sitegezondheid of de systeeminfo van uw applicatie, bevestig de nieuwe versie
In containers, controleer binnen elke draaiende container

Als u vandaag niet kunt patchen: tijdelijke mitigaties

Het PHP-project is heel duidelijk: alleen een update is een complete oplossing. De onderstaande maatregelen verminderen de blootstelling aan de bekende aanvalspaden. Ze maken een server niet veilig. Gebruik ze alleen als een brug van uren of dagen, niet weken.

Verminder eerst de blootstelling

Beperk internettoegang tot PHP-systemen die je niet onmiddellijk kunt patchen. Gebruik een VPN of IP-toegangslijst voor beheerpaneel en interne tools
Voor niet-essentiële systemen, overweeg ze offline te halen totdat ze zijn gepatcht, zoals het UK NCSC adviseert waar onmiddellijke remedie niet mogelijk is.

Voor CVE-2026-109618 (OOM-corruptie)

Stel memory_limit=-1 in op een manier waarop applicaties dit niet kunnen overschrijven, bijvoorbeeld met php_admin_value[memory_limit] = -1 in de FPM-pool of php_admin_value memory_limit -1 in de Apache-configuratie. Controleer of geen enkele pool, directory of applicatie-instelling een eindige limiet terugzet.
Omdat dit de eigen geheugengrens van PHP verwijdert, gebruik een container of cgroup geheugengrens als veiligheidsgrens. Gebruik geen RLIMIT_AS of RLIMIT_DATA hiervoor. De waarschuwing geeft aan dat ze de kwetsbare toewijzingsfout kunnen veroorzaken.
Verlaag post_max_size. De aanbeveling suggereert 8M voor applicaties zonder uploads en 32M waar uploads nodig zijn, met upload_max_filesize onder post_max_size
Handhaaf limieten voor aanvraaggrootte, veldtelling, aantal multipart-onderdelen, header-telling en geneste limieten op het niveau van de webserver, proxy of WAF, inclusief voor aanvragen zonder een bruikbare Content-Length

Voor CVE-2026-109619 (verouderde globale status)

Stel session.upload_progress.enabled=0 in php.ini, de FPM-pool of serverconfiguratie in (niet met ini_set() of .user.ini), en start vervolgens elke worker opnieuw op. De aanbeveling is om dit uit te laten, zelfs na het patchen, als je geen uploadvoortgang nodig hebt.
Op PHP 8.5, stel fatal_error_backtraces=0 in en herstart elke worker
Verwijder ongeldige of verouderde PHP-instellingen per verzoek die waarschuwingen veroorzaken vóór de initialisatie van het verzoek. Het verbergen van waarschuwingen met display_errors of error_reporting helpt niet.
Los fatale fouten en uitvoeringstijdslimieten op die aanvallers kunnen activeren, bijvoorbeeld bij upload- of importverwerking.

Voorbeeld van een PHP-FPM poolbestand (/etc/php/8.3/fpm/pool.d/www.conf):

php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off

Test eerst op staging. Een memory_limit van -1 in combinatie met een ontbrekende container of cgroup limiet kan ervoor zorgen dat een enkele runaway script al het geheugen van de server gebruikt.

Stap 5: Controleer op tekenen van compromittering

Er worden al pogingen tot exploitatie waargenomen, dus alleen patchen is niet genoeg voor internetgerichte servers die blootgesteld zijn. Voordat er grote wijzigingen worden aangebracht, bewaar bewijs: kopieën van webserver- en PHP-logboeken, configuratie en verdachte bestanden.

Controleer dan op:

Nieuwe of gewijzigde PHP-bestanden, vooral in uploadmappen waar geen PHP zou moeten bestaan:

find /var/www -type f -name "*.php" -mtime -7
find /var/www -path "*/uploads/*" -name "*.php"

Web shells: kleine PHP-bestanden met obfuscated code, eval, base64_decode, system, shell_exec of assert op ongebruikelijke plaatsen
Onverwachte cron-taken, vooral voor de webservergebruiker:

sudo crontab -l -u www-data
ls -la /etc/cron.* /var/spool/cron/ 2>/dev/null

Nieuwe systeem- of applicatieaccounts: nieuwe WordPress- of Magento-beheerders, nieuwe SSH-sleutels in ~/.ssh/authorized_keys
Ongewone processen of uitgaande verbindingen die draaien als de webservergebruiker:

ps -u www-data -f
sudo ss -tunp | grep -E 'php|www-data|apache|nginx'

Webserverfouten en crashes: een piek in PHP-FPM-werknemerscrashes (segfaults) of out-of-memory-fouten in de logs kan wijzen op pogingen tot exploitatie

Als je tekenen van compromittering vindt, behandel de server dan als onbetrouwbaar. Draai alle inloggegevens waarmee toegang is verkregen (database, API-sleutels, SSH-sleutels, betalingsintegraties) en overweeg om opnieuw op te bouwen vanuit een schone staat en gegevens te herstellen vanuit een back-up die is gemaakt voor de compromittering. Mijn WordPress malware schoonmaakgids en server back-upstrategie behandelen deze stappen.

Snelle checklist

Stap	Klaar?
Inventariseer alle PHP-servers, containers en hostingaccounts
Update PHP naar 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 of gepatcht vendor pakket
Herbouw en herdistribueer containerafbeeldingen
Herstart alle PHP-FPM pools, Apache en LiteSpeed
Controleer de draaiende versie op elke site
Schakel `session.upload_progress` uit als het niet nodig is
Beperk of isoleer systemen die niet gepatcht kunnen worden
Controleer logs, bestanden, cron en accounts op compromittering
Plan upgrade van PHP 8.2 en ouder

Lessen voor de toekomst

PHP2Shell herinnert ons eraan dat applicatie-updates niet genoeg zijn. De runtime (PHP, webserver, OS-bibliotheken) heeft dezelfde aandacht nodig:

Automatiseer beveiligingsupdates voor PHP-pakketten, met monitoring die je waarschuwt wanneer een herstart nodig is
Blijf op ondersteunde PHP-versies
Ken uw inventaris: welke sites draaien welke PHP-versie waar
Houd getest, externe back-ups
Geef de voorkeur aan PHP-FPM boven mod_php voor nieuwe installaties, met aparte pools en gebruikers per site

Mijn Linux server hardening checklist legt uit hoe je deze routine kunt maken.

Veelgestelde vragen

Is WordPress (of Magento, Laravel, Drupal) kwetsbaar voor PHP2Shell?

De kwetsbaarheden zitten in PHP zelf, niet in de applicaties. Elke van deze applicaties die draait op een kwetsbare PHP-versie is blootgesteld via PHP. Het bijwerken van WordPress of plugins lost het niet op. Je moet PHP bijwerken.

Ik heb PHP bijgewerkt. Waarom toont mijn site nog steeds de oude versie?

Het PHP-FPM- of Apache-proces is niet opnieuw opgestart, of de site gebruikt een andere PHP-versie of pool dan degene die je hebt bijgewerkt. Herstart alle PHP-services en controleer per site.

Is het wijzigen van php.ini genoeg?

Nee. Het PHP-project stelt dat configuratiewijzigingen de blootstelling aan specifieke aanvalspaden verminderen, maar maken een installatie niet veilig. Bijwerken.

Mijn server draait PHP 7.4 of 8.1. Wat nu?

Die versies ontvangen geen officiële PHP-releases meer. Controleer of uw OS-leverancier of een LTS-aanbieder een teruggepatchte oplossing biedt. Het PHP-project heeft minimale bronbackports gepubliceerd voor 7.4, 8.0 en 8.1. De echte oplossing is om zo snel mogelijk te upgraden naar een ondersteunde versie (8.4 of 8.5).

Beschermt een WAF mij?

Een webapplicatie-firewall kan enkele bekende aanvalspatronen blokkeren en verzoeklimieten afdwingen, wat het risico vermindert. Het is geen vervanging voor patching.

Is mijn gedeelde hosting veilig?

Alleen als uw host gepatchte PHP-builds heeft uitgerold en zijn PHP-werkers heeft herstart. Vraag het hen rechtstreeks en krijg een bevestiging schriftelijk.

Heeft u hulp nodig bij het patchen van uw servers?

Ik help bedrijven met het inventariseren, patchen en verharding van PHP-servers die WordPress, WooCommerce, Magento en op maat gemaakte applicaties draaien, inclusief containerherstellingen en compromitteringscontroles. Bekijk mijn servers en back-upservice of vraag urgente hulp aan.