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øttede versioner PHP 7.4, PHP 8.0 og PHP 8.1 (sårbare versioner fra 5.4 til 7.3 får ikke patcher), hvor to kritiske sårbarheder er blevet rettet:
- CVE-2026-109618 — fjernudførelse af kode, der skyldes, at når den tilgængelige procesfri hukommelse er opbrugt, kan hukommelsesfejlhåndtereren via udførelsen af funktionen longjmp() afbryde PHP-interpretatoren i en tilstand, hvor kun en del af de interne strukturer relateret til behandling af forespørgslen er blevet initialiseret. Den efterfølgende behandlingsafslutningsfunktion henviser til disse strukturer som allerede initialiserede, selvom der ikke er allokeret hukommelse til dem.
Det primære angrebsvinkel er manipulation med multipart-forespørgsler for at skabe forhold, der fører til opbrug af den tilgængelige hukommelse til processen. For at omgå begrænsningen post_max_size kan headeren Content-Length undlades, og et enormt antal HTTP-headere kan sendes. Målrettede angreb på specifikke handlinger i PHP-applikationer, der bruger for meget hukommelse, er også mulige. Eksploiten er bekræftet for mod_php, da den kalder funktionen shutdown() selv ved en fejl. PHP-FPM afslutter ved en fejl den underliggende proces, hvilket vanskeliggør angrebet, men teoretisk kan det ikke udelukkes.
- CVE-2026-109619 — fjernudførelse af kode, der er forårsaget af adgang til hukommelse efter dens frigivelse på grund af forkert oprydning af den globale tilstand, der er knyttet til en bestemt forespørgsel. Hvis forespørgslen afbrydes på grund af en fatal fejl, timeout eller mangel på hukommelse, kan den globale tilstand forblive uafklaret, og pegerne forbliver aktive, på trods af at den hukommelse, de refererer til, er frigivet. Ved behandling af den næste forespørgsel i den samme proces kan der opstå adgang via den tilbageværende peger til den gamle globale tilstand.
Kørsel kan medføre udtømning af tilgængelig hukommelse ved behandling af multipart-anmodninger i koden til indikation af uploadens fremskridt (session.upload_progress). Den primære og bekræftede angrebsvektor nævnes som handleren fatal_error_backtraces i PHP 8.5, som ikke nulstiller sporingsstatus ved afslutning. I første tilfælde er angrebet muligt på mod_php og PHP-FPM, mens det i det andet kun er muligt på mod_php. Der nævnes også en ubekræftet mulighed for angreb i konfigurationer, hvor indstillinger medfører visning af advarsler på et tidligt stadium af anmodningsbehandlingen (f.eks. advarsler om brug af forældede parametre).
Det er blevet erklæret, at fuld blokering af sårbarheder kun er mulig gennem installation af opdateringer. Følgende foranstaltninger kan reducere sandsynligheden for, at angreb lykkes, men gør systemet ikke helt sikkert:
- Indstilling af php.ini-parameteren „memory_limit=-1”, hvilket vanskeliggør gør det vanskeligt for angriberen at kontrollere udtømningen af hukommelsesgrænserne.
- Indstilling af parameteren „post_max_size = 8M”, hvis der ikke er behov for at uploade store filer. Værdien af parameteren „upload_max_filesize” skal være mindre end værdien af parameteren „post_max_size”.
- Sætte en grænse for det tilladte hukommelsesforbrug på systemniveau, via cgroup memory.max eller containerens hukommelsesforbrug, men ikke via systemgrænserne RLIMIT_AS og RLIMIT_DATA, som blot fremkalder det problematiske kald longjmp().
- Hvis ydeevnen ikke er vigtig, kan antallet af anmodninger, der behandles af en enkelt arbejdsproces, begrænses gennem pm.max_requests=1 i PHP-FPM og MaxRequestsPerChild i Apache httpd.
- Indstilling på niveauet php.ini eller konfiguration server (ikke gennem ini_set() eller FPM .user.ini, da parameteren skal gælde før anmodningens behandling påbegyndes) parameteren „session.upload_progress.enabled=0”.
- Ved brug af PHP 8.5-versionen bør parameteren „fatal_error_backtraces=0” indstilles.
- Fjernelse af bundet til individuelle anmodninger forældede eller fejlagtige indstillinger (som assert.* og forkert stier i open_basedir), der fører til visning af diagnostiske meddelelser før initialization.
- Eliminering i PHP-koden af situationer, der fører til tidsoverskridelser og fatale fejl, f.eks. relateret til nedbrud i callback-handlere og uploadbehandling.
- For blocking the first vulnerability in the code of old PHP versions, you can replace the call to longjmp() in the memory exhaustion handler with _exit().
- Additionally, you can reduce the value of the max_input_nesting_level parameter in php.ini and block multipart requests, as shown in the preliminary announcement.
The status of vulnerability remediation in distributions can be assessed on these pages: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
Addendum 1: Vulnerabilities were detected using AI models GPT-5.6 and Gemini 4 Argon. OpenAI has released a utility called php2shell-checker to check for website and local executable file vulnerabilities, but this utility only checks the PHP version returned by the HTTP server or the command 'php -v', without detailed analysis.
Addendum 2: The author of the exploit prototype that exploits the double free vulnerability reported that the issue remains unpatched in the release of PHP 8.5.12 and the exploit continues to work. Previously, representatives of PHP stated that this vulnerability is not related to upcoming fixes and is not a real problem. However, the author of the exploit claimed that this is a completely different vulnerability.
Kilde: opennet.ru
