PHP2Shell: WTF is er gebeurd? (CVE-2026-109618 en CVE-2026-109619)

Het reactievenster was kort omdat het embargo in het openbaar uiteenviel, en dit is het deel dat de reactie "WTF is er gebeurd" opriep.

Het onderzoek was wekenlang stil geweest. Calif meldde PHP in augustus een eerste fout, en Wiz Research meldde PHP de kwetsbaarheden op 24 augustus, waarbij het securityteam van OpenAI in de gecoördineerde inspanning wordt genoemd. De fix was moeilijk te bouwen, en de gecoördineerde openbaarmaking was gepland voor 22 oktober.

Toen brak het embargo in fasen. Op 20 oktober begonnen de twee CVE-identificatoren op forums en sociale media te circuleren met onjuiste ernst en timing eraan verbonden; op dat moment waren de identificatoren openbaar, niet de technische details. Kort daarna publiceerde Calif per ongeluk een video die een werkende proof-of-concept bevatte, wat technisch materiaal wel blootlegde en bijdroeg aan snellere onafhankelijke exploitontwikkeling. Ook mitigatieadvies dat de PHP Foundation privé had gedeeld met organisaties voor kritieke infrastructuur kan zijn uitgelekt. Nu het embargo zichtbaar uiteenviel, haalde PHP zijn release een dag naar voren, naar 21 oktober.

De derde blootstelling werd een publiek geschil, en het is de moeite waard beide posities helder te stellen. De PHP Foundation karakteriseerde Chainguards publicatie van gepatchte container-images, om 07:41 UTC op 21 oktober, ongeveer zes uur vóór de gecoördineerde release, als het breken van het embargo: "Elke aanvaller kon nu de fix in binaire vorm bestuderen terwijl elke andere PHP-gebruiker nog op de release wachtte", en voegde eraan toe dat het "wekenlang werk van vele partijen aan een gecoördineerde openbaarmaking negeerde". Chainguards CEO, Dan Lorenc, antwoordde dat het bedrijf niets had laten uitlekken, de tijdlijn niet betwistte, dezelfde kwetsbaarheden onafhankelijk had ontdekt met eigen AI-tooling, en had geholpen de patches te testen. De twee claims sluiten elkaar niet uit, en de PHP Foundation heeft het verslag van de onafhankelijke ontdekking publiekelijk niet beantwoord.

Het mechanisme achter de klacht van de Foundation is een terugkerend leveringsketenprobleem dat de moeite waard is te begrijpen. Wanneer een gepatcht binary vóór de advisory wordt uitgebracht, kan iedereen het vergelijken met de vorige build, de gewijzigde code lokaliseren en terugwerken naar de fout. Patch-diffing kan een fix veranderen in een kaart van de bug. Het publiceren van een gepatcht binary vóór een advisory bewijst op zichzelf niet dat de publicist de bron van het lek was of dat elke aanvaller dat pad gebruikte, maar het kan de drempel verlagen voor wie dat wel doet.

Exploitatie valt niet netjes samen met het patch-tijdstempel. Securityleveranciers meldden exploitatiepogingen voordat de patches landden, waarbij sommigen activiteit dateerden op 17 oktober, en Cloudflare observeerde aanvalsverkeer en zei dat sommige aanvallers payloads aanpasten om zijn WAF-regels te omzeilen. Op 21 oktober had Cloudflare om 03:02 UTC regels ingeschakeld, bracht PHP de fixes uit rond 14:00 UTC, en ging watchTowr binnen enkele minuten na de release over van het melden van geen waargenomen exploitatie naar actieve pogingen tegen beide CVE's. Dit zijn verschillende waarnemingen, niet noodzakelijk één campagne, en vroege samples, aangetoonde ketens, exploitatiepogingen en bevestigde compromittering zijn niet hetzelfde. Ten tijde van de eerste berichtgeving op 21 oktober was er geen bevestigde inbreuk gepubliceerd en stond geen van beide CVE's in CISA's catalogus van bekende uitgebuite kwetsbaarheden (Known Exploited Vulnerabilities), hoewel meerdere organisaties, waaronder BambooHR en enkele Nederlandse overheids- en onderwijssites, diensten uit voorzorg offline haalden. Behandel die status als tijdgebonden en controleer hem opnieuw voordat u handelt.

De praktische les is dat het tijdstempel van de patch-release niet het moment is waarop de dreiging begon. Publiek onderzoek en exploittooling verminderden het werk dat een aanvaller anders had gehad om de aangetoonde aanvallen te reproduceren aanzienlijk. Dat maakte niet elke deployment even exploiteerbaar, maar het verkortte het pad van openbaarmaking naar praktische pogingen, en het betekent dat elk systeem dat vooraf blootgesteld was onderzoek nodig heeft, niet alleen een patch.

Wat een ongepatchte server te wachten staat

Voor een ongepatchte, op het internet gerichte server volgen er twee soorten uitkomsten, en de eerste heeft geen code-uitvoering nodig. Het geheugenlekkagepad kan vrijgegeven workergeheugen in het antwoord teruggeven en zo geheimen blootleggen uit andere verzoeken die dezelfde worker afhandelde, zoals sessietokens en API-sleutels. Het laat mogelijk geen duidelijke fout op applicatieniveau achter, dus responders moeten webserver- en proxytelemetrie naast PHP-logs en procesactiviteit onderzoeken in plaats van een duidelijke logregel te verwachten.

De tweede uitkomst is volledige remote code execution, en van daaruit volgt de bekende keten: een webshell, diefstal van inloggegevens, laterale beweging, data-exfiltratie of het klaarzetten voor ransomware. Het probleem van de oude versies maakt dit op bepaalde plaatsen hardnekkig. End-of-life-branches zullen deze fix nooit ontvangen, en PHP dat in een appliance, een embedded apparaat of een leverancierproduct is gebundeld heeft mogelijk zonder de leverancier helemaal geen patch, wat inventarisatie en leverancierscoördinatie het eigenlijke werk maakt, geen bijzaak.

Detectie en threat hunting

Omdat de trigger het parsen van verzoeken is en het effect geheugencorruptie, groeperen de waarneembare signalen zich rond misvormde uploads en instabiele workers. Onderzoek voor een server die vóór het patchen blootgesteld kan zijn geweest:

• Ongebruikelijke multipart/form-data-verzoeken, vooral die kort gevolgd worden door memory-limit-fouten in de PHP-logs.

• Herhaalde HTTP 500-antwoorden, die de fatal errors begeleiden waarvan de eerste bug afhankelijk is.

• Onverwacht grote of misvormde PHPSESSID-waarden in serverantwoorden. Hier komt het geheugenlekkagepad aan de oppervlakte, het is dus een artefact van het uitgaande antwoord, geen te grote cookie die van de client binnenkomt.

• Onverklaarde herstarts van PHP-workers, die kunnen volgen op een mislukte of gedeeltelijke exploitatiepoging.

Geen van deze is op zichzelf sluitend. Afgemeten aan de normale baseline van de applicatie is een cluster van te grote multipart-verzoeken, memory-limit-fatals en worker-fluctuatie tegen een ongepatchte server een onderzoeksaanwijzing met hoge prioriteit. Een succesvolle geheugencorruptie-exploit produceert mogelijk niet dezelfde symptomen als een gewone fout, corroboreer dus over webserver-, proxy- en PHP-logs plus procestelemetrie heen in plaats van op één patroon te vertrouwen.

Reageren op PHP2Shell: volgorde van prioriteiten

Handel in een blootgestelde omgeving in deze volgorde:

1. Identificeren en patchen. Vind elke op het internet gerichte PHP-runtime, inclusief die gebundeld in containers, appliances en producten van derden, en pas de door de leverancier herstelde release toe. Het bijwerken van het applicatieframework herstelt de runtime niet.

2. Blootstelling verminderen tijdens het patchen. Als een onmiddellijke update onmogelijk is, beperk dan de publieke toegang of isoleer de getroffen dienst. Behandel WAF-regels en PHP-configuratiewijzigingen als tijdelijke risicovermindering, niet als volledige mitigaties.

3. Mogelijke compromittering onderzoeken. Bekijk web-, proxy- en PHP-logs, endpoint-telemetrie, onverwachte processen, gewijzigde bestanden en verdachte uitgaande verbindingen. Patchen stelt niet vast of een aanvaller vooraf toegang tot het systeem had.

4. Het resultaat verifiëren. Herstart de relevante diensten en workers, bevestig dat de draaiende runtime een herstelde build is, en controleer leverancier-advisories waar fixes zijn gebackport.

Tijdelijke mitigaties en hun grenzen

Het PHP-project is er duidelijk over dat er geen volledige mitigaties zijn en dat bijwerken de enige veilige keuze is. De onderstaande maatregelen verminderen de blootstelling aan specifieke paden; ze maken een ongepatchte runtime niet veilig. Herstart de getroffen PHP-workers en relevante serveerprocessen na het toepassen van configuratiewijzigingen, zoals uw deployment vereist. Verifieer de actuele aanbevelingen in het security-release-bericht van de PHP Foundation in plaats van op een samenvatting te vertrouwen.

Voor CVE-2026-109618 beveelt PHP aan memory_limit op -1 te zetten via configuratie die applicaties niet kunnen overschrijven, zoals de FPM-pool of de Apache-config, wat de bestuurbare memory-limit-trigger wegneemt. Dit is geen achteloze wijziging: het verwijdert PHP's geheugenplafond per verzoek, dus een enkel verzoek kan aanzienlijk systeemgeheugen verbruiken, en externe verzoeklimieten alleen garanderen niet dat het kwetsbare allocatiepad niet bereikt kan worden. Verzacht het denial-of-service-risico door post_max_size laag en upload_max_filesize daaronder te houden, verzoekgroottelimieten op de proxy af te dwingen, en een container- of cgroup-geheugengrens rond de worker te plaatsen die hem kan beëindigen. Vervang dit niet door RLIMIT_AS of RLIMIT_DATA, die de allocatiefouten die de bug bereiken opnieuw creëren.

Voor CVE-2026-109619 beveelt PHP aan session upload progress uit te schakelen om bevestigde sessiegerelateerde exploitpaden te blokkeren. Zet session.upload_progress.enabled op 0 op pool- of serverniveau zodat het vóór het parsen van het verzoek van kracht wordt, en herstart dan de workers; het instellen via ini_set() of een .user.ini komt te laat om te helpen. Zet op PHP 8.5 ook fatal_error_backtraces op 0 om het bevestigde fatal-backtrace-pad te blokkeren. Deze instellingen adresseren specifieke paden, niet elke mogelijke variant, en maken een ongepatchte installatie niet veilig.

Een opmerking voor na het patchen, volgens de berichtgeving over de fix: hij introduceert een hard geheugenlimiet dat een proces kan beëindigen zonder de PHP-shutdown-handlers uit te voeren. Als uw logica afhankelijk is van shutdown-functies of nette afhandeling van geheugenuitputting, bevestig dan het gepatchte gedrag aan de hand van de PHP-release-notes voordat u aanneemt dat het overeenkomt met het oude.

Wat dit betekent voor inventarisatie en reactie

PHP2Shell is operationeel een inventarisatieprobleem voordat het een patch-probleem is. Op 21 oktober was de eerste vraag voor de meeste teams niet hoe de bug werkt. Die luidde: waar draaien we PHP, welke versies, en welke producten, diensten en klanten zijn blootgesteld.

Een actuele, voldoende volledige software bill of materials helpt dit te beantwoorden door de producten, builds en images te identificeren die de getroffen PHP-runtime bevatten. Daar verstopt PHP zich graag: gebundeld in appliances en embedded webinterfaces, ingebakken in container-base-images, binnengehaald als afhankelijkheid van een groter product, plaatsen die een scan op manifestniveau graag over het hoofd ziet. Een SBOM is slechts zo goed als zijn dekking. Hij wijst u op de assets die het controleren waard zijn; hij bevestigt op zichzelf niet de exacte versie die in productie draait en bewijst niet dat een bepaalde host exploiteerbaar is. Wanneer SBOM's actueel zijn en de relevante runtime vastleggen, veranderen ze een dagenlange telling in een veel kortere lijst van te verifiëren assets.

Interlynk is voor dit patroon gebouwd. lynkctl genereert build-bewuste SBOM's die de runtimes en componenten vastleggen die in firmware, appliances en images zijn ingebed, ver voorbij de top-level-afhankelijkheden. Het Interlynk-platform neemt die SBOM's op, beoordeelt componenten op risico aan de hand van kwetsbaarheidsdata zodat een getroffen PHP-versie automatisch naar boven komt, beheert VEX-uitspraken voor de producten die u hebt beoordeeld, en stelt stakeholders op de hoogte wanneer een nieuwe openbaarmaking de blootstelling verandert van iets dat al is uitgeleverd. Wanneer de volgende CVE op runtimeniveau landt, staat de inventaris al klaar.

De kern van de zaak

PHP2Shell laat zien hoe een geheugenfout in een breed ingezette runtime de beveiliging kan ondermijnen van applicaties die niets fout deden. Twee geheugenfouten die ruim een decennium in PHP aanwezig waren, werden ontwikkeld tot niet-geauthenticeerde remote code execution, en een gecoördineerde openbaarmaking die uiteenviel liet verdedigers vrijwel geen respijt.

Patch de runtime naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35, herstart uw workers, verifieer op CVE-ID, en onderzoek alles wat vóór de patch blootgesteld was. Maak daarna de inventarisatievraag vooraf beantwoordbaar, want wanneer een kwetsbaarheid leeft in een runtime die over duizenden producten wordt gedeeld, is weten waar die runtime is ingezet onderdeel van de incident response, niet van het opruimen achteraf.