CVE-2026-109618

CVE-2026-109619

October 21, 2026

Minutes Read

PHP Critical Remote Code Execution Vulnerabilities

Security Advisory

Advisory

October 21, 2026

Minutes Read

PHP Critical Remote Code Execution Vulnerabilities

Security Advisory

Advisory

October 21, 2026

Minutes Read

Kudelski Security Team

Find out more

table of contents

Share on

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

Summary

On 2026-10-21, the PHP project released PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 to fix two critical vulnerabilities that can allow unauthenticated remote code execution (RCE).

CVE-2026-109618 is an RCE via out-of-memory (OOM) corruption.
CVE-2026-109619 is an RCE via stale global state.

Both are rated CVSS 4.0 9.2 (Critical) by the PHP security team.

The PHP project states that only an update is a complete solution and that configuration mitigations only reduce exposure to specific attack paths. These mitigations should only be used if immediate upgrades are not possible.

The vendor reports a demonstrated exploit against mod_php, and exploitation in the wild has been reported, though not corroborated.

Affected Systems and Applications

PHP versions earlier than:

- 8.2.35

- 8.3.36

- 8.4.27

- 8.5.12

All PHP installations serving web requests, including:

- PHP-FPM

- Apache with mod_php

- php-cgi

- FrankenPHP

- LiteSpeed

The vendor considers the risk highest for mod_php.
PHP 8.1 and older no longer receive updates from the PHP project; however, some distributions and LTS vendors provide backported fixes.
The project published minimal source backports for:

- PHP 7.4

- PHP 8.0

- PHP 8.1

The vendor does not list these branches as affected in the GHSAs, but the existence of the backports indicates they carry the issue.
Claims that every PHP version from PHP 5 onward is affected have not been confirmed by a vendor source.
Exposure of PHP 5.x and PHP 7.0–7.3 remains unknown.

Technical Details

Vulnerability Mechanism

CVE-2026-109618 (RCE via OOM Corruption)

PHP uses longjmp() for out-of-memory errors to abort the current request.

If an allocation fails while request memory is only partially initialized, the early exit leaves invalid data that request cleanup can treat as valid.

Several multipart parsing behaviors can trigger OOM within normal PHP limits.

CVE-2026-109619 (RCE via Stale Global State)

Request-owned global state (error, session, object, and extension state) can survive after its backing memory is freed.

A later request handled by the same worker may use that stale state before normal initialization resets it, causing a use-after-free condition. A crafted heap layout can lead to RCE.

Fatal errors, including OOM conditions, can skip the cleanup that resets state.

Two confirmed consumers are:

INI diagnostics raised before request initialization
Session upload progress handling

Observed Exploitation Path

The PHP project reports unauthenticated RCE as the web worker account, validated against mod_php with default settings.
An unauthenticated request can trigger the attack before any application code runs.
The advisory describes a demonstrated exploit but does not state that exploitation occurred in the wild.
watchTowr states exploitation was observed in the wild as of 2026-10-21 through its honeypot network, though no independent corroboration has been found.
No attribution, threat campaign details, or indicators of compromise (IOCs) have been published.

Key Points

Impact is unauthenticated remote code execution in a technology that supports a very large share of web applications.
No complete workaround exists; updating is the only complete fix.
According to CrowdStrike, out-of-the-box visibility and detection coverage exists for post-exploitation activities related to these PHP vulnerabilities. Existing IOAs detect and prevent:

- Web shell deployment

- Suspicious child processes spawned by PHP or web server processes

- Malicious command execution

Palo Alto Networks lists Threat Prevention signature 543004 as currently available.

Mitigation

Immediate Actions for Self-Hosted Instances

Limit Exposure

These measures reduce exposure to specific attack paths only and do not make an installation safe.

CVE-2026-109618

Set:‍ memory_limit=-1

in a way applications cannot override (for example, using php_admin_value in an FPM pool or Apache configuration).

Verify no pool, directory, or application setting restores a finite limit.
Note that an underlying allocation failure can still reach the vulnerable path.
Set a low post_max_size:

- 8M if no file uploads are required

- 32M if uploads are required

Ensure upload_max_filesize remains below post_max_size.
Enforce limits at the web server or proxy for:

- Decoded request size

- Input field count

- Multipart part count

- Header count

- Nesting depth

Block multipart requests at the frontend if applications do not require them.
Use container or cgroup memory limits as an availability boundary.
Prefer terminating only the affected worker.
Do not use:

- RLIMIT_AS

- RLIMIT_DATA

These limits can trigger the vulnerable allocation failure path.

CVE-2026-109619

Disable upload progress tracking:session.upload_progress.enabled=0

Apply the setting via:

- php.ini

- FPM pool configuration

- Server configuration that takes effect before request parsing

Restart all PHP workers.
Do not rely on:

- ini_set()

- .user.ini

This blocks the confirmed session paths but may not prevent other variants.

PHP 8.5 Only

Set:fatal_error_backtraces=0

Then restart all PHP workers.

This blocks the confirmed fatal backtrace path only.

Additional Recommendations

Remove invalid or deprecated per-request settings that emit diagnostics before initialization.
Fix attacker-reachable fatal errors.
Fix attacker-reachable execution timeouts.
Hiding diagnostics with:

- error_reporting

- display_errors

- @

does not mitigate the issue.

Consider:pm.max_requests=1

if performance requirements allow.

Patch / Upgrade

Recommended Versions

Upgrade to:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

Additional Guidance

Linux distributions and LTS vendors received patches in advance. Check vendor repositories for updated packages.
PHP 8.1 and older:

- Obtain a vendor backport, or

- Upgrade to a supported PHP release.

Minimal source backports are available for:

- PHP 7.4

- PHP 8.0

- PHP 8.1

The PHP project urges users of the volunteer-maintained rpms.remirepo.net repository to switch to distribution packages or build from source, as updates may not be immediately available.
Restart all PHP workers after:

- Updating PHP

- Applying configuration changes