PHP2Shell: What Teams Need to Know About CVE-2026-109618 and CVE-2026-109619

PHP moved fast with a fix, and upgrading is the right goal. But legacy versions, vendor appliances and change-frozen systems mean many teams can’t get there this week. Here’s how to reduce exposure until they can.

The Short Version

On October 21, 2026, the PHP project released emergency fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. Both are rated CVSS 9.2 and let an unauthenticated attacker run code on a server using crafted web requests. Details leaked before the patch, and exploitation has been reported in the wild.

The PHP project did an excellent job getting fixes out quickly, and the advice everyone is giving is the right advice: upgrade. But in most enterprises, “upgrade everything now” isn’t realistic. Some systems run PHP versions with no official fix. Others sit inside vendor appliances you don’t control, or support applications that can’t change without testing.

For those systems, the question isn’t whether to patch. It’s how to stay protected until you can. That takes a plan that covers every scenario: upgrade where you can, mitigate where you can’t, and track the difference. Updating to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 remains the only complete fix.

Remedio customers can deploy automated configuration mitigation that eliminates a known PHP2Shell attack vector on supported systems, while you roll out the update.  Reducing your remediation window without disruption. See “If You Cannot Patch Immediately” below.

What to Do Now

• Today: Find internet-facing PHP and upgrade it. Where you can’t, apply a mitigation and restart every PHP worker. Check exposed systems for signs of compromise.
• This week: Extend the search to internal systems, containers, workstations and vendor products.  Continue monitoring for signs of compromise.
• This quarter: Retire or upgrade PHP 8.1 and older, and plan for PHP 8.2’s end of life on December 31, 2026.

What Happened

PHP announced an out-of-cycle security release on October 20, the same day details of the flaws leaked online. Fixes shipped on October 21, and within a day watchTowr reported exploitation in the wild and Unit 42 counted more than 22.6 million potentially exposed instances.

The Two Vulnerabilities, in Plain Terms

CVE-2026-109618: out-of-memory corruption. If PHP runs out of memory while setting up a request, it can stop partway through, and the cleanup that follows treats half-built data as valid. Researchers have demonstrated multipart (file upload) requests as a trigger.

CVE-2026-109619: stale global state. After certain fatal errors, internal state from one request can outlive its memory. The next request handled by the same PHP worker may use it before it is reset, which is why long-lived workers are the main target.

Both flaws are in the PHP interpreter, so application or CMS updates won’t fix them. On Apache with mod_php, PHP’s highest-risk setup, the demonstrated exploit runs before any application code.

Who Is Affected

Any PHP installation serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

Branch	Vulnerable	Fixed in
PHP 8.5	8.5.11 and earlier	8.5.12
PHP 8.4	8.4.26 and earlier	8.4.27
PHP 8.3	8.3.35 and earlier	8.3.36
PHP 8.2	8.2.34 and earlier	8.2.35
PHP 8.1 and older	All versions	No PHP project release. Some distributions and LTS vendors ship security fixes; PHP also published source backports for 7.4, 8.0 and 8.1

Where PHP Hides

Look beyond your web server list. PHP often arrives inside something else:

• Vendor appliances and products with a web admin console
• Container images built on PHP base images and never rebuilt
• Developer workstations and legacy internal tools

For bundled PHP, ask the vendor directly whether their product is affected and when a fix will ship.

Upgrading

• Supported versions: Update from the PHP downloads page or your distribution’s packages, most of which received the patches in advance.
• Older versions: Check your distribution or LTS vendor for security fixes first. If you build from source, use the backports linked in the PHP security advisory.
• Containers: Rebuild on a fixed base image and redeploy. Updating the host doesn’t change the image.
• Afterward: Restart workers and confirm the running version, not just the installed package.

If You Cannot Patch Immediately

PHP has published interim mitigations for each vulnerability in its security advisory. They reduce exposure to specific attack paths but don’t make a system safe, and the details matter:

• Where you set a value matters. Several settings only work in php.ini, the FPM pool or server configuration, not through ini_set() or .user.ini.
• Restart every worker. A setting a running worker hasn’t loaded isn’t protecting anything.
• Test first. Some measures change application behavior, such as upload progress indicators.

Applied manually across hundreds of systems, these changes are easy to get wrong and hard to verify, so establishing a clear process and tracking will be critical.

Automating the mitigation with Remedio

Remedio now provides a targeted, autonomous protection for supported PHP configurations:

• Identify: Remedio assesses PHP configurations for settings associated with known attack paths.
• Reduce risk: Remedio applies targeted protective settings, reversible at any time.
• Show what remains: Remedio clearly separates systems with a partial mitigation from those running a fixed PHP version, so nothing is marked done before fully remediated..

This protection disables PHP session upload progress, eliminating a known PHP2Shell attack vector. This will allow you to reduce your remediation window without disruption.

Before applying it: Applications that display upload progress may be affected, and reloading the PHP service may briefly interrupt active requests. Start with a small group of systems. 

We’ll continue to evaluate additional mitigations, as we all work through this critical CVE remediation.

Remedio customers seeking assistance with understanding your exposure and building your remediation plan, can reach out to [email protected].

Checking for Signs of Compromise

Because details leaked before the patch, check systems that were exposed before you updated:

• PHP and web server logs for unexplained worker crashes, out-of-memory or fatal errors around unusual requests
• Large or malformed multipart POST requests to endpoints that don’t normally receive uploads
• Unexpected processes spawned by PHP workers, new files in web roots, or unusual outbound connections

If something looks wrong, preserve logs and system state before patching or rebuilding.

Staying Current

We’ll update this post as new information is confirmed. Thanks to the PHP security team for moving so quickly, and to everyone responding this week.

Sources

• PHP Group, Security advisory: Critical remote code execution vulnerabilities, update now, Oct 21, 2026
• PHP Group, GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)

About Author

Matt Rowe

Chief Technology Officer

Remedio's CTO, Matt brings over 20 years of leadership building and scaling secure technology platforms for the likes of Amazon, Synchrony Financial, and GE. Matt is passionate about advancing scalable, outcome-driven cybersecurity for critical systems.