CVE-2026-109619: uitvoering van code op afstand in PHP door verouderde globale toestand

Wat er misgaat, op het niveau van de leveranciersinformatie

Volgens de PHP Foundation kan een fatale fout op de verkeerde plek interne toestand achterlaten die naar geheugen van een vorig verzoek wijst. Een later verzoek op dezelfde worker kan dat vrijgegeven geheugen dan gebruiken. De Foundation zegt dat de use-after-free en een crash van de worker zijn bevestigd, en dat de melder uitvoering van code op afstand heeft gedemonstreerd tegen een echte applicatie op Apache met mod_php. De beschrijving van het Britse NCSC komt overeen met de zin van php.net.

Het advies van de University of Toronto noemt de standaard ingeschakelde session upload progress als een bevestigd pad. Volgens de tijdelijke PHP-aanbeveling blokkeert session.upload_progress.enabled=0 de bevestigde sessiepaden, maar niet andere varianten. Uitschakelen is een mitigatie, geen oplossing. Hoe een verzoek het tijdvenster van de fatale fout bereikt, beschrijven wij niet.

mod_php en PHP-FPM

Expel zegt met verwijzing naar PHP dat PHP deze CVE tegen PHP-FPM heeft gedemonstreerd wanneer de applicatiecode zelf in een fatale fout kan worden gedreven. De FPM-blootstelling hangt af van applicatie en configuratie; PHP beschouwt FPM-installaties toch als risicovol. mod_php blijft de configuratie die het PHP-project als hoogste risico aanmerkt. Het Canadian Cyber Centre herhaalt dat: met een gedemonstreerde exploit op mod_php kan een verzoek zonder authenticatie het lek vóór de applicatiecode activeren.

Oplossing

Er is geen aparte patch. Installeer de releases van 21 oktober en herstart elke worker. Voor PHP 8.5 noemt het project daarnaast fatal_error_backtraces=0 als tijdelijke maatregel, die alleen het bevestigde pad via fatal-backtraces blokkeert. Diagnostiek verbergen met error_reporting, display_errors of de @-operator helpt volgens php.net niet. Google Cloud noemt voor het paar 5.4 tot en met 8.5.11 als kwetsbaar; hoe dat aansluit bij de daadwerkelijk gepatchte takken, staat op de versiepagina.

Waarom het lek twee verzoeken op dezelfde worker nodig heeft

PHP’s volledige advisory beschrijft het lek als een paar. Eerst laat een bewerking een pointer naar het geheugen van één verzoek achter in een worker-brede globale toestand (fout-, sessie-, object- of extensietoestand) en wordt onderbroken voordat die gewist is, bijvoorbeeld door een fatale fout, een mislukte require, een time-out of geheugentekort. Daarna geeft de worker dat geheugen vrij, neemt het volgende verzoek aan, en iets dat vóór de normale start draait gebruikt de oude pointer. Beide helften moeten op dezelfde worker landen; meer workers en recycling vertragen een aanval, maar voorkomen hem niet.

Waar vroege instellingen vandaan komen, per SAPI

Een bevestigde trigger is een waarschuwing of deprecation terwijl PHP vóór de start instellingen per verzoek toepast, ook als de melding nooit getoond of gelogd wordt. Fouten onderdrukken helpt dus niet. Of dat pad bestaat, hangt af van hoe instellingen PHP bereiken:

• Apache mod_php: .htaccess en php_value / php_flag / php_admin_* worden vroeg toegepast; een foute of verouderde directive daar telt. De gewone php.ini wordt eenmaal bij de start gelezen en hoort er niet bij.
• PHP-FPM: alleen zo blootgesteld als nginx, mod_proxy_fcgi of een andere frontend PHP_VALUE of PHP_ADMIN_VALUE doorgeeft die een waarschuwing oplevert. Pool-instellingen en .user.ini niet, omdat die bij de workerstart of na de start gelden.
• LiteSpeed LSAPI: vroege omgevingsinstellingen maken het een voorwaardelijke kandidaat. FrankenPHP: geen vergelijkbaar vroeg pad in de standaardopzet, wat volgens PHP niet betekent dat het immuun is.

Extra stappen uit de advisory als je nog niet kunt patchen

• Verwijder verouderde of ongeldige directives uit alles wat per verzoek geldt, en geef de voorkeur aan php.ini, pool- of serverconfiguratie.
• Los fatale fouten en time-outs op die bezoekers kunnen veroorzaken, ook in upload-, import-, foutpagina-, destructor-, serialisatie- en plug-incode.
• Laat de doorvoer het toe, dan zorgt pm.max_requests=1 dat elke FPM-worker één verzoek afhandelt. PHP noemt dit optioneel; het is duur.
• Zet session.upload_progress.enabled uit waar je het niet gebruikt, ook na het patchen: PHP noemt de functie weinig gebruikt en weinig getest.
• Log voor een afgebakende audit alles (log_errors=On, een werkende error_log, error_reporting=E_ALL) en zoek naar waarschuwingen die zich herhalen vóór scripts starten, fouten tijdens het opruimen, fatale fouten en time-outs. Een schoon log bewijst geen veiligheid.