PHP2Shell: RCE via OOM corruption

Summary

Unauthenticated remote code execution in the PHP runtime. An out-of-memory exit can occur while request state is only partly initialised; later cleanup may treat invalid memory as valid. PHP says multiple OOM strategies can reach the condition.

Component: PHP core (php-src). Disclosed: 21 October 2026. Last verified: 22 October 2026, 16:45 UTC.

Affected versions

Version ranges preserve the source wording. A distribution package may contain a backport without changing this string. GitHub / PHP Security Team PHP Group CERT-EU Wiz Research

Fixed versions

Fixed upstream in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Distributions may carry a backport without changing the visible version string. PHP Group GitHub / PHP Security Team

Conditions and scope

These are the conditions named by the sources. They are not a score and not a prediction.

• PHP is serving web requests through a SAPI such as Apache mod_php, PHP-FPM, php-cgi, FrankenPHP or LiteSpeed.
• PHP rates Apache mod_php highest risk because a demonstrated exploit can run before application code executes.
• The OOM path depends on inducing an allocation failure while request data is partly initialised; this is not described as every request.
• Bitdefender's analysis says defeating ASLR is also required for exploitation; that is a vendor assessment, not a guarantee.

Exploitation status

Security vendors observed exploitation attempts before and after the patch, including an Amazon honeypot attempt on 17 October 2026. As of this page's verification time, no publicly documented confirmed mass compromise had been established. Attempts are not the same as successful exploitation.

Severity and scoring

Scores are listed with their version and assessor. Different CVSS versions, and different assessors, are not averaged. The presence of a high score does not establish exploitation, and a lower score does not make a memory-safety defect harmless.

What the flaw is

PHP uses longjmp() to leave the current execution context when an out-of-memory condition occurs. The advisory says some contexts do not fully account for that exit while request memory is still being initialised. Request cleanup can then read or branch on memory that was never validly set up.

The practical consequence is memory corruption inside the PHP worker, below the application layer. The advisory states that multiple OOM strategies can consistently trigger the condition and lead to remote code execution. This is a description of the defect, not an exploit recipe.

Who is exposed

Any PHP installation that serves web requests is in scope, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project singles out Apache mod_php because an unauthenticated request can trigger the demonstrated attack before any application code runs.

Website code, CMS versions and plugins are not the relevant boundary here. A fully patched application can still be exposed if the PHP runtime underneath it is unpatched. Container images, appliances and managed hosting need their own verification because the PHP binary may be supplied by the platform rather than the site owner.

Fix and interim controls

The complete fix is a PHP release containing the patch: 8.2.35, 8.3.36, 8.4.27 or 8.5.12. Distributions and LTS vendors received patches in advance and may backport them. A backported package may keep the old upstream version string, so the package changelog and vendor advisory matter more than the number reported by a version scanner.

If an immediate update is impossible, PHP lists interim controls: set memory_limit=-1 in a way applications cannot override; reduce post_max_size (8M where uploads are not required, 32M where they are); enforce decoded request-size, field-count, multipart-part, header-count and nesting limits at the proxy; and use container or cgroup memory limits. PHP explicitly warns against using RLIMIT_AS or RLIMIT_DATA as the boundary because they can cause the vulnerable allocation failure.

These controls reduce specific attack paths. They do not make an installation safe. The same page also says update is the only complete mitigation.

Why a WAF, backup or non-root user does not close the issue

Cloudflare deployed managed WAF rules about nine hours before public disclosure and reported attack traffic. That is useful time-buying, but Cloudflare itself says customers should patch even with WAF protection. A rule match can be evaded by payload variation, and a missed request reaches PHP before the application sees it.

Backups restore availability after an incident; they do not prevent code execution. Running PHP as a non-root user limits what a successful attacker can do next, but it does not turn remote code execution into a non-event. Each of these controls addresses a different part of the risk.

Verification status

The defect, affected branches and fixed releases are confirmed by the PHP project's advisory, the GitHub security advisories and the release changelog. The two CVEs are tracked separately by NVD. Exploitation attempts are reported by multiple security vendors, but this site does not convert attempt counts into a claim that any particular site was compromised.

The CISA KEV catalog version downloaded for this page did not list either CVE. That is a statement about one catalog at one time, not a finding that exploitation never happened.

What to do

• Verify the serving runtime and the installed fix — useful for any runtime update, not only PHP.
• Interim controls and their limits — how to buy time without claiming a fix.
• Read the advisory labels correctly — CVSS versions, KEV, PoC and exploitation.

Sources

Last verified 22 October 2026, 16:45 UTC. A statement that no evidence was found in checked sources is not a statement that an event never occurred.