Corrigerende versies van PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 zijn gepubliceerd, evenals patches voor de al niet meer ondersteunde takken PHP 7.4, PHP 8.0 en PHP 8.1 (kwetsbare versies van 5.4 tot 7.3 blijven zonder patches), waarin twee kritieke kwetsbaarheden zijn verholpen:
- CVE-2026-109618 — remote code execution, veroorzaakt doordat bij het uitputten van het beschikbare geheugen van het proces de geheugenuitputting handler via het aanroepen van de longjmp() functie de PHP-interpreter kan onderbreken in een staat waarin slechts een deel van de interne structuren, die verband houden met het verwerken van de aanvraag, zijn geïnitialiseerd. Vervolgens probeert de functie die de verwerking van de aanvraag beëindigt deze structuren te benaderen alsof ze al zijn geïnitialiseerd, terwijl er geen geheugen voor hen is toegewezen.
De belangrijkste aanvalsvector is manipulatie van multipart-aanvragen om voorwaarden te creëren voor het uitputten van het beschikbare geheugen van het proces. Om de limiet post_max_size te omzeilen, kan de Content-Length header weggelaten worden en kan een enorm aantal HTTP-headers worden verzonden. Gerichte aanvallen op specifieke bewerkingen in php-toepassingen die overmatig geheugen verbruiken, zijn ook mogelijk. Het bestaan van een exploit is bevestigd voor mod_php, omdat het de shutdown() functie aanroept, zelfs bij een fout. PHP-FPM beëindigt het kindproces bij een fout, wat het uitvoeren van een aanval bemoeilijkt, maar theoretisch niet uitsluit.
- CVE-2026-109619 — remote code execution, veroorzaakt door toegang tot geheugen na het vrijgeven ervan door onjuiste opruiming van de globale status die aan een specifieke aanvraag is gekoppeld. In het geval van onderbreking van de aanvraag door een fatale fout, timeout of geheugenuitputting kan de globale status onthouden blijven en kunnen aanwijzers actief blijven, ondanks het vrijkomen van het geheugen waarnaar ze verwijzen. Bij het verwerken van de volgende aanvraag in hetzelfde proces kan er een toegang plaatsvinden via de overblijvende aanwijzer naar de oude globale status.
Voor gebruik kan het creëren van omstandigheden voor het uitputten van beschikbare geheugen bij het verwerken van multipart-verzoeken in de code voor het aangeven van de uploadvoortgang (session.upload_progress) worden toegepast. Als belangrijkste en bevestigde aanvalsvector wordt de fatal_error_backtraces-handler in PHP 8.5 genoemd, die de traceerstatus niet reset bij beëindiging. In het eerste geval is een aanval mogelijk op mod_php en PHP-FPM, en in het tweede geval alleen op mod_php. Er wordt ook een onbevestigd potentieel voor een aanval genoemd in configuraties waarin instellingen zijn verwerkt die leiden tot het weergeven van waarschuwingen in een vroeg stadium van de aanvraagverwerking (bijvoorbeeld waarschuwingen voor verouderde parameters).
Het is vastgesteld dat volledige blokkering van kwetsbaarheden alleen mogelijk is via het installeren van updates. De volgende maatregelen kunnen de kans op succesvolle aanvallen verkleinen, maar maken het systeem niet volledig veilig:
- Het instellen van de parameter "memory_limit=-1" in php.ini, wat het voor de aanvaller moeilijk maakt om de uitputting van geheugengrenzen te controleren.
- Het instellen van de parameter "post_max_size = 8M", als er geen behoefte is aan het uploaden van grote bestanden. De waarde van de parameter "upload_max_filesize" moet lager zijn dan die van "post_max_size".
- Het vaststellen van een limiet voor het toegestane geheugengebruik op systeemniveau, via cgroup memory.max of geheugenverbruikparameters van de container, maar niet via de systeemlimieten RLIMIT_AS en RLIMIT_DATA, die alleen de probleemaanroep longjmp() uitlokken.
- Als prestaties niet belangrijk zijn, kan het aantal verzoeken dat door één werkproces wordt verwerkt, worden beperkt via pm.max_requests=1 in PHP-FPM en MaxRequestsPerChild in Apache httpd.
- Instellen op het niveau van php.ini of configuratie de server (niet via ini_set() of FPM .user.ini, aangezien de parameter moet gelden voordat de aanvraagverwerking begint) van de parameter "session.upload_progress.enabled=0."
- Bij gebruik van de uitgave van PHP 8.5 dient de parameter "fatal_error_backtraces=0" te worden ingesteld.
- Verwijderen van gekoppelde verouderde of foutieve instellingen per afzonderlijk verzoek (zoals assert.* en onjuiste paden in open_basedir), die leiden tot het weergeven van diagnostische berichten vóór initiatie.
- Het elimineren van situaties in PHP-code die leiden tot time-outs en fatale fouten, bijvoorbeeld gerelateerd aan mislukkingen in callback-handlers en het verwerken van uploads.
- Om de eerste kwetsbaarheid in de code van oude versies van PHP te blokkeren, kan de aanroep van longjmp() in de handler voor het opraken van vrije geheugencapaciteit worden vervangen door _exit().
- Daarnaast kan de waarde van de parameter max_input_nesting_level in php.ini worden verlaagd en kunnen multipart-verzoeken worden geblokkeerd, zoals in de eerdere aankondiging is getoond.
De status van het verhelpen van kwetsbaarheden in distributies kan worden geëvalueerd op de volgende pagina's: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
Aanvulling 1: Kwetsbaarheden zijn ontdekt met behulp van AI-modellen GPT-5.6 en Gemini 4 Argon. OpenAI heeft de tool php2shell-checker gepubliceerd om de kwetsbaarheid van websites en lokale uitvoerbare bestanden te controleren, maar deze tool controleert alleen het versienummer van PHP dat door de HTTP-server of het commando "php -v" wordt geretourneerd, zonder een gedetailleerde analyse.
Aanvulling 2: De auteur van de prototype-exploit, die gebruikmaakt van de kwetsbaarheid veroorzaakt door double-free, heeft gemeld dat het probleem niet is opgelost in de uitgave PHP 8.5.12 en dat de exploit blijft werken. Eerder hadden vertegenwoordigers van PHP verklaard dat deze kwetsbaarheid niet gerelateerd is aan de aanstaande oplossingen en geen daadwerkelijk probleem vormt. De auteur van de exploit claimde echter dat dit een geheel andere kwetsbaarheid is.
Bron: opennet.ru
