{"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\/da\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Detaljer om kritiske s\u00e5rbarheder i PHP er blevet afsl\u00f8ret, og rettende opdateringer er blevet offentliggjort.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Korrigerende udgivelser af PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35 er blevet offentliggjort, samt patcher til de allerede ikke underst\u00f8ttede versioner PHP 7.4, PHP 8.0 og PHP 8.1 (s\u00e5rbare versioner fra 5.4 til 7.3 f\u00e5r ikke patcher), hvor to kritiske s\u00e5rbarheder er blevet rettet:<\/p>\n
\n
CVE-2026-109618 \u2014 remote code execution triggered by exhausting the available process free memory, where the memory shortage handler via executing the longjmp() function can interrupt the PHP interpreter in a state where only part of the internal structures related to request handling are initialized. Subsequently, the request termination function accesses these structures as if they were already initialized, even though no memory has been allocated for them.\n
Det prim\u00e6re angrebsvinkel er manipulation med multipart-foresp\u00f8rgsler for at skabe forhold, der f\u00f8rer til opbrug af den tilg\u00e6ngelige hukommelse til processen. For at omg\u00e5 begr\u00e6nsningen post_max_size kan headeren Content-Length undlades, og et enormt antal HTTP-headere kan sendes. M\u00e5lrettede angreb p\u00e5 specifikke handlinger i PHP-applikationer, der bruger for meget hukommelse, er ogs\u00e5 mulige. Eksploiten er bekr\u00e6ftet for mod_php, da den kalder funktionen shutdown() selv ved en fejl. PHP-FPM afslutter ved en fejl den underliggende proces, hvilket vanskeligg\u00f8r angrebet, men teoretisk kan det ikke udelukkes. <\/p>\n
CVE-2026-109619 \u2014 remote code execution caused by accessing memory after it has been freed due to incorrect cleanup of global state tied to a specific request. In the event of a request being interrupted due to a fatal error, timeout, or memory shortage, the global state may not be reset, and pointers may remain active despite the memory they reference being freed. When processing the next request in the same process, there may be access via the remaining pointer to the old global state.\n
K\u00f8rsel kan medf\u00f8re udt\u00f8mning af tilg\u00e6ngelig hukommelse ved behandling af multipart-anmodninger i koden til indikation af uploadens fremskridt (session.upload_progress). Den prim\u00e6re og bekr\u00e6ftede angrebsvektor n\u00e6vnes som handleren fatal_error_backtraces i PHP 8.5, som ikke nulstiller sporingsstatus ved afslutning. I f\u00f8rste tilf\u00e6lde er angrebet muligt p\u00e5 mod_php og PHP-FPM, mens det i det andet kun er muligt p\u00e5 mod_php. Der n\u00e6vnes ogs\u00e5 en ubekr\u00e6ftet mulighed for angreb i konfigurationer, hvor indstillinger medf\u00f8rer visning af advarsler p\u00e5 et tidligt stadium af anmodningsbehandlingen (f.eks. advarsler om brug af for\u00e6ldede parametre).<\/p>\n<\/ul>\n
Det er blevet erkl\u00e6ret, at fuld blokering af s\u00e5rbarheder kun er mulig gennem installation af opdateringer. F\u00f8lgende foranstaltninger kan reducere sandsynligheden for, at angreb lykkes, men g\u00f8r systemet ikke helt sikkert:<\/p>\n
\n
Setting the php.ini parameter 'memory_limit=-1', which complicates 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 'upload_max_filesize' should be less than the value of 'post_max_size'.\n
S\u00e6tte en gr\u00e6nse for det tilladte hukommelsesforbrug p\u00e5 systemniveau, via cgroup memory.max eller containerens hukommelsesforbrug, men ikke via systemgr\u00e6nserne RLIMIT_AS og RLIMIT_DATA, som blot fremkalder det problematiske kald longjmp().\n
Hvis ydeevnen ikke er vigtig, kan antallet af anmodninger, der behandles af en enkelt arbejdsproces, begr\u00e6nses gennem pm.max_requests=1 i PHP-FPM og MaxRequestsPerChild i Apache httpd.\n