Remote Code Execution (RCE) Affecting php package, versions [,8.2.35)[8.3.0,8.3.36)[8.4.0,8.4.27)[8.5.0,8.5.12)
Threat Intelligence
This vulnerability is trending on Twitter; this may indicate a growing threat.
Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-UNMANAGED-PHP-21347796
- published21 Oct 2026
- disclosed21 Oct 2026
- creditlcfr-hax, sagitzadik-wiz, tomash-areion, amyb-oai
Introduced: 21 Oct 2026
NewCVE-2026-109619 (opens in a new tab)How to fix?
Upgrade php to version 8.2.35, 8.3.36, 8.4.27, 8.5.12 or higher.
Overview
Affected versions of this package are vulnerable to Remote Code Execution (RCE) due to a use after free in the worker global state covering error, session, object, and extension data, where state owned by one request stays published after the request heap is freed, so an operation running before the next request's normal initialization consumes a dangling pointer. An attacker can reach remote code execution by first interrupting an operation after it publishes such state, through a parse or compile failure, an uncaught error, a failed require, Maximum execution time exceeded, or memory exhaustion, and then triggering a consumer on a later request handled by the same worker.
The two confirmed consumers are a warning, notice, or deprecation emitted while applying invalid or deprecated INI settings before executor initialization, and session upload progress reaching session handling before ordinary session initialization, with the strongest demonstrated case being fatal_error_backtraces on PHP 8.5, whose backtrace state is never reset during shutdown. Exploitation needs both a producer and a consumer in the same worker, so reachability turns on the SAPI: mod_php applies .htaccess and php_value directives before php_request_startup(), FPM is exposed only when a frontend passes PHP_VALUE or PHP_ADMIN_VALUE producing an early diagnostic, and no equivalent early configuration consumer is established for FrankenPHP in its default configuration. Adjusting error_reporting, using @, or disabling display_errors or log_errors does not help, because the global state is accessed before PHP decides whether to report the diagnostic at all.
Workarounds
The following partial mitigations are possible, but none completely remove the vulnerability.
Set session.upload_progress.enabled=0 and restart every worker, applying it through php.ini, an FPM pool, or server configuration that takes effect before request parsing, never ini_set() or an FPM .user.ini. This removes the demonstrated early session producer and consumer, and no other variant.
On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This removes the producer behind the confirmed case, and nothing else.
Remove invalid or deprecated settings applied per request that emit a diagnostic before initialization, which closes the INI consumer. Suppressing the output with error_reporting, display_errors, or @ does not help, since the stale state is read before PHP decides whether to report.
Fix attacker-reachable fatal errors and execution timeouts, including failures inside callbacks, upload and import processing, and cleanup, which is what abandons an operation before its matching reset.