PHP2Shell Vulnerability

PHP2Shell is a pair of critical PHP runtime vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that let an unauthenticated attacker run code on a web server with crafted HTTP requests. Both are rated CVSS v4.0 9.2. The PHP project fixed them on October 21, 2026, in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.

The ReversingLabs Research Team has analyzed both vulnerabilities, mapped which PHP releases are affected, and added PHP2Shell detection to Spectra Assure so affected PHP components can be found inside compiled software packages. This entry covers what we found and how to remediate.

The name says it all: PHP in, shell out. The flaws sit in the PHP engine, not in a framework or plugin. Our analysis shows that even a minimal "Hello World" app running on an affected PHP build can be exposed.

TL;DR

• What: Memory-safety flaws in how PHP recovers from fatal and out-of-memory errors mid-request.
• Impact: Unauthenticated remote code execution, plus remote leaks of server memory.
• Reach: Every PHP release from 5.4 (2012) onward is affected by at least one of the two flaws. PHP powers an estimated 70% of websites.
• Proven targets: Unauthenticated code execution works against default WordPress, Drupal, and Joomla installs.
• Fix: Upgrade PHP and restart every worker. Configuration changes only narrow known paths.
• Hard part: Finding PHP you don't know you run, inside vendor apps, appliances, and container images.

• PHP2Shell lives in the PHP engine. Updating WordPress, Drupal, or a plugin does not fix it; only a patched PHP build does.
• No login and no special app code are required. Reaching the server over the network is enough.
• Our team confirmed the bug class reaches back more than a decade, to PHP 5.4.
• PHP 7.3 and older get no fix at all, and 7.4 through 8.1 only have source backports.
• The largest blind spot is PHP embedded in third-party software that security teams can't inspect or patch themselves.
• A version string is not proof. Vendors may backport fixes without changing it, so verify with evidence from the software itself.

PHP2Shell is new, but the code it lives in is not. PHP has powered the web since 1995, and the vulnerable error-handling paths date back to PHP 5.4, released in 2012. They sat in production for more than a decade.

A long line of PHP remote code execution bugs

Our research team sees PHP2Shell as the latest in a recurring pattern: a flaw in how PHP receives and processes requests, not in application code, turns into server takeover at scale.

PHP2Shell timeline

The flaws were found independently by researchers at Calif and Wiz. About 81 days passed between first discovery and the patch, and working exploits against major CMSs existed within two days of the second team's discovery.

Both flaws share one root cause: PHP does not clean up safely when a request dies from a fatal or out-of-memory error. Internal state is left half-built or pointing at memory that has already been freed, and the next request handled by the same worker trusts it.

The attack, step by step

1. The attacker sends a normal-looking HTTP request to any PHP endpoint. No account or prior access is needed.
2. The request is shaped, often a large or unusual multipart upload, to push PHP into an out-of-memory or fatal error mid-request.
3. PHP's cleanup leaves dangling internal state behind in the worker process.
4. Follow-up requests to the same worker reuse that state, letting the attacker read leftover memory or corrupt it.
5. Corrupted memory becomes code execution, which typically becomes a web shell for data theft, ransomware, or lateral movement.

Where risk is highest

• Default CMS installs: unauthenticated RCE has been demonstrated on the latest official WordPress and Drupal container images through both CVEs, and on Joomla through CVE-2026-109618.
• Apache with mod_php: exploitation can trigger before any application code runs.
• Every PHP server interface: PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed are all in scope.
• Session upload progress: enabled by default and a confirmed attack path. Turning it off narrows exposure but does not fix the flaw.

Signs of exploitation to look for

• Unusual multipart requests followed by PHP memory-limit errors
• Bursts of HTTP 500 responses from PHP endpoints
• Unusually large or malformed PHPSESSID cookies
• Unexplained PHP worker crashes or restarts
• New web shells, cron jobs, or accounts on PHP hosts

Attackers are already mutating payloads to slip past web application firewall rules, so treat WAF coverage as a stopgap, not a fix.

PHP2Shell is the clearest sign yet that AI has changed the speed of vulnerability discovery. Two independent teams found the same decade-old flaws within 18 days of each other, both using frontier AI models.

• AI found the bugs. The flaws surfaced during AI-assisted audits of PHP's source code, using models including GPT-5.6 Sol and Gemini 4 Argon.
• AI built the exploits. The same models helped turn the bugs into working, unauthenticated exploits for major CMSs in days, not months.
• AI validated the fix. Models were also used for attack detection and patch validation.
• Experts still steered. Deep knowledge of PHP's internals decided where the models looked and which findings were real.

What this means for defenders

The tools that audited PHP can be pointed at any widely deployed runtime, parser, or library. Old, trusted code is now being re-read at machine speed, and the time from bug to exploit is shrinking.

Our research team's view: defenders can't wait for a vendor bulletin to learn what's inside their software. They need an inventory of the components inside critical systems before the next disclosure, so the next AI-found flaw is a lookup, not an investigation.

Patching the PHP servers you manage is the easy part. The harder question is whether your inventory is complete.

Enterprises run commercial software they don't build: digital banking platforms, file-transfer tools, network appliances, admin consoles, and virtual appliances. Many ship with an embedded PHP runtime that never appears in internal dependency scans. Because PHP2Shell needs no special application code, any embedded PHP that serves web requests is a candidate. Those products can only be fixed when the vendor rebuilds, tests, and ships a new release.

In our analysis of software packages, two issues come up again and again:

• Version strings mislead. Vendors often backport fixes without changing the PHP version number. An "old" version may be patched, while an identical version in another product may not be.
• Presence is not exploitability. PHP inside a package doesn't automatically mean a reachable, vulnerable execution path.

Vendor advisories help, but they are claims. Independent analysis of the software itself gives you the evidence to judge risk and verify the fix. For the full response playbook, read our companion piece, PHP2Shell: What security teams need to know.

The ReversingLabs Research Team recommends five steps:

1. Inventory PHP everywhere, including vendor applications, appliances, containers, and images. Record version, vendor, location, and whether it serves web requests.
2. Patch and restart. Upgrade to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, then restart every PHP worker so no process keeps running old code. For vendor software, ask for evidence of a backported fix.
3. Prioritize by exposure and business impact. Internet-facing, unpatched PHP behind critical services comes first.
4. Engage vendors with specifics. Bring component, version, and finding evidence, not a generic "are you affected?"
5. Mitigate, hunt, then verify. Where patching must wait, disable session upload progress, cap request sizes, and keep WAF rules on. Check logs for the signs of exploitation above. Then confirm the fix landed.

Can't see inside your vendor software? ReversingLabs is offering PHP2Shell Exposure Assessments. Using Spectra Assure's new PHP2Shell detection, our team inspects selected third-party software packages and reports embedded PHP components and versions, findings tied to CVE-2026-109618 and CVE-2026-109619, and which packages need investigation or vendor remediation.

Request a PHP2Shell Exposure Assessment →

Use this table to check a PHP version. Run php -v on the server, or check the base image tag in your Dockerfile.

Our research team expects PHP2Shell to mark the start of a pattern, not a one-off.

• More AI-found bugs in foundational code. If AI can find decade-old flaws in PHP, it can do the same to other runtimes, parsers, and libraries that everything else is built on.
• Days, not months, from bug to exploit. Working CMS exploits existed within two days of discovery, and leaked details turned into attack traffic within a day.
• Follow-on variants. More variants of these bugs exist, tracked and untracked, and a related session issue (CVE-2026-115560) was flagged two days after the patch. Expect more research into the same code.
• A long tail of unsupported PHP. PHP 8.1 and older are out of support, and PHP 8.2 reaches end of life on December 31, 2026. Embedded runtimes in vendor products will lag for months.
• Third-party software as the main exposure. The next critical runtime flaw will again be easiest to fix where you own the code, and hardest where you don't.

The organizations that respond fastest will be those that can already answer, with evidence, "Which of our critical software contains this component?"

• What is PHP2Shell?

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two critical PHP engine vulnerabilities that allow unauthenticated remote code execution and remote memory leaks.

• Which PHP versions are affected?

Every release from PHP 5.4 onward, up to the fixed releases: 8.2.35, 8.3.36, 8.4.27, and 8.5.12. See the version table above.

• Does updating WordPress, Drupal, or my plugins fix it?

No. The flaws are in the PHP engine, so you must update PHP itself and restart its workers.

• Do I need a vulnerable plugin or custom code to be exposed?

No. Even a minimal "Hello World" PHP app on an affected version can be vulnerable.

• Is PHP2Shell being exploited?

Working exploit code is circulating and attack traffic has been reported. Treat unpatched, internet-facing PHP as urgent.

• Is there a workaround?

Disabling session upload progress, capping request sizes, and WAF rules reduce exposure. None of them is a complete fix; updating is the only safe choice.

• Was PHP2Shell found by AI?

Yes. Two research teams found it independently using frontier AI models, with human experts guiding the work.

• How do I know if third-party software contains vulnerable PHP?

Ask vendors for specific evidence, and verify it with independent analysis. The ReversingLabs PHP2Shell Exposure Assessment identifies embedded PHP components and related findings in selected packages.