CVE detail

CVE-2026-109618: PHP Remote Code Execution via Out-of-Memory Corruption

CVE-2026-109618 is one of the two PHP runtime vulnerabilities grouped under PHP2Shell. It is a critical, unauthenticated remote code execution flaw that arises when PHP runs out of memory during request processing. This page covers the affected deployments, the fixed releases, the temporary mitigations that target this CVE, and its relationship to CVE-2026-109619.

Last updated: October 23, 2026

CVSS v4.0 9.2 CriticalFixed 21 Oct 2026OOM corruption

Check a website Full PHP2Shell advisory

Based on the official php.net advisory. This page contains no exploitation instructions.

Free checker

Check a site for CVE-2026-109618 exposure

Enter a public URL. The checker reads the PHP version a site exposes and compares it with the first fixed release in its branch. A hidden version or a distribution suffix is reported as cannot determine.

Free · No sign-up · We never store the URLs you check

The flaw

What is CVE-2026-109618?

The PHP project published CVE-2026-109618 on 21 October 2026 as part of a critical security release. The official advisory describes an out-of-memory corruption. PHP aborts request processing when an allocation fails, but during some operations the request memory is temporarily reachable without being fully initialized. If the allocation fails at that point, PHP does not account for the early exit correctly and leaves the request in an invalid state. Request shutdown can then process data that looks valid but is not.

Because the failure happens inside the PHP runtime, the application does not need a bug of its own for the issue to matter. The advisory says unauthenticated remote code execution was confirmed against Apache with mod_php. PHP-FPM is considered susceptible based on source analysis, although no complete FPM exploit was demonstrated. FrankenPHP is likely similarly affected, and LiteSpeed's LSAPI is likely susceptible to application-specific attacks but was not validated.

The bug is in PHP, not in the website code

A CMS, framework, plugin, or theme update cannot repair this flaw. The vulnerable logic runs inside the PHP worker, before application code gets a chance to handle the request. The fixed PHP binary is the boundary that matters.

Severity and scope

How serious is CVE-2026-109618?

The advisory rates the flaw CVSS v4.0 9.2, Critical. It does not require an account or application-level access, which is why the advisory treats all PHP installations that serve web requests as in scope: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

The official advisory considers mod_php the highest-risk deployment because a demonstrated exploit can trigger the flaw before application code runs. That does not make the other SAPIs safe. A reverse proxy, CDN, or web application firewall may block some request shapes, but it does not patch the PHP binary.

CVSS v4.0

9.2 · Critical

Unauthenticated remote code execution in affected configurations.

Affected SAPIs

PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. mod_php is the highest-risk setup in the official advisory.

Fixed releases

Which PHP versions fix CVE-2026-109618?

The official fixes are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Every earlier release in those branches is affected. PHP 8.1, 8.0, 7.4, and older no longer receive supported releases from the PHP project. The project published minimal source backports for 7.4, 8.0, and 8.1, and some Linux distributions provide patched packages, but those are not supported PHP releases. The supported path is an upgrade to PHP 8.4 or 8.5.

PHP 8.2 still receives security fixes, but its security support ends on 31 December 2026, so it is a temporary destination rather than a long-term plan. The full per-branch table, including the first fixed release and support status, is on the PHP2Shell checker.

Full affected-version table

A distribution suffix changes the answer. If the version string includes something like -1ubuntu2.19, the vendor may have backported the fix without changing the upstream version. A passive checker cannot tell, so it reports cannot determine. Check the distribution's security notice.

Temporary mitigations

Settings that target CVE-2026-109618

Updating is the only complete fix. The advisory says there are no complete mitigations. The measures below reduce exposure to specific attack paths. They do not make an installation safe, and they do not address CVE-2026-109619.

Set memory_limit=-1 and enforce it where the application cannot override it, such as php_admin_value in the PHP-FPM pool or Apache configuration. Check pools, directories, and application settings for a finite limit that restores the failure path. Even then, an underlying allocation failure can still reach the vulnerable code.
Lower post_max_size. Use 8M if the site does not need file uploads and 32M if it does, and keep upload_max_filesize below post_max_size.
Enforce request limits at the web server or proxy: decoded request size, input field count, multipart part count, header count, and nesting depth. Include requests without a usable Content-Length.
Use a container or cgroup memory limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA as a substitute; the advisory warns that they can trigger the vulnerable allocation failure.

The PHP2Shell advisory has a combined example configuration for both CVEs, with the source links.

Both CVEs

How CVE-2026-109618 relates to CVE-2026-109619

CVE-2026-109619 is a separate PHP runtime flaw: request-owned global state can survive after its backing memory is freed, and a later request on the same worker may use that stale state before normal initialization resets it. The two vulnerabilities were disclosed together and share the same fixed releases, but they are not variants of one bug. A mitigation aimed at the out-of-memory path does not close the stale-state path, and the reverse is also true.

Because both are fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, one update covers both. Read the CVE-2026-109619 guide for the settings that target the second flaw. If an immediate update is impossible, apply both sets of temporary measures and plan the upgrade.

Verification

How to tell whether a server is patched

A passive checker can only report what a site exposes. It reads public response headers and homepage markup and compares the version with the first fixed release. If the version is hidden, or if it carries a distribution suffix, the result is cannot determine rather than a guess.

For a definitive answer, inspect the web SAPI on the server: WordPress Site Health under Tools → Site Health → Info → Server, cPanel's Select PHP Version or MultiPHP Manager, Plesk's PHP Settings, or a temporary file containing <?php echo PHP_VERSION; ?> that is deleted immediately after use.

After updating, restart every PHP worker. Replacing files on disk is not enough if PHP-FPM, Apache, or a container keeps the old binary in memory. Verify through the web server, not only with php -v, because the CLI and the web SAPI can be different builds.

How to patch PHP2Shell cPanel and Plesk guide All check methods

Keep reading

Related guides

CVE-2026-109619

The stale global state flaw, its own temporary settings, and why it needs a separate response.

Read guide

PHP2Shell checker

The combined advisory, the affected-version table, and a configuration example for both CVEs.

Read guide

Patch PHP2Shell

Update and verify PHP on Linux, Docker, and Windows, including the worker restart step.

Read guide

cPanel and Plesk

Switch to a fixed PHP branch on shared hosting and verify the web version afterward.

Read guide

FAQ

CVE-2026-109618 questions

Short answers about the out-of-memory flaw, the fixed releases, and the limits of temporary mitigations.

Is CVE-2026-109618 part of PHP2Shell?

Yes. PHP2Shell is the name used for the pair of critical PHP runtime vulnerabilities CVE-2026-109618 and CVE-2026-109619. Both were addressed in the PHP security release on 21 October 2026, and both affect PHP installations that serve web requests.

Which PHP versions fix CVE-2026-109618?

PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 contain the official fix. Earlier releases in those branches are affected. PHP 8.1 and older have no supported release; the PHP project published minimal source backports for 7.4, 8.0, and 8.1, but the supported path is an upgrade to PHP 8.4 or 8.5.

Is there a workaround for CVE-2026-109618?

There is no complete workaround. The advisory lists temporary measures such as enforcing memory_limit=-1, lowering post_max_size, limiting request sizes at the web server or proxy, and using container or cgroup memory limits. These reduce exposure to specific attack paths but do not make an installation safe. Updating PHP is the only complete fix.

Official references

This guide summarizes the official PHP advisory for site owners. It is not a security audit. A patched PHP version does not by itself prove that a site is secure.

Check another site

The checker is free and does not require an account.

Back to the PHP version checker