Details van kritieke kwetsbaarheden in PHP onthuld en correctieve updates gepubliceerd

Corrigerende versies van PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 zijn gepubliceerd, evenals patches voor al niet meer ondersteunde versies van 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 opgelost:

• CVE-2026-109618 — remote code execution, veroorzaakt doordat de geheugen tekort handler via het aanroepen van de longjmp() functie de PHP-interpreter kan onderbreken in een toestand waarin slechts een deel van de interne structuren die verband houden met het verwerken van de verzoeken zijn geïnitialiseerd, wanneer de beschikbare vrije geheugen voor het proces is uitgeput. De opvolgende verzoekverwerking functie probeert deze structuren aan te spreken als waren ze al geïnitialiseerd, terwijl er geen geheugen aan hen is toegewezen.

  De belangrijkste aanvalsvector is het manipuleren van multipart-verzoeken om condities te creëren voor het uitputten van het beschikbare geheugen van het proces. Om de limiet van post_max_size te omzeilen, kan de Content-Length header worden weggelaten en kan een enorme hoeveelheid HTTP-headers worden verzonden. Gerichte aanvallen op specifieke operaties in php-toepassingen die te veel geheugen verbruiken, kunnen ook worden uitgevoerd. De aanwezigheid van een exploit is bevestigd voor mod_php, aangezien het de shutdown() functie aanroept, zelfs bij een fout. PHP-FPM beëindigt de subprocess bij een fout, wat een aanval bemoeilijkt, maar theoretisch niet uitsluit.

• CVE-2026-109619 — remote code execution, veroorzaakt door toegang tot geheugen na vrijgave door onjuiste opruiming van de globale status gerelateerd aan een specifiek verzoek. In het geval van onderbreking van een verzoek door een fatale fout, timeout of geheugen tekort, kan de globale status niet worden gereset en blijven de pointers actief, ondanks de vrijgave van het geheugen waar ze naar verwijzen. Bij het verwerken van het volgende verzoek in hetzelfde proces kan er toegang plaatsvinden via de achtergebleven pointer naar de oude globale status.

  Voor de werking kan het creëren van voorwaarden voor het opraken van beschikbare geheugen worden gebruikt bij het verwerken van multipart-verzoeken in de code voor het aangeven van de voortgang van uploads (session.upload_progress). Hierbij wordt de handler fatal_error_backtraces in PHP 8.5 genoemd als de belangrijkste en bevestigde aanvalsvector, die de trace-status niet reset bij voltooiing. 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 onbevestigde mogelijkheid genoemd om een aanval uit te voeren in configuraties waarbij de instellingen leiden tot het weergeven van waarschuwingen in een vroeg stadium van het verwerken van het verzoek (bijvoorbeeld waarschuwingen over het gebruik van verouderde parameters).

Er wordt beweerd dat volledige blokkering van kwetsbaarheden alleen mogelijk is door het installeren van een update. De volgende maatregelen verlagen de kans op succesvolle aanvallen, maar maken het systeem niet volledig veilig:

• Het instellen van de parameter «memory_limit=-1» in php.ini, wat het moeilijk maakt voor de aanvaller om het opraken van geheugenlimieten te beheersen.
• 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 kleiner zijn dan de parameter «post_max_size».
• Het instellen van een limiet voor het toegestane geheugengebruik op systeemniveau, via cgroup memory.max of parameters voor geheugengebruik van de container, maar niet via systeemlimieten RLIMIT_AS en RLIMIT_DATA, die alleen problematische aanroepen van longjmp() uitlokken.
• Als de 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 vóór het begin van het verwerken van het verzoek) van de parameter «session.upload_progress.enabled=0.
• Bij gebruik van PHP 8.5 dient de parameter «fatal_error_backtraces=0» te worden ingesteld.
• Het verwijderen van verouderde of onjuiste instellingen die aan specifieke verzoeken zijn gebonden (zoals assert.* en onjuiste paden in open_basedir), die leiden tot het weergeven van diagnostische berichten vóór de initialisatie.
• Het elimineren van situaties in PHP-code die leiden tot time-outs en fatale fouten, bijvoorbeeld gerelateerd aan falingen in callback-handlers en het verwerken van uploads.
• Om de eerste kwetsbaarheid in de code van oude PHP-versies te blokkeren, kan de aanroep van longjmp() in de handler voor onvoldoende geheugen 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 werd getoond in de eerdere aankondiging.

De status van het oplossen van kwetsbaarheden in de distributies kan worden beoordeeld 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 gedetailleerde analyse.

Aanvulling 2: De auteur van de prototype-exploit die gebruik maakt van de kwetsbaarheid veroorzaakt door double-free, meldde dat het probleem nog steeds niet is opgelost in de release PHP 8.5.12 en dat de exploit blijft werken. Eerder verklaarden vertegenwoordigers van PHP dat deze kwetsbaarheid niet gerelateerd is aan de komende correcties en geen reëel probleem vormt. De auteur van de exploit beweerde echter dat dit een geheel andere kwetsbaarheid is.

Bron: opennet.ru