PHP Group PHP stale global-state use-after-free enables remote code execution

PHP has various global state that temporarily points into request memory. In some scenarios, global state may not be correctly reset, or may be repopulated after being reset. The global state may then refer to request memory even after it has been freed. Subsequent requests may read or branch on this stale state before it is fully initialized. Multiple strategies can trigger this condition and produce remote code execution (RCE).

PHP Group PHP package php-src has defaultStatus set to unaffected outside the listed ranges. The affected branches and listed fixed releases are:

• Branch 8.2.*: affected when less than 8.2.35; the listed patched release is 8.2.35.
• Branch 8.3.*: affected when less than 8.3.36; the listed patched release is 8.3.36.
• Branch 8.4.*: affected when less than 8.4.27; the listed patched release is 8.4.27.
• Branch 8.5.*: affected when less than 8.5.12; the listed patched release is 8.5.12.

Branches or releases outside these ranges should not be inferred from the fact that one branch has a fix.

PHP retains global state, including error, session, object and extension state, in a worker even though that state may point to memory owned by one request. A producer operation can publish request-owned state and then fail to reset it, or repopulate it after its normal reset. When the request ends, its heap is freed while the worker still retains the stale reference; a later request handled by the same worker can act as a consumer and read, free, branch on or otherwise use the stale state before normal request initialization replaces it.

Documented producer conditions include fatal errors, out-of-memory failures, parse or compile failures, uncaught errors, require failures, execution timeouts and some diagnostics raised during cleanup. Confirmed consumers include INI diagnostics before request initialization and session upload progress before ordinary session initialization. With Apache mod_php, .htaccess and php_value, php_flag or php_admin_* settings can be applied early; with FPM, reachability depends on frontend-supplied PHP_VALUE or PHP_ADMIN_VALUE parameters and application behavior. Exposure of other state families depends on the application, extensions and the point at which the state was published.

The vulnerability can be reached over the network without prior privileges or user interaction, but exploitation requires specific deployment and lifecycle conditions. The producer request and consumer request must be handled by the same worker; multiple workers or worker recycling reduce the success rate per request but do not remove the condition.

The advisory confirms RCE through the fatal_error_backtraces path on mod_php, and confirms the session upload progress path on mod_php and FPM. The validated FPM path requires state to be published during application execution after successful startup, followed by a fatal error and a later request using session upload progress. The supplied record identifies no public exploit; its current enrichment also labels exploitation as none, but that status does not prove exploitation is impossible.

The confirmed technical outcomes are unauthenticated heap use-after-free, memory disclosure and RCE with the web worker's privileges. The fatal_error_backtraces path has confirmed RCE on mod_php, while the session lifecycle path has been validated on both mod_php and FPM. Other error, exception, object or extension state families establish security impact only when a concrete producer and consumer are demonstrated.

An attacker must still create the producer condition, allow request memory to be freed, have the same worker handle a subsequent request and reach the consumer before normal initialization completes. Therefore, not every deployment or route has the same exploitability, but the absence of an error in logs does not exclude exposure. If RCE succeeds, the attacker may obtain the worker's privileges and affect data, application code or system resources accessible to that account.

Successful exploitation can let an unauthenticated attacker execute code with the web worker's privileges, read heap data or alter PHP process behavior. RCE may provide access to or modification of data available to the worker, although the practical scope remains bounded by the worker account and system configuration. The flaw can also affect service availability if heap or process state is corrupted. Multiple workers and worker recycling reduce the success rate per request but do not eliminate the risk.

1. Update each affected branch to its exact listed fixed release: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. The advisory identifies the complete state-reset patch as the only reliable mitigation.
2. If a PHP 8.5 installation cannot be updated, set fatal_error_backtraces=0 administratively and restart every worker. This removes the producer used by the confirmed RCE path, but does not cover other request-owned global or extension state.
3. If updating is not yet possible and session upload progress is not required, set session.upload_progress.enabled=0 and restart every worker. This blocks the demonstrated session producer and consumer path, but does not mitigate other lifecycle paths.
4. Remove fatal errors, warnings and diagnostics from attacker-reachable request paths, including upload, import, error-page, shutdown, destructor, serialization, output-handler, plugin and extension paths. Prefer php.ini, FPM-pool or server configuration applied at startup over per-request overrides, and remove obsolete directives.
5. If compatible with performance requirements, consider limiting the number of requests handled by each worker with pm.max_requests=1. Changing the execution time limit is not a complete fix; it only removes one possible interruption.
6. After configuration changes, restart all relevant workers and recheck inventory, configuration, logs and application flow.

1. Inventory all PHP deployments and identify the worker model, especially Apache mod_php, FPM and LSAPI; compare the php-src package with the affected branches and fixed points in affected_summary.
2. Review settings that can produce diagnostics before request initialization, including .htaccess, PHP_VALUE, PHP_ADMIN_VALUE, per-request INI settings and invalid, obsolete or conflicting INI values.
3. Check fatal_error_backtraces and session.upload_progress.enabled, and identify routes that can trigger uploads, fatal errors, timeouts, callbacks, plugins or extension behavior.
4. During an isolated audit, enable log_errors=On, use error_reporting=E_ALL and verify that error_log is functional. Review Apache, PHP-FPM, reverse-proxy and service logs for warnings, deprecations, core errors, fatal or uncaught errors, parse failures, Maximum execution time exceeded and failures limited to attacker-controlled routes or content types.
5. Use logs to supplement inventory, static configuration review and application-flow review. Do not treat the absence of an error in logs as proof of safety because the failure may occur before logging or relevant log levels may have been excluded.