{"id":183943,"date":"2026-10-22T05:40:56","date_gmt":"2026-10-22T03:40:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/raskryty-detali-kriticheskih-uyazvimostej-v-php-i-opublikovany-korrektiruyushhie-obnovleniya"},"modified":"2026-10-22T05:41:02","modified_gmt":"2026-10-22T03:41:02","slug":"details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Details van kritieke kwetsbaarheden in PHP onthuld en correctieve updates gepubliceerd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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:<\/p>\n
\n
CVE-2026-109618 \u2014 remote code execution caused by exhausting the available free memory for the process, where the out-of-memory handler via the longjmp() function may interrupt the PHP interpreter in a state where only part of the internal structures related to request processing have been initialized. Subsequently, the request handling function accesses these structures as if they were already initialized, even though no memory has been allocated for them.\n
De belangrijkste aanvalsvector is het manipuleren van multipart-verzoeken om condities te cre\u00ebren 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\u00ebindigt de subprocess bij een fout, wat een aanval bemoeilijkt, maar theoretisch niet uitsluit. <\/p>\n
CVE-2026-109619 \u2014 remote code execution caused by accessing memory after it has been freed due to improper cleanup of the global state tied to a specific request. If a request is interrupted due to a fatal error, timeout, or memory exhaustion, the global state may remain active and pointers will still reference freed memory, despite being deallocated. During the handling of the next request in the same process, an access via the remaining pointer to the old global state may occur.\n
Voor de werking kan het cre\u00ebren 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).<\/p>\n<\/ul>\n
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:<\/p>\n
\n
Setting the parameter in php.ini to 'memory_limit=-1', which hinders the attacker's ability to control the exhaustion of memory limits.\n
Setting the parameter 'post_max_size = 8M' if there is no need to upload large files. The value of the 'upload_max_filesize' parameter should be less than the 'post_max_size' parameter.\n
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.\n
Als de prestaties niet belangrijk zijn, kan het aantal verzoeken dat door \u00e9\u00e9n werkproces wordt verwerkt worden beperkt via pm.max_requests=1 in PHP-FPM en MaxRequestsPerChild in Apache httpd.\n