As of 27 October 2026, PHP2Shell is a known-exploited problem, not a theoretical one. CISA added CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities (KEV) catalog on 26 October, with a due date of 29 October. Last week's roundup said CISA had not observed exploitation. That changed. The fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP 8.1 and older get no release from the PHP project. A KEV entry confirms exploitation in the wild. It doesn't tell you who is doing it or how, so don't wait for that detail before you act.
What changed on 26 October
The CISA catalog lists both entries under PHP Group / PHP: CVE-2026-109618 as "PHP Memory Corruption Vulnerability" and CVE-2026-109619 as "PHP Stale Internal Request-State Vulnerability". Both were added on 2026-10-26 with a due date of 2026-10-29, and the required action reads "Apply mitigations in accordance with vendor instructions."
Earlier in the week the picture was different. CISA's alert, as our roundup of 19 October reported it, said CISA had not observed exploitation as of publication. The current version, revised 26 October, no longer carries that sentence.
The 29 October due date comes from CISA's Binding Operational Directive 26-04, which applies to what it calls Federal Civilian Executive Branch agencies. A private company isn't bound by it. Our judgment: use it as your benchmark anyway, because exploitation is confirmed and the patches have been out since 21 October.
Which of your systems count
PHP's security advisory says the exposure covers "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." The project rates the risk highest for mod_php, where it has a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.
The two bugs, per php.net: CVE-2026-109618 is an out-of-memory handling flaw that can interrupt PHP while internal request data is only partially initialised. CVE-2026-109619 leaves request state alive after its backing memory is freed, so a later request on the same worker may use it.
How to patch PHP2Shell in 72 hours
1. Name one owner and a deadline
Done means one named person per segment, with a date. Split the estate into in-house applications, agency-built sites, vendor products and containers, and give each segment an owner today. This is the real decision in the whole exercise. An estate with no owner is the finding, and it's the one that costs you if the answer to "who patches the marketing site?" is a shrug.
2. Inventory every PHP you run
Done means a list of systems with PHP version and server type (mod_php or FPM) next to each. CISA's alert tells organisations to "identify and inventory systems running any version of PHP across your organization," and warns that PHP is often a component of other software, so prevalence may not be directly observable.
That last point is the hard part. Our suggested places to look, as judgment drawn from CISA's warning: CMS installs (WordPress, Drupal, Joomla), sites an agency built years ago, vendor products with a PHP admin panel or portal, container base images and managed runtimes. Ask each agency and host in writing which PHP version and which server API they run. A written answer is evidence. A phone call isn't.
3. Patch internet-facing systems first
Done means the fixed version is running, not just installed. CISA says to "apply the patch immediately, prioritizing internet-facing systems." The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Per php.net, Linux distributions and LTS vendors received patches in advance, so check your vendor's packages before building anything yourself. In our judgment, restart PHP workers so the new binary is what serves requests. Our note on patching a security release by exposure order covers the sequencing logic for a different product.
4. Rebuild and redeploy containers and managed runtimes
Done means new images are deployed and old ones are gone. Google Cloud's release notes for 24 October say App Engine, Cloud Run and Cloud Run functions were rebuilt with 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and tell customers: "Take immediate protective action by rebuilding and redeploying your resources with updated dependencies."
AWS's security bulletin 2026-143-AWS is specific about who does what:
- Lambda has no managed PHP runtime, so custom runtimes and container images need updating and redeploying by you.
- Elastic Beanstalk environments without Managed Platform Updates need a platform version update.
- AWS says it cannot update running Lightsail instances in place; you launch new ones from updated blueprints.
- Amazon Linux needs the updated packages applied.
5. If you cannot patch today, reduce exposure and watch
Done means the mitigations are set, workers restarted, and someone is looking at logs. Be clear about what these buy you: php.net says its measures "reduce exposure to specific attack paths but do not make an installation safe."
The php.net settings:
- Set
memory_limit=-1in a way applications can't override, such asphp_admin_value. - Set
post_max_sizeto 8M (32M if you accept uploads), withupload_max_filesizebelow it. - Set
session.upload_progress.enabled=0and restart every worker. Don't set it throughini_set()or.user.ini. - On PHP 8.5, set
fatal_error_backtraces=0. - Don't use
RLIMIT_ASorRLIMIT_DATA, php.net warns.
CISA adds that a web application firewall "may provide some protection," and says to monitor for suspicious activity, "including PHP worker processes launching shells or downloading tools." It also posted a SIGMA detection rule on 23 October. If you can't do any of this, see the section on PHP 8.1 and older below.
6. Confirm and record
Done means running versions are checked after the restart and the evidence is saved. Check the version the web server actually runs: php-fpm -v (or your distro's versioned php-fpm binary), or phpinfo() served through the same web path. php -v shows only the command-line binary. Keep the output with the date. php.net also updated its Windows builds on 26 October (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) to fix the Brotli flaw CVE-2026-111497.
If a system was internet-facing and unpatched from 21 October onward, treat it as possibly compromised and review it. That's our judgment, not a CISA instruction, but with exploitation confirmed it's the safer default.
What to do with PHP 8.1 and older
Here the two primary sources read differently, and you should see both.
PHP's own advisory says "PHP 8.1 and older no longer receive updates from the PHP project." It adds that some distributions and LTS vendors provide backported fixes, so you should contact your vendor, or upgrade. The security team also provided minimal source backports for 7.4, 8.0 and 8.1, for people building from source or without LTS vendor access.
CISA's guidance is blunter: if you can't update immediately, or run PHP 8.1 or earlier, take PHP-based systems offline until they can be patched or updated.
The two sources differ. AWS's bulletin says no upstream fix was released for 5.4 to 8.1 and those branches have no planned fix. "Migration to a supported branch is required." Ask your vendor which applies to your build.
| Option | What it means | What to get in writing |
|---|---|---|
| Upgrade to 8.4 or 8.5 | Move to a branch the PHP project still patches | Test plan and a date from the owner |
| Buy a vendor or LTS backport | Your distribution or vendor ships the fix for your branch | The vendor's confirmation that it covers both CVEs |
| Take it offline | Follow CISA's guidance until patched | Who approves the outage and who restores service |
We haven't put costs in that table, because we have no sourced figures. Ask for quotes.
One more date to plan against. PHP 8.2 security support ends on 31 December 2026, as the PHP version and support-date table in our guide to hiring PHP developers shows. Patching to 8.2.35 buys you two months, not a strategy.
The related CVE-2026-115560
On 23 October php.net published an informational advisory for CVE-2026-115560. It suggests setting session.upload_progress.enabled=0 until the next regular bugfix release, "to fully protect from an unlikely RCE vector." The issue only occurs if an application sets session.serialize_handler to php_binary or php_serialize, then switches to php at runtime with ini_set() before session_start(), with upload progress enabled. There's no fixed version yet, and the full advisory comes with the next release. If you already applied that setting for CVE-2026-109619, keep it.
What this means for who owns PHP and the upgrade budget
You have one decision to make by 29 October: who owns PHP across the company. If you can't name that person for in-house apps, agency sites and vendor products, you've found the actual problem. CISA's inventory instruction and its note that PHP often hides inside other software make this an ownership question before it's a patching one.
The second decision is money. PHP 8.1 and older receive nothing from the PHP project, AWS says migration is required, and 8.2 loses security support on 31 December. Putting an upgrade budget behind that now beats buying a vendor backport every time the next advisory lands.
For outsourced sites, patching is also a contract question. Check who is obliged to apply security updates, and get the answer in writing. For where this fits among the other language and platform changes you're tracking, start with Platform and language release notes: what breaks and what to fix. If one of your branches is already past its end of life, what to do when a language branch reaches end of life shows the same decision on Python.
FAQ
What is the PHP2Shell flaw?
PHP2Shell is the name attached to two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, fixed in PHP's 21 October security release. One is an out-of-memory handling flaw that can leave request data partially initialised. The other lets request state survive after its memory is freed. CISA added both to its KEV catalog on 26 October, which means exploitation in the wild is confirmed.
Which PHP versions fix it and which are vulnerable?
The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The php.net advisory doesn't list affected versions. What it does say is that PHP 8.1 and older get no updates from the PHP project, though some distributions and LTS vendors backport fixes.
How do I patch the PHP vulnerability?
Inventory your PHP, patch internet-facing systems first, restart workers, and rebuild containers and managed runtimes. Steps 1 to 6 above cover the order. If you can't patch yet, apply php.net's partial mitigations and watch for PHP workers launching shells.
Do I need to act if I only run WordPress or Laravel?
Yes. The advisory covers all PHP installations serving web requests, whatever application runs on top. You patch the PHP underneath, through your host, image or package manager, not the CMS or framework.
Is the 29 October deadline binding on my company?
The due date comes from CISA's Binding Operational Directive 26-04, which applies to what it calls Federal Civilian Executive Branch agencies. For everyone else it's a benchmark, and our judgment is to use it as your own deadline.
Sources
- CISA: Critical Vulnerabilities in PHP Require Immediate Patching
- PHP: news archive 2026, security advisory 21 October and informational advisory 23 October
- CISA: Known Exploited Vulnerabilities Catalog
- CISA: BOD 26-04, Prioritizing security updates based on risk
- Google Cloud: release notes
- AWS: Security bulletin 2026-143-AWS, PHP web runtimes