PHP2Shell: Two Critical PHP Flaws. Act Now.
On October 21, 2026, the PHP project fixed two critical vulnerabilities in PHP itself. Working exploit code is now publicly available, so the window to act is short. If PHP runs anywhere in your environment, here is what you need to know and do.
What Has Happened
On October 21, 2026, the PHP project released fixes for two flaws in PHP itself, collectively known as PHP2Shell:
- CVE-2026-109618 related to out-of-memory handling
- CVE-2026-109619 related to stale state carried between requests
The PHP project rates both as critical (CVSS v4.0 score of 9.2 out of 10). In affected setups, an attacker could take over a web server remotely without needing to log in. Details of the flaws became public before the fixes were released, which reduced the time available to respond, and working exploit code is now publicly available.
Because the issue sits in PHP rather than in any one application, the fix is a runtime update. The update itself is straightforward. Finding every place PHP runs, and confirming each one is genuinely patched, is where most of the effort lies.
Why This One Is Serious
PHP2Shell sits below your applications, so the usual protections do not apply.
These Flaws Are in PHP, Not Your Code
Well-written applications are still exposed. Secure code does not protect the server underneath it.
Every Common Setup Is at Risk
PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed are all affected. With mod_php, the attack can fire before any application code runs.
PHP Is Everywhere
WordPress, Drupal, Magento, Moodle, many vendor products and internal tools all run on it.
Impacted and Fixed Versions
| PHP Branch | Status | Fixed In |
|---|---|---|
| 8.5 | Supported | 8.5.12 |
| 8.4 | Supported | 8.4.27 |
| 8.3 | Supported | 8.3.36 |
| 8.2 | Supported until December 31, 2026 | 8.2.35 |
| 8.1, 8.0, 7.4 | End of life | Source backports or a vendor fix |
| 7.3 and older | End of life | Vendor-supported builds, or upgrade |
A patched server can look unpatched. On Red Hat, Ubuntu and Debian, fixes are often backported without changing the PHP version string. Confirm status from the package version and your distribution’s security advisory, not from php -v.
Your Response Plan
Patch first. Where you cannot patch today, reduce exposure and set a date to finish the job.
Build a Complete Inventory
Identify every PHP instance, including containers, third-party products, appliances and less visible servers.
Update or Apply the Vendor Fix
Install the fixed release or your operating system vendor’s update wherever one is available. Rebuild containers from patched base images.
Cover End-of-Life Versions
Arrange extended support or a backported fix, and set a dated plan to move to a supported PHP version.
Use Temporary Mitigations Only to Buy Time
If you cannot patch immediately, apply the mitigations in the PHP security advisory: set session.upload_progress.enabled=0, and on PHP 8.5 also set fatal_error_backtraces=0. Make these changes in php.ini or the PHP-FPM pool, not through .user.ini or ini_set(), which take effect too late. They reduce risk but do not replace patching.
Restart and Verify
Restart all PHP workers after any change, then confirm both web server and command-line configurations are covered.
PHP also recommends keeping session.upload_progress.enabled=0, even after patching, until its next bugfix release, to address a related issue (CVE-2026-115560).
| Path | When It Applies | Effort |
|---|---|---|
| Update | Supported versions, 8.2 to 8.5 | Routine |
| Vendor Fix | Older versions where Red Hat, Ubuntu, Debian or a hosting panel has backported the patch | Routine |
| Extended Support or Stopgap | End-of-life versions with no vendor fix | A stopgap you own |
| Upgrade the Application | Any end-of-life version | A project, and the long-term fix |
Every path other than a straight update should end with a dated plan to reach a supported PHP version.
PHP Hides in Many Places
Containers, third-party products, appliances and less visible servers.
Version Checks Can Mislead
Fixed distribution builds keep the old version number.
Settings Can Differ
Command-line and web server configurations are often separate, so checking one does not confirm the other.
Old Versions Have No Standard Fix
PHP 8.1 and earlier no longer receive official releases.
Got You Covered, From Servers to Applications
PHP2Shell needs both infrastructure and application expertise. Our Infrastructure and Digital Engineering teams work together across on-premises and cloud environments, and where we already support your systems, we can start right away.
Exposure Check
Quick and at no cost. Find out whether you are affected, and how urgently.
Request a checkRapid Response
Discover, fix, verify and check for signs of compromise, ending with an evidence pack for your records.
Explore moreLegacy Stabilization
Extended support, hardening and a dated upgrade plan for older PHP versions.
Explore moreModernization
Upgrade to a supported PHP version, with regression tests you can reuse for future patches.
Explore moreOngoing Coverage
Monitoring for runtime vulnerabilities, with patching within an agreed SLA.
Explore moreManaged Services
Application and infrastructure management so future runtime fixes are handled for you.
Explore moreLet’s confirm where you stand.
Reach out to your Jade Global account manager, or fill in the form below and our team will schedule your exposure check.
References
- PHP security advisory, October 21, 2026 (php.net)
- Canadian Centre for Cyber Security, Alert AL26-026
This advisory provides general guidance based on publicly available information as of October 27, 2026. The situation is evolving, and vendor fixes and recommendations may change. Please confirm current status with your operating system or platform vendor’s security advisories. This advisory does not replace an assessment of your specific environment.