PHP Fixes Two Critical RCE Vulnerabilities Allowing Unauthenticated Code Execution
PHP Fixes Two Critical RCE Vulnerabilities Allowing Unauthenticated Code Execution
PHP released emergency security updates to address two critical vulnerabilities that could allow unauthenticated attackers to execute code on vulnerable servers. These vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and both have a CVSS v4.0 score of 9.2. The fixes are included in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Administrators should update immediately, as…
Vulnerabilities mentionedAll →
- CVE-2026-1096199.26%PHP has various global state that temporarily points into request memorypublished · php php PoC ×7+1 related
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-109619 |
Full article566 words · extracted from gbhackers.com · click to collapse
PHP released emergency security updates to address two critical vulnerabilities that could allow unauthenticated attackers to execute code on vulnerable servers.
These vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619, and both have a CVSS v4.0 score of 9.2. The fixes are included in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Administrators should update immediately, as configuration changes alone cannot fully eliminate exposure.
The PHP project considers all installations serving web requests to be potentially at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed.
Among these, Apache mod_php presents the highest demonstrated risk: researchers have been able to achieve code execution through unauthenticated requests before any application code executes. Successful exploitation allows malicious code to run with the privileges of the web worker account.
PHP Fixes Two Critical RCE Flaw
CVE-2026-109618 impacts PHP’s handling of out-of-memory (OOM) conditions. Previously, PHP used `longjmp()` to abandon execution when memory allocation failed.
If this interruption occurred while request data remained partially initialized, subsequent shutdown routines could operate on invalid internal structures, leading to memory corruption and potential remote code execution.
Multipart request processing offers several pathways to memory exhaustion. For example, requests lacking usable Content-Length information can bypass initial size checks.
At the same time, excessive multipart headers and nested file metadata can consume disproportionate memory. Apache mod_php performs an unconditional request shutdown after startup failures, exposing a corrupted state before application logic begins.
The patch modifies OOM handling by replacing the abrupt failure with a delayed, graceful failure that occurs at a safe point in the virtual machine. Additionally, a higher memory threshold triggers immediate process termination through `_exit()`, preventing unsafe cleanup while maintaining memory controls.
CVE-2026-109619 relates to request-owned memory that is referenced by persistent worker globals after that memory has been freed. Fatal errors or late shutdown diagnostics can leave stale error, session, object, or extension state available for subsequent requests.
Exploitation requires one operation to leave the stale state and another request, handled by the same worker, to consume it before initialization resets the globals. Confirmed paths include fatal-error backtraces in PHP 8.5 and session upload progress processing.
Researchers have validated that remote code execution is possible against mod_php and, through specific application-dependent session paths, PHP-FPM. Using multiple workers might reduce the chance of successful exploitation per request, but does not eliminate the vulnerability.
Administrators should deploy the corrected PHP release for their branch or obtain vendor packages containing backported fixes. PHP versions 8.1 and older no longer receive upstream updates; affected operators should consult their distribution or LTS provider, or migrate to a supported release.
Temporary measures include disabling `session.upload_progress.enabled` and, on PHP 8.5, `fatal_error_backtraces`, followed by restarting all workers. These changes will block confirmed exploitation paths, but not every potential variant. Suppressing displayed errors does not prevent exploitation of the stale state.
To address OOM exposure, enforcing `memory_limit=-1` avoids the predictable PHP memory-limit trigger but still allows for underlying allocation failures.
Implementing conservative request limits and using container or cgroup boundaries can help reduce exposure and availability risks. PHP explicitly warns against replacing `RLIMIT_AS` or `RLIMIT_DATA`, as this may trigger vulnerable allocation failures. Updating remains the only complete solution for both vulnerabilities across affected deployments.
Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.
Divya is a Senior Journalist at GBhackers covering Cyber Attacks, Threats, Breaches, Vulnerabilities and other happenings in the cyber world.