CVE-2026-109618 vs CVE-2026-109619: The Two PHP2Shell Flaws Explained

CVE-2026-109618 and CVE-2026-109619 are the two critical PHP flaws known together as PHP2Shell. Both can let an attacker run code on your web server without logging in, and PHP fixed both on October 21, 2026. They share one trigger but break in different ways, and your server setup decides which one is the real threat. This guide compares the two side by side, then covers affected versions and how to patch and verify.

What is PHP2Shell?

The shared name for two critical PHP core flaws, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution.

What is CVE-2026-109618?

A memory corruption flaw. A crafted request forces an out-of-memory error, and PHP's cleanup then trusts half-built request data.

What is CVE-2026-109619?

A use-after-free flaw. Request state survives after its memory is freed, and a later request on the same worker reuses it.

Which is more dangerous?

Both are rated 9.2. CVE-2026-109618 is easiest on Apache mod_php; CVE-2026-109619 also reaches PHP-FPM and can leak memory.

Key Takeaways

• Both flaws are rated CVSS v4.0 9.2 and allow code execution without authentication. They are flaws in PHP itself, not in any one application.
• They share a trigger (a crafted request that exhausts memory) but differ in root cause: 109618 is memory corruption, 109619 is a use-after-free.
• Apache mod_php carries the highest risk. PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed setups are also affected.
• CVE-2026-109619 is the one that reaches PHP-FPM and can also leak server memory.
• Patching is the only complete fix. WAF rules and php.ini changes only buy time.

CVE-2026-109618 vs CVE-2026-109619

The two flaws look similar at a glance, but they break PHP in different places and threaten different server setups. Here is how they compare across ten dimensions that actually change what you do.

1. Bug Type

This is the core difference. CVE-2026-109618 is a memory corruption flaw: an out-of-memory error interrupts PHP mid-request, and cleanup code then trusts request data that was only half built. CVE-2026-109619 is a use-after-free: request state lives on after its memory has been freed, and a later request on the same worker picks it up. Different faults, same end result of attacker-controlled memory.

2. Shared Trigger

Neither flaw is a classic injection where a payload sneaks past a parser. Both start the same way: a crafted request that forces PHP to run out of memory at a precise moment. From there the two bugs diverge. That shared root is why PHP shipped one advisory and one set of patches for both, and why fixing one without the other was never an option. Fast-moving flaws like this one, where a vulnerability gets exploited within days of disclosure, leave no time to triage two bugs separately.

3. Where It Was Validated

Researchers confirmed CVE-2026-109618 against Apache mod_php, where request cleanup runs even after a failed startup and reaches the corrupted data. CVE-2026-109619 was validated on both mod_php and PHP-FPM, through the session upload progress path. If you want to know which bug threatens your stack, this row matters more than the CVE number.

4. Server Setup Exposure

Apache mod_php is the highest-risk setup for both flaws, partly because per-directory .htaccess settings apply before request startup. PHP-FPM is affected mainly through CVE-2026-109619. php-cgi, FrankenPHP, and LiteSpeed (LSAPI) setups are also in scope. In short, 109618 is mostly a mod_php problem, while 109619 is the one that follows you onto FPM. The lesson echoes why attackers keep finding internet-exposed systems: the setup you forgot about is the one that gets hit.

5. Extra Impact Beyond Code Execution

Both flaws can lead to remote code execution, but CVE-2026-109619 carries a second danger. Its session path can return freed worker memory to the client, a Heartbleed-style leak that can expose session tokens, API keys, or other secrets from earlier requests. That makes any pre-patch exposure a reason to rotate credentials, not just patch. CVE-2026-109618 does not have this disclosure angle.

6. Severity Rating

Here the two are identical: both carry a CVSS v4.0 score of 9.2, rated critical. Some vendors scored them differently for their own stacks, because exploitability depends on the setup, but PHP's official rating treats them as equally severe. The matching score is a reminder that neither one is the "lesser" bug you can safely defer, the same trap teams fall into when they let medium alerts sit in the queue.

7. Ease of Exploitation

CVE-2026-109618 is the more straightforward of the two to reach on mod_php, because the corruption happens during request startup before any application code runs. CVE-2026-109619 needs a second request on a surviving worker, so it takes more steps, but that extra complexity is exactly what lets it reach PHP-FPM, where 109618 usually can't. Neither should be treated as hard to exploit.

8. Partial Mitigations

The stopgaps differ by flaw. For CVE-2026-109618, PHP suggested enforcing memory_limit=-1 with a low post_max_size. For CVE-2026-109619, the levers are session.upload_progress.enabled=0 and, on PHP 8.5, fatal_error_backtraces=0. PHP is clear that each of these only reduces exposure, and none makes a server safe on its own. A full penetration test is how you confirm whether a mitigation actually holds.

9. Detection Signals

Because the trigger is memory pressure rather than a recognizable string, signature matching is weak for both. Look instead for shared behavioral signs: multipart requests with empty filenames and deeply nested field names, and bursts of out-of-memory errors. CVE-2026-109619 adds its own tell, repeated requests carrying PHP_SESSION_UPLOAD_PROGRESS with no file part, plus high-entropy data in PHPSESSID response cookies from the memory leak.

10. The Fix

