CVE-2026-109618: uitvoering van code op afstand in PHP door out-of-memory-corruptie

Wat er misgaat, op het niveau van de leveranciersinformatie

Op oss-security schreef Jakub Zelenka dat PHP de verzoekverwerking bij out-of-memory-fouten afbreekt via longjmp(); een mislukte geheugentoewijzing kan de initialisatie onderbreken terwijl onvolledige verzoektoestand al bereikbaar is, en het afsluiten van het verzoek kan dan die ongeldige toestand benaderen en zo mogelijk uitvoering van code op afstand toestaan. De weergave van de PHP Foundation sluit daarbij aan: bereikte een verzoek memory_limit op het verkeerde moment, dan konden gedeeltelijk geïnitialiseerde gegevens achterblijven en later als geldig gelden.

Verder dan dit mechanisme publiceren wij niets. Hoe je de geheugenfout afdwingt, beschrijven wij niet.

Wat is gedemonstreerd

• oss-security: uitvoering van code op afstand zonder authenticatie is via HTTP gedemonstreerd tegen Apache mod_php, voordat applicatiecode draait. Broncodeanalyse wijst ook op kwetsbaarheid van FPM, maar een volledige FPM-exploit is niet gedemonstreerd.
• PHP Foundation: volledige uitvoering van code op afstand is gedemonstreerd op Apache mod_php met standaardinstellingen, voordat applicatiecode draait. Op PHP-FPM is RCE bevestigd via codepaden op applicatieniveau.
• Expel, met verwijzing naar PHP: de mod_php-demonstratie voor deze CVE werkte met de standaardlimieten van PHP voor invoer en geheugen.
• Het advies van de University of Toronto zegt dat aanvallers de toestand kunnen afdwingen met gemanipuleerde multipart-verzoeken binnen de ogenschijnlijke PHP-limieten. Wij werken die zin niet uit tot een handleiding.

Impact

Geslaagd misbruik betekent uitvoering van code op afstand zonder authenticatie met de rechten van het besturingssysteemaccount van de PHP-worker. Wiz en Cloudflare noemen daarnaast crashes en het lekken van procesgeheugen. De reikwijdte hangt af van build, extensies en serveropbouw; volgens de University of Toronto wisselt de betrouwbaarheid, en PHP heeft volledige RCE gevalideerd. Een betrouwbare uitspraak „werkt overal” staat niet in de bekeken bronnen – en er is geen reden om daarop te wachten met patchen.

Oplossing

Werk bij naar 8.2.35, 8.3.36, 8.4.27 of 8.5.12 of nieuwer en herstart de workers die verkeer afhandelen. Volgens oss-security is de update de enige volledige oplossing. Tijdelijke instellingen van PHP, waaronder memory_limit=-1 en een lage post_max_size, zijn onvolledig: ook zonder stuurbare geheugenlimiet kan een onderliggende toewijzingsfout het kwetsbare pad bereiken. Volgens Tanium is de NVD-vermelding op 21 oktober 2026 gepubliceerd en gemarkeerd als „Undergoing Analysis”. Gebruik het PHP-advies als operationele bron zolang de NVD achterloopt.

Blootstelling per servertype, volgens PHP’s volledige advisory

De GitHub-advisory legt uit waarom het risico per SAPI verschilt. Beslissend is of PHP de opruimfase aan het einde van een verzoek nog uitvoert als het starten van dat verzoek is mislukt.

Waarom uploadlimieten het geheugen niet begrenzen

Volgens de advisory kan een multipart-formulierverzoek PHP door zijn geheugen laten raken terwijl het ruim binnen de limieten lijkt te blijven. In grote lijnen: een body zonder bruikbare lengte kan de post_max_size-controle passeren; het aantal headers in één deel is onbegrensd en neemt in het geheugen meer ruimte in dan op de lijn; lege bestandsvelden tellen niet mee voor max_file_uploads, maar PHP bouwt er toch uploadarrays voor. Ook applicatiecode kan die toestand bereiken als gebruikersinvoer een grote allocatie stuurt. We blijven op het niveau dat PHP publiceerde en beschrijven niet hoe je zo’n verzoek maakt.

Wat de fix in PHP verandert

Bij geheugentekort springt PHP niet meer uit het lopende codepad. Op het volgende veilige punt in de engine volgt een ‘zachte’ out-of-memory-fout; loopt het gebruik op tot een tweede, hogere drempel, dan stopt het proces direct. memory_limit blijft werken en de opruimfase ziet geen half opgebouwde toestand meer.

Hardening die na het patchen nog helpt

Volgens PHP verkleinen deze stappen ook op gefixte builds het risico op harde afbrekingen en denial of service. Ze vervangen de update niet.

• Begrens de gedecodeerde verzoekgrootte op de webserver of proxy, los van post_max_size.
• Verlaag max_input_nesting_level en begrens max_input_vars, het aantal multipart-delen, headers per deel en uploads.
• Accepteert een applicatie of route nooit uploads of multipart-formulieren, weiger multipart-verzoeken dan aan de rand, vóór PHP. Veel framework-API’s die alleen JSON aannemen kunnen dat veilig.
• Geheugenlimieten van containers of cgroups (memory.max) vervangen memory_limit maar deels. Een hele container stoppen doodt ook de FPM-master en alle workers, tenzij elke worker een eigen groep heeft.
• Gebruik RLIMIT_AS of RLIMIT_DATA niet als geheugengrens: volgens PHP laten ze allocaties precies zo mislukken dat de fout geraakt wordt.