Kritieke kwetsbaarheden in PHP (CVE-2026-109618 en CVE-2026-109619): wat er is gebeurd en wat u moet doen

Op 21 oktober 2026 heeft het PHP-project fixes uitgebracht voor twee kritieke kwetsbaarheden, en CERT-EU publiceerde dezelfde dag waarschuwing 2026-018. Beide kwetsbaarheden zijn beoordeeld met 9,2 en beide worden beschreven als code-uitvoering op afstand zonder authenticatie. Als u een WordPress-site, een webwinkel of een andere PHP-toepassing beheert, geldt dit voor u, en de oplossing is een update, geen instelling. Dit artikel legt uit wat er bekend is, hoe de aanval binnenkomt en wat u moet doen. Stand van zaken: 22 oktober 2026, op basis van versie 1.1 van de CERT-EU-waarschuwing.

Wat er is gebeurd

PHP kondigde op 20 oktober een beveiligingsrelease aan en publiceerde de fixes op 21 oktober om 13:30 UTC. CERT-EU gaf zijn waarschuwing de titel “Critical Vulnerabilities in PHP” en noemt twee CVE’s: CVE-2026-109618 en CVE-2026-109619, elk met een score van 9,2. CERT-EU schrijft er ook bij dat de technische details inmiddels openbaar worden besproken en dat de eerste voorbeeldcode die de aanval aantoont (proof of concept) in omloop is. De waarschuwing bevestigt geen aanvallen in het wild, maar stelt dat het hierdoor waarschijnlijker wordt dat aanvallers de kwetsbaarheden al uitbuiten. Behandel dit als dringend.

Wie getroffen is

Getroffen is elke PHP-versie onder de verholpen versie in een ondersteunde tak, en elke tak die het einde van zijn levensduur heeft bereikt.

CERT-EU noemt PHP-FPM, Apache met mod_php, php-cgi, FrankenPHP en LiteSpeed. Volgens het PHP-team brengt mod_php het grootste risico met zich mee. Ook producten waarin PHP is ingebouwd, kunnen getroffen zijn; CERT-EU verwijst daarvoor naar een lijst van het Nederlandse NCSC aan het eind van dit artikel. Elke installatie die webverzoeken afhandelt, telt mee, met of zonder uploadformulier.

Hoe een aanvaller bij de eerste kwetsbaarheid komt

Niemand hoeft in te loggen. Volgens CERT-EU toont een gedemonstreerde aanval aan dat één enkel verzoek zonder authenticatie volstaat om de aanval te starten, voordat er enige toepassingscode draait. Dat is het punt dat de meesten missen: het maakt niet uit of uw WordPress actueel is, of uw plug-ins gepatcht zijn of dat uw contactformulier beschermd is. Het verzoek bereikt eerst de PHP-engine.

De eerste kwetsbaarheid, CVE-2026-109618, werkt zo:

1. Een verzoek komt aan op een adres dat PHP bedient. Geen login, geen account.
2. PHP begint de inhoud van het verzoek te lezen. CERT-EU noemt als voorbeeld het verwerken van formuliergebaseerde bestandsuploads.
3. PHP dwingt zijn memory_limit af met longjmp(). Wordt de grens overschreden, dan springt PHP uit waar het mee bezig was en beëindigt het verzoek.
4. Gebeurt dat midden in het opbouwen van interne verzoekgegevens, dan zijn die gegevens maar half opgebouwd.
5. De opruiming die daarna volgt, behandelt de ongeldige gegevens als geldig en geeft geheugen vrij dat nooit is geïnitialiseerd. Dat geheugen kan nog gegevens van eerdere toewijzingen bevatten die de aanvaller in handen had.
6. Vanaf dat punt beschrijft de waarschuwing code-uitvoering op de server.

Hoe een aanvaller de laatste stap stuurt, beschrijven we bewust niet. Het volstaat te weten dat het toegangspunt niet uw toepassing is, en daarom kan niets binnen uw toepassing de aanval tegenhouden.

De tweede kwetsbaarheid: een toestand die zijn geheugen overleeft

CVE-2026-109619 is een ander mechanisme met hetzelfde resultaat. PHP houdt voor elk verzoek een interne toestand bij. Na bepaalde fouten, zoals een fatale fout, kan die toestand blijven bestaan terwijl het geheugen eronder al is vrijgegeven. Het volgende verzoek dat hetzelfde werkproces afhandelt, kan die verouderde toestand dan gebruiken voordat hij op de normale manier is teruggezet. De aanvaller heeft twee verzoeken nodig die op hetzelfde werkproces terechtkomen; CERT-EU beoordeelt het resultaat net als bij de eerste kwetsbaarheid: code-uitvoering op afstand.

Wat u vandaag moet doen

1. Zoek uit welke PHP-versie uw site werkelijk bedient. php -v op de opdrachtregel toont de versie van de opdrachtregel, die kan afwijken van die van uw webserver. Controleer php-fpm -v, uw hostingpaneel of een pagina die phpinfo() aanroept. Bij gedeelde hosting vraagt u het uw provider.
2. Werk bij naar een verholpen versie: 8.5.12, 8.4.27, 8.3.36 of 8.2.35. Distributies nemen fixes vaak terug over zonder het versienummer te wijzigen; zoek daarom de CVE-nummers in de beveiligingsmelding van uw leverancier. Bouw in containers opnieuw vanaf een bijgewerkte basisimage. Het PHP-team merkt op dat rpms.remirepo.net op de dag van publicatie nog geen updates had, en adviseert pakketten van de distributie of een build vanuit de broncode.
3. Herstart elk PHP-werkproces. Een update op schijf verandert niets aan processen die al draaien. Herstart PHP-FPM of de webserver en controleer daarna opnieuw de draaiende versie.
4. Als u vandaag niet kunt bijwerken, isoleer dan de server van openbare netwerken totdat de fix is doorgevoerd en gecontroleerd. CERT-EU is duidelijk: alleen een update verhelpt deze kwetsbaarheden volledig.
5. Als u PHP 8.1 of ouder gebruikt, vraag dan uw leverancier om de terugportering of stap over op een ondersteunde tak. Deze versies krijgen geen reguliere updates meer.

Tijdelijke maatregelen die het risico verkleinen maar niets verhelpen

CERT-EU noemt maatregelen die een aanval bemoeilijken. De waarschuwing stelt uitdrukkelijk dat ze een installatie niet veilig maken. Gebruik ze terwijl u de update voorbereidt, niet in plaats ervan.

• Tegen CVE-2026-109618: stel memory_limit=-1 zo in dat toepassingen het niet kunnen overschrijven, bijvoorbeeld met php_admin_value in de FPM-pool, en controleer dat geen enkele pool-, map- of toepassingsinstelling opnieuw een eindige grens zet. Stel een lage post_max_size in (8M zonder uploads, 32M met) en houd upload_max_filesize daaronder. Beperk de grootte van verzoeken, het aantal velden, multipart-delen, het aantal headers en de nestingdiepte bij de webserver of proxy. Gebruik een geheugenlimiet van de container of cgroup als beschikbaarheidsgrens, maar niet RLIMIT_AS of RLIMIT_DATA, die de kwetsbare toewijzingsfout kunnen veroorzaken.
• Tegen CVE-2026-109619: stel session.upload_progress.enabled=0 in in php.ini, in de FPM-pool of in een serverconfiguratie die geldt voordat het verzoek wordt verwerkt (niet met ini_set() of .user.ini), en herstart alle werkprocessen. Stel bij PHP 8.5 bovendien fatal_error_backtraces=0 in. Verwijder ongeldige of verouderde instellingen per verzoek die meldingen tonen vóór de initialisatie, en verhelp fatale fouten en time-outs die een aanvaller kan bereiken.

Wat SilentShield hier wel en niet kan

Dit is geen botprobleem, en dat zeggen we liever dan dat we een productpagina iets anders laten suggereren. De aanval treft de PHP-engine voordat iets van ons, een CAPTCHA, een plug-in of een firewallregel binnen uw toepassing het verzoek ziet. Een botbescherming op een formulier houdt hem niet tegen, en niemand mag u vertellen dat dat wel zo is. De enige volledige oplossing is de PHP-update.

De SilentShield-API en het dashboard zijn niet in PHP geschreven. De WordPress-plug-in en de PHP-SDK draaien in uw eigen PHP, dus daarvoor moet de update op uw server plaatsvinden. Na de update is de gebruikelijke bescherming tegen bots en formulierspam net zo nuttig als voorheen; ze was alleen nooit het antwoord op dit probleem.

Bronnen

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• PHP-aankondiging van 20 oktober 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: producten waarin PHP is ingebouwd