PHP heeft noodupdates uitgebracht die twee kritieke fouten in de taal zelf verhelpen, waardoor een aanvaller zonder account code op een webserver kan uitvoeren. De fixes zitten in PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35, en het PHP-team zegt dat alleen updaten een server volledig beschermt.
De kwetsbaarheden, samen aangeduid als PHP2Shell, zitten in de PHP-runtime, niet in een applicatie, dus een website is kwetsbaar zelfs wanneer de eigen code veilig is. Het risico is het grootst op servers die Apache’s mod_php gebruiken, waarbij een werkende exploit de aanval activeert voordat enige applicatiecode wordt uitgevoerd.
Beide fouten zijn beoordeeld met een 9,2 op de CVSS v4.0-schaal en hebben de identifiers CVE-2026-109618 en CVE-2026-109619. PHP publiceerde ze rond de geplande uitgiftetijd van 14:00 UTC op 21 oktober, een dag nadat details gelekt waren vóór de geplande openbaarmaking op 22 oktober.
Onderzoekers van Wiz, Calif en OpenAI vonden en rapporteerden de fouten, die bijna elke PHP-versie terug tot PHP 5.4 beïnvloeden.
Wie is getroffen
Elke PHP-installatie die webverzoeken bedient loopt risico, inclusief PHP-FPM, Apache mod_php, php-cgi, FrankenPHP en LiteSpeed, volgens het PHP-beveiligingsadvies.
Aangezien de fouten in de engine zitten in plaats van in de code van een site, kan zelfs een eenvoudige “Hello World”-pagina op een kwetsbare PHP-versie worden aangevallen.
Het advies wijst mod_php aan als het grootste risico, met een bewezen exploit waarbij één ongeauthenticeerd verzoek de aanval activeert voordat enige applicatiecode draait. PHP-FPM gedraagt zich anders omdat het de worker afsluit wanneer een request vroegtijdig faalt tijdens de setup.
Voor één van de twee fouten ondersteunt PHP’s eigen analyse dat FPM kwetsbaar kan zijn, maar zegt dat er geen compleet FPM-exploit is aangetoond; de tweede fout is getoond als code-executie op zowel mod_php als PHP-FPM, hoewel het FPM-pad daar afhankelijk is van een bewerking binnen de draaiende applicatie.
Een aanvaller kan ook geheugen lezen uit het PHP-workerproces, dat wachtwoorden, authenticatietokens, API-sleutels en certificaten van andere verzoeken kan bevatten, zonder eerst code-uitvoering te verkrijgen.
De onderzoekers demonstreerden het uitlezen van live-workergeheugen tegen applicaties die zij niet beheerden, waardoor het onafhankelijk is van de applicatie die bovenop PHP draait.
Wat te installeren
Update de PHP-runtime die webverzoeken bedient en herstart daarna Apache, PHP-FPM en alle langlopende PHP-workers. Het updaten van een applicatie zoals WordPress of Laravel werkt de onderliggende PHP-runtime niet bij; die komt uit het serverpakket, de host of de containerimage.
| PHP-branch | Kwetsbaar | Eerste gepatchte versie |
|---|---|---|
| 8.5 | lager dan 8.5.12 | 8.5.12 |
| 8.4 | lager dan 8.4.27 | 8.4.27 |
| 8.3 | lager dan 8.3.36 | 8.3.36 |
| 8.2 | lager dan 8.2.35 | 8.2.35 |
PHP 8.1 en ouder krijgen geen updates meer van het PHP-project, en PHP 8.2 bereikt end-of-life op 31 december 2026. Voor de oudere branches heeft het PHP-securityteam source-backports gepubliceerd voor PHP 7.4, 8.0 en 8.1 om mensen te helpen die vanaf bron bouwen of op een vendor wachten.
Linux-distributies en leveranciers met lange-termijnondersteuning ontvingen de patches vooraf, dus een distributiepakket kan de fix bevatten onder een ogenschijnlijk oude versienaam; controleer de pakketwijzigingslog voor de CVE, zoals Debian adviseert, en niet alleen de versiestring.
Als u nog niet kunt updaten
Alleen updaten is een volledige oplossing. De onderstaande maatregelen verminderen de blootstelling aan specifieke aanvalspaden en maken een server volgens het advies niet veilig.
Voor CVE-2026-109618: zet memory_limit=-1 zodat applicaties dit niet kunnen overschrijven, houd post_max_size laag en handhaaf verzoekgroottelimieten op de webserver of proxy. Gebruik niet RLIMIT_AS of RLIMIT_DATA als vervanging, omdat PHP waarschuwt dat deze hetzelfde kwetsbare pad kunnen activeren.
Voor CVE-2026-109619: zet session.upload_progress.enabled=0 en herstart iedere worker, en zet op PHP 8.5 ook fatal_error_backtraces=0. Het uitschakelen van session upload progress blokkeert de bevestigde session-paden maar niet andere varianten, en geen enkele configuratiewijziging verlicht deze fout volledig zonder te updaten.
Die instelling is de workaround die voorafgaand aan de patch circuleerde, en de release bevestigt dat het nooit een volledige fix was. Session upload progress staat standaard aan en kan session-handling bereiken voordat PHP klaar is met het opzetten van een request, wat verklaart waarom het deel uitmaakt van één bevestigd aanvalspad voor CVE-2026-109619 en waarom het uitschakelen ervan niets doet voor CVE-2026-109618.
“Het enige wat ik kan zeggen is dat de enige mitigatie het patchen/upgraden van PHP is. Ik weet helaas te veel,” schreef PHP-coreontwikkelaar Gina Peter Banyard vóór de release, als antwoord op iemand die suggereerde dat die instelling mogelijk voldoende zou zijn.
Na het updaten, controleer uw geheugensinstellingen. De fix voegt een nieuwe harde geheugengrens toe, en het bereiken daarvan beëindigt het proces en voorkomt dat shutdown-handlers draaien, dus controleer memory_limit en post_max_size ten opzichte van wat uw applicatie nodig heeft.
Als u al gepatcht heeft maar een eerdere inbraak vermoedt, suggereren de onderzoekers te letten op ongebruikelijke multipart-verzoeken gevolgd door geheugenlimietfouten of herhaalde HTTP 500-responses, vreemd grote PHPSESSID-responscookies en onverklaarde herstarts van PHP-workers.
Wordt er op dit moment aangevallen
Voor de patch werd geleverd, zei Cloudflare dat het vroege pogingen zag om de fouten te misbruiken. “We zien vroege aanvallen ontstaan en werken mitigaties bij naarmate nieuwe vectoren opduiken,” zei Cloudflare-CTO Dane Knecht, noemde de firewallregels die Cloudflare heeft ingezet een tijdelijke maatregel en spoorde beheerders aan te patchen.
Geen bron heeft een succesvolle inbraak bevestigd. watchTowr, dat CVE-2026-109618 reproduceerde, meldde geen uitbuiting in het wild om 11:26 UTC op 21 oktober, en geen van beide fouten stond op dat moment in CISA’s Known Exploited Vulnerabilities-catalogus.
Sommige organisaties haalden uit voorzorg diensten offline zonder dat er sprake was van een bewezen inbraak. BambooHR haalde zijn dienst offline in de Verenigde Staten, Canada en Ierland, waarschuwde dat loonadministratie verstoord zou worden en zei nog geen hersteltermijn te hebben.
In Nederland gingen MijnOverheid, DigiD, de website van de Tweede Kamer, het Nationaal Cyber Security Centrum en verschillende onderwijssystemen offline, meldde de omroep NOS; het centrum zei geen misbruik van de fout te hebben waargenomen maar riep iedereen op te patchen.
Hoe het naar buiten kwam
Een lek versnelde de publicatie. Op 20 oktober meldde The Hacker News dat een bericht op Hacker News zei dat twee PHP-remote-code-execution-fouten, met de twee CVE-identifiers, op 22 oktober openbaar zouden worden gemaakt, op grond van maximaal één betrouwbare tip.
PHP postte die avond een vooraankondiging en verschoof de release naar 21 oktober. De bewering van het lek dat de CVSS-score 10,0 zou zijn, was niet die van PHP; PHP beoordeelt beide fouten als 9,2.
De fouten werden gevonden door Wiz Research, Calif en OpenAI’s Codex Security-team, die samenwerkten met het PHP-securityteam en Google’s Gemini-team aan de fix. De onderliggende code zat al meer dan tien jaar in PHP.
De onderzoekers zeggen dat AI-modellen hielpen om deze lang bestaande fouten om te zetten in werkende exploits, waardoor één onderzoeker in ongeveer een week kon doen wat anders naar verluidt maanden door een team zou hebben gekost.
Calif, dat de oorsprong van de bug terugvoerde tot PHP-onderzoek uit 2004, zegt dat kennis van de geschiedenis van het doel nog steeds belangrijk was, en dat huidige modellen niet betrouwbaar vanuit obscure, twintig jaar oude primitieve constructies zelfstandig starten.
Update: watchTowr rapporteert exploitatiepogingen, nog geen bevestigde inbraak
watchTowr, dat eerder op de dag aangaf niets te zien, zei in een nieuw advies om 14:19 UTC op 21 oktober dat het “actieve exploitatiepogingen” observeert van zowel CVE-2026-109618 als CVE-2026-109619. Cloudflare zei aanvalverkeer tegen zijn klanten te hebben gezien en zag aanvallers hun payloads aanpassen om zijn firewallregels te omzeilen, die het vanaf 03:02 UTC vóór de patch standaard had ingeschakeld. Geen enkele bron heeft tot dit update-moment een bevestigde inbraak van een specifieke server gemeld.
De PHP Foundation zei dat de gecoördineerde disclosure uit elkaar viel vóór de release. Rond 20:00 UTC op 20 oktober plaatste het onderzoeksbedrijf Calif per ongeluk een video van zijn werkende proof of concept, en om 07:41 UTC op 21 oktober, ongeveer zes uur voordat de fix werd geleverd, publiceerde leverancier Chainguard gebouwde images met de patch, waardoor iedereen de fix kon bestuderen terwijl andere gebruikers wachtten om te updaten.
Update: PHP Foundation zegt dat een audit uit 2024 de eerste tekenen van de fout vond
In hetzelfde bericht zei de PHP Foundation dat een core-ontwikkelaar de eerste tekenen van de out-of-memory-fout achter CVE-2026-109618 vond tijdens PHP’s externe audit in 2024, maar dat er toen alleen een theoretische aanval werd vermoed en geen concreet pad naar code-executie werd gevonden.
Wederzijdse fixes liepen het risico compatibiliteit te breken, denial-of-service-paden te openen of wijzigingen af te dwingen bij derdepartij-extensies, en een klein team worstelde om overeenstemming te bereiken, waardoor het werk aan een fix maanden stagneerde. De Foundation noemde de vertraging “een structurele fout” in haar besluitvormingsproces en haar middelen.
De rapporten uit 2026 van Calif, OpenAI en Wiz, die AI-tools gebruikten, stelden het werkende exploit vast dat de volledige impact van de fout duidelijk maakte en plaatste de fix bovenaan de prioriteitenlijst. De Foundation zei dat zij sindsdien haar manier van beveiligingsbeslissingen nemen heeft aangepast en personeel en tooling heeft toegevoegd om soortgelijke problemen eerder te detecteren.
(Het verhaal is bijgewerkt na publicatie op 21 oktober 2026 om latere rapporten over exploitatiepogingen en het relaas van de PHP Foundation over de geschiedenis van de fout toe te voegen.)