This is where the two converge again. One PHP update closes both: 8.2.35, 8.3.36, 8.4.27, or 8.5.12. There is no complete workaround for either, and PHP's advisory calls updating the only safe choice. Whichever flaw worries you more, the action is the same, which is why the rest of this guide treats remediation as a single job. Patching fast matters, because some flaws are exploited within days of a patch.

Also Read: JFrog Artifactory Vulnerability

Affected PHP Versions and Exploitation Risk

Both CVEs are fixed in the same releases, so this table covers them together.

Distribution packages may keep the old version number, so check your vendor's advisory for the CVE IDs rather than the version string alone. PHP says every installation serving web requests is affected, with risk varying by setup: Apache mod_php is highest, PHP-FPM is confirmed through the CVE-2026-109619 path, and LiteSpeed is likely but unvalidated. Don't forget appliances. Cisco, OPNsense, pfSense, and Palo Alto Networks have published bulletins.

Details leaked before the coordinated release, and Amazon's MadPot honeypots recorded an exploit attempt on October 17, 2026, four days before disclosure. Keep one distinction clear: these reports show exploit requests reaching servers, not successful compromise. Amazon said it was unclear whether any attempt would have succeeded, and SANS called the published proof of concept unreliable. Treat an attempt in your logs as a reason to check, not a verdict.

How to Fix and Mitigate PHP2Shell

The steps below close both CVEs at once. Work top to bottom, starting with internet-facing hosts.

1. Upgrade to a patched PHP version. Install a fixed release or your distribution's patched package, then restart every PHP-FPM pool and Apache process. A patched binary does nothing while old workers keep running. On PHP 8.1 or older, use vendor LTS packages or PHP's source backports, and plan the upgrade. PHP's own release announcement is blunt: updating is the only safe choice.
2. Apply temporary config mitigations if you can't patch yet. Set these in php.ini or the FPM pool config, not ini_set() or .user.ini, then restart workers: session.upload_progress.enabled=0 closes the confirmed CVE-2026-109619 session path; fatal_error_backtraces=0 on PHP 8.5; and memory_limit=-1, enforced so nothing overrides it, with a low post_max_size. If your app takes no file uploads, block multipart/form-data requests at the front end.
3. Use a WAF as a stopgap, not a fix. Cloudflare and Imunify360 have shipped rules for known PHP2Shell patterns, but attackers have modified payloads to bypass them. The bug lives in PHP, so a WAF buys time while you patch, nothing more.
4. Verify the patch actually took. Confirm the version the web server loads, not just php -v, and check that worker start times are later than the update. For PHP-FPM and containers, confirm pools were reloaded and images rebuilt, not just pulled.
5. Check for suspicious activity. Search web logs from October 17 onward for POST requests containing PHP_SESSION_UPLOAD_PROGRESS, multipart uploads with very long filenames, and bursts of out-of-memory errors. Look for new PHP files in upload folders, shells spawned by the web server user, and new cron entries. A clean log is not proof of safety.
6. Rotate exposed credentials. Because CVE-2026-109619 can leak memory, treat any pre-patch internet exposure as a credential-rotation event: session secrets, API keys, and TLS private keys on affected hosts.

How OraSec Can Help

The hard part of PHP2Shell isn't the patch; it's knowing every place PHP is exposed and confirming each one is actually fixed. OraSec's vulnerability assessment and penetration testing maps every PHP runtime you expose, including forgotten sites, admin panels, and appliances, then confirms patched hosts run fixed builds, workers were restarted, and any temporary mitigations hold. If you had internet-facing exposure before patching, our web application security testing shows what an attacker could actually reach from a compromised PHP host, so you know whether a logged exploit attempt went anywhere. All testing is manual, and findings come with proof and a clear fix. The team's own research has produced published CVEs (CVE-2025-50847 through CVE-2025-50850).

Conclusion

CVE-2026-109618 and CVE-2026-109619 are two different bugs with one name, one trigger, and one fix. The distinction that matters in practice is reach: 109618 is mostly a mod_php problem, while 109619 follows you onto PHP-FPM and can leak memory on top of code execution. But you don't have to pick which to worry about. Patch to PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12, restart every worker, review logs back to October 17, and rotate anything that may have leaked. Treat exploit attempts as a reason to look, not proof of a breach.

Frequently Asked Questions

What is the difference between CVE-2026-109618 and CVE-2026-109619?

CVE-2026-109618 is memory corruption from interrupted out-of-memory handling, mainly on mod_php. CVE-2026-109619 is a use-after-free that also reaches PHP-FPM and can leak memory.

Do I need to patch both?

Yes, but one update does it. PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 fix both flaws at once.

Does PHP2Shell affect WordPress?

Yes, if the server runs an unpatched PHP version. The flaws are in PHP itself, so WordPress updates and security plugins don't fix them.

Is PHP-FPM vulnerable?

Yes. It's affected mainly through CVE-2026-109619's session path. Apache mod_php still carries the highest risk.

Can a WAF prevent PHP2Shell exploitation?

Not reliably. WAF rules block known patterns, but attackers have modified payloads to bypass them. Patching PHP remains essential.

Are PHP2Shell exploits being used in the wild?

Exploit attempts have been seen since October 17, 2026. Public reports so far show attempts, not confirmed compromises.