{"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\/no\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Detaljer om kritiske s\u00e5rbarheter i PHP er blitt avsl\u00f8rt, og korrigerende oppdateringer er publisert.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Det er utgitt korrigerende utgaver av PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35, samt sikkerhetsoppdateringer for ikke-lenger st\u00f8ttede versjoner av PHP 7.4, PHP 8.0 og PHP 8.1 (s\u00e5rbare versjoner fra 5.4 til 7.3 forblir uten oppdateringer), der to kritiske s\u00e5rbarheter er blitt rettet:<\/p>\n
\n
CVE-2026-109618 \u2014 fjernutf\u00f8relse av kode p\u00e5 grunn av at n\u00e5r tilgjengelig prosessminne er oppbrukt, kan minneh\u00e5ndteringsfunksjonen via funksjonen longjmp() avbryte PHP-tolken i en tilstand der bare deler av de interne strukturene relatert til foresp\u00f8rselsh\u00e5ndteringen er initialisert. Senere kan fullf\u00f8ringsfunksjonen av foresp\u00f8rselen referere til disse strukturene som om de allerede er initialisert, selv om minne for dem ikke er allokert.\n
Hovedvektoren for angrep er manipulering av multipart-foresp\u00f8rslene for \u00e5 skape forhold som f\u00f8rer til oppbruk av tilgjengelig minne for prosessen. For \u00e5 omg\u00e5 grensen for post_max_size kan ikke innholdstypen Content-Length spesifiseres, og et enormt antall HTTP-hoder kan sendes. Presise angrep p\u00e5 spesifikke operasjoner i PHP-applikasjoner som bruker for mye minne er ogs\u00e5 mulige. Eksploitasjon er bekreftet for mod_php, ettersom den kaller funksjonen shutdown() selv under feil. PHP-FPM vil avslutte dataprocessen ved feil, noe som gj\u00f8r angrep vanskeligere, men teoretisk sett ikke umulig. <\/p>\n
CVE-2026-109619 \u2014 fjernutf\u00f8relse av kode p\u00e5 grunn av tilgang til minne etter frigj\u00f8ring p\u00e5 grunn av feilaktig rensing av global tilstand knyttet til en spesifikk foresp\u00f8rsel. Hvis foresp\u00f8rselen avbrytes p\u00e5 grunn av en fatal feil, tidsavbrudd eller mangel p\u00e5 minne, kan den globale tilstanden forbli nullstilt, og pekere vil forbli aktive til tross for at minne de refererer til er frigjort. Ved behandling av neste foresp\u00f8rsel i samme prosess kan det oppst\u00e5 en referanse via den gjenv\u00e6rende pekeren til den gamle globale tilstanden.\n
For operation, conditions can be created that exhaust available memory while processing a multipart request in the code for upload progress indication (session.upload_progress). In this case, the main and confirmed attack vector mentioned is the fatal_error_backtraces handler in PHP 8.5, which does not reset the trace state upon termination. In the first case, the attack is possible on mod_php and PHP-FPM, and in the second only on mod_php. An unverified possibility of conducting an attack is also mentioned in configurations with directives that lead to the output of warnings at an early stage of request processing (for example, warnings about the use of deprecated parameters).<\/p>\n<\/ul>\n
It is claimed that complete vulnerability blocking is only possible through the installation of updates. The following measures can reduce the likelihood of successful attacks but do not make the system completely secure:<\/p>\n
\n
Innstilling av php.ini-parameteren \u00abmemory_limit=-1\u00bb, noe som gj\u00f8r det vanskeligere for en angriper \u00e5 kontrollere oppbruken av minnegrenser.\n
Innstilling av parameteren \u00abpost_max_size = 8M\u00bb dersom det ikke er n\u00f8dvendig \u00e5 laste opp store filer. Verdien av parameteren \u00abupload_max_filesize\u00bb b\u00f8r v\u00e6re mindre enn parameteren \u00abpost_max_size\u00bb.\n
Setting a limit for allowable memory consumption at the system level via cgroup memory.max or container memory consumption parameters, but not through system limits RLIMIT_AS and RLIMIT_DATA, which only provoke the problematic longjmp() call.\n
If performance is not critical, the number of requests processed by a single worker process can be limited through pm.max_requests=1 in PHP-FPM and MaxRequestsPerChild in Apache httpd.\n