Detaljer om kritiske sårbarheter i PHP er blitt avslørt, og korrigerende oppdateringer er publisert.

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øttede versjoner av PHP 7.4, PHP 8.0 og PHP 8.1 (sårbare versjoner fra 5.4 til 7.3 forblir uten oppdateringer), der to kritiske sårbarheter er blitt rettet:

• CVE-2026-109618 — ekstern kodekjøring, forårsaket av at når tilgjengelig minne for prosessen er oppbrukt, kan minnehåndteringsfunksjonen via utførelsen av funkjsonen longjmp() avbryte PHP-tolkeren i en tilstand der bare en del av de interne strukturene relatert til håndtering av forespørselen er initialisert. Videre refererer funksjonen som avslutter håndteringen av forespørselen til disse strukturene som allerede er initialisert, selv om det ikke er tildelt minne for dem.

  Hovedvektoren for angrep er manipulering av multipart-forespørslene for å skape forhold som fører til oppbruk av tilgjengelig minne for prosessen. For å omgå grensen for post_max_size kan ikke innholdstypen Content-Length spesifiseres, og et enormt antall HTTP-hoder kan sendes. Presise angrep på spesifikke operasjoner i PHP-applikasjoner som bruker for mye minne er også 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ør angrep vanskeligere, men teoretisk sett ikke umulig.

• CVE-2026-109619 — ekstern kodekjøring, forårsaket av tilgang til minne etter at det er frigjort på grunn av feilaktig opprydding av global tilstand knyttet til en spesifikk forespørsel. Hvis forespørselen avbrytes på grunn av en fatal feil, tidsavbrudd eller mangel på minne, kan den globale tilstanden forbli uendret, og pekerne forblir aktive, til tross for at minnet de refererer til er frigjort. Ved behandling av den neste forespørselen i samme prosess kan det oppstå tilgang via en gjenværende peker til den gamle globale tilstanden.

  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).

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:

• Setting the `memory_limit=-1` parameter in php.ini makes it difficult for an attacker to control the exhaustion of memory limits.
• Setting the `post_max_size = 8M` parameter if there is no need to upload large files. The value of the `upload_max_filesize` parameter should be less than that of `post_max_size`.
• 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.
• 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.
• Setting at the php.ini level or configuration serveren (not via ini_set() or FPM .user.ini, as the parameter must take effect before request processing begins) the `session.upload_progress.enabled=0` parameter.
• When using PHP 8.5, the `fatal_error_backtraces=0` parameter should be set.
• Removing deprecated or erroneous settings (such as assert.* and incorrect paths in open_basedir) attached to individual requests that lead to the output of diagnostic messages before initialization.
• Eliminating situations in PHP code that lead to timeouts and fatal errors, such as those related to failures in callback handlers and upload processing.
• For blocking the first vulnerability in the code of older PHP versions, you can replace the longjmp() call in the out-of-memory handler with _exit().
• Additionally, you can lower the max_input_nesting_level parameter in php.ini and block multipart requests, as demonstrated in the preliminary announcement.

The status of vulnerability remediation in distributions can be evaluated on the following pages: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.

Supplement 1: Vulnerabilities were identified using AI models GPT‑5.6 and Gemini 4 Argon. OpenAI has released the php2shell-checker utility to check website and local executable file vulnerability exposure, but this utility only checks the PHP version returned by the HTTP server or the command 'php -v' without detailed analysis.

Supplement 2: The author of the exploit prototype, which utilizes the vulnerability caused by double-free memory, reported that the issue remains unpatched in the PHP 8.5.12 release, and the exploit continues to work. Previously, PHP representatives stated that this vulnerability was not related to the upcoming fixes and was not a real issue. However, the exploit's author claimed that it is a completely different vulnerability.

Kilde: opennet.ru