PHP2Shell: patch PHP itself, not just your website

PHP2Shell: patch PHP itself, not just your website

Killswitch Issue #1 opens on the fact that matters for operators: the bug is in the PHP engine that sits under WordPress, Drupal, Joomla and countless custom apps [1]. Severity is Critical, and the briefing is written for SME owners, IT leads, MSPs and GRC teams.

Two critical flaws in the PHP engine let one unauthenticated web request run code on the server [1]. Updating WordPress or a plugin won’t fix them. Updating PHP will. Facts are as of 26 Oct 2026, and this is a defensive briefing: no exploit code, payloads or weaponisation steps.

The flaw is under your website, not in it

On 21 Oct 2026 PHP fixed two flaws that sit underneath almost every PHP website and fire before any of your own code runs [1]. Researchers showed unauthenticated code execution on current WordPress, Drupal and Joomla installs [16][17]. Wiz, one of the teams that found them, says PHP powers 70% of all websites [16]. That is Wiz’s figure, not one Killswitch measured.

CMS and plugin updates don’t help, because the bug is in the runtime your host or IT team installs. If a website, client portal or appliance of yours runs PHP, get a fixed build confirmed this week.

Two CVEs, one fix: update PHP

CVE-2026-109618 (RCE via out-of-memory corruption) and CVE-2026-109619 (RCE via stale global state) are known together as “php2shell” [1][6]. PHP, the CNA, scores both CVSS 4.0 9.2 Critical [5]; NVD scores them CVSS 3.1 9.8 and 8.1 [14][15]. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 [1].

Every PHP installation serving web requests is in scope: mod_php (highest risk, says PHP), PHP-FPM, php-cgi, FrankenPHP and LiteSpeed [1]. For 8.1 and older there is no official release, though PHP published minimal source backports for 7.4, 8.0 and 8.1 [1]. The only full fix is to update: PHP says its interim settings “do not make an installation safe” [1].

Exploit attempts came four days before the fix

Wiz research began on 19 Aug 2026; Wiz reported to PHP on 24 Aug and PHP acknowledged on 21 Sep [16]. On 17 Oct Amazon’s MadPot honeypots logged an exploit attempt, four days before disclosure [20]. PHP gave advance notice on 20 Oct and shipped the fixed releases on 21 Oct, the day the CVE records were published and CISA, ENISA and partners, and NCSC-UK issued alerts [1][2][5][6][10][11].

On 23 Oct CISA added a Sigma rule to its alert [6][8], and PHP flagged a third, unusual-configuration RCE, CVE-2026-115560, to be fixed in the next regular release [2]. On 26 Oct CISA added both php2shell CVEs to KEV, with a federal due date of 29 Oct [6][7]. PHP 8.2 reaches end of life on 31 Dec 2026 [2].

One request breaks the worker; the next one pays

Both bugs follow one pattern. A request is cut short halfway through setup, and what it leaves behind is trusted later. PHP reuses worker processes between requests [18], so leftovers from one request can reach the next: a later request on the same worker touches that stale state before normal initialisation resets it [1].

For 109618, running out of memory interrupts PHP while request data is only partly built; for 109619, a fatal error interrupts PHP before cleanup finishes [1][18]. Researchers turned this into memory disclosure and code execution [3][16], and the attacker gets the web server account’s rights, including secrets in process memory such as passwords, tokens and API keys [16][19]. In our read, that can include database credentials. No vulnerable plugin is needed, which is why patching the CMS alone misses the mark.

Patching the app doesn’t patch PHP

PHP lives between the web server and your application. Patching WordPress, Drupal or a plugin changes the application layer; the flaw is one layer down. That’s why the fix has to come from whoever installs PHP: your host, your IT team, your container image or your appliance vendor.

PHP also hides beyond “the website”. On shared hosting and control panels, the host picks the PHP version. Container images bundle their own PHP; AWS has updated Elastic Beanstalk, Amazon Linux and Lightsail blueprints, but Lambda custom runtimes are the customer’s job [19]. NCSC-NL keeps a list of products with a PHP dependency [12]. Confirm the version that actually serves HTTP: the command-line php -v can differ from PHP-FPM or mod_php.

Is the PHP serving your pages fixed?

You are affected on 8.5.0–8.5.11, 8.4.0–8.4.26, 8.3.0–8.3.35 or 8.2.0–8.2.34 [19]. Treat 8.1 and older as affected too: Calif says the earliest affected path dates to PHP 5.4.0 [17], and NCSC-UK says not to limit discovery to outdated versions [11]. Calif confirmed pre-auth RCE on WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS [17].

Safe, read-only checks (Killswitch check list), only on systems you run or have permission to check: php -v, then the web runtime itself, such as php-fpm -v (or php-fpm8.x -v), because the FPM binary version can differ from the CLI; apachectl -M to see whether Apache loads mod_php; your package manager’s PHP list, remembering that distribution builds can carry the fix under their own version numbers [1][21]; and php -v inside each running container, then rebuild the image. For hosted services and appliances, ask the provider in writing. A hidden X-Powered-By header proves nothing.

Watch the worker, not just the request

Look for POST requests carrying the form field PHP_SESSION_UPLOAD_PROGRESS (Amazon) [20]; unusual multipart requests followed by memory-limit errors or repeated HTTP 500s, malformed PHPSESSID cookies or unexplained worker churn (Wiz) [16]; and PHP worker processes launching shells or downloading tools (CISA) [6]. That last one is the strongest sign an attack worked.

Check web server access logs, PHP and PHP-FPM error logs, WAF logs and process telemetry such as EDR, auditd or osquery. PHP adds that a clean log is not proof of safety [4]. CISA’s Sigma rule is marked “test”, so expect noise, tune it and baseline legitimate shell-outs [8]. Amazon’s published IP addresses belong to shared anonymisation networks, and Amazon says to investigate hits, not block them [20].

Four roles, three horizons

SME owners: today, ask whoever runs your website which PHP version it uses and get the answer in writing [1]; this week, if it is 8.1 or older or nobody knows, agree a fix date or take the site offline. CISA advises taking PHP 8.1-and-older systems offline; CERT-EU says to consider isolating them [6][9]. IT leads: inventory every PHP runtime, internet-facing first [6][11], update to a fixed release, restart every worker [1] and rebuild container images [18].

Where you can’t patch yet, apply PHP’s interim settings and restart every worker, knowing they are not a fix [1]. MSPs: sweep every client estate and hosting node, patch shared hosting first [1][19], check appliances against the NCSC-NL list [12] and hunt logs back to at least 17 Oct [20]. GRC: log both CVEs in the risk register with an owner and due date, and record KEV status as “listed 26 Oct, due 29 Oct” [7]. This quarter, add PHP lifecycle to supplier reviews before 8.2’s end of life [2].

Turn the patch into audit evidence

PHP2Shell tests several NIS2 duties [22]. Article 21(2)(e), vulnerability handling: can you patch a runtime-level critical within days? The evidence is patch tickets with CVE, dates and closure. Article 21(2)(d), supply chain: do hosts, agencies and appliance vendors tell you their PHP status? Article 23: if you find a compromise, is it a significant incident, with a 24-hour early warning?

On the ISO/IEC 27001:2022 side [23], A.5.9 asks whether the asset inventory lists runtimes, not just apps; A.8.8 covers triage and a fix deadline; A.8.9 keeps interim php.ini settings under change control; A.8.15 and A.8.16 ask whether you keep logs from 17 Oct and can see worker-spawned shells; and A.5.19–A.5.22 and A.5.24–A.5.28 cover suppliers and incidents. Whether NIS2 applies depends on your sector, size and national law.

Three lessons, one 30-minute exercise

Three lessons will outlive this bug. Inventory runtimes, not just applications: “WordPress on PHP 8.3 under PHP-FPM, on host X” answers the question, “we run WordPress” doesn’t. End of life is a risk you accept in advance: 8.1 and older get no official fix [1], and 8.2 joins them on 31 Dec 2026 [2]. And a patch isn’t done until the old process is gone: restart every worker [1][4] and rebuild images [18].

The 30-minute tabletop is fictional. Your web host emails that tonight it will move every site on PHP 8.1 or older to 8.3, and nobody knows which PHP your 2021 client portal runs. Who can tell you the version within an hour? What breaks if it jumps to 8.3, and who tests it? If it can’t move, who decides to take it offline and tell customers? What evidence would show the portal wasn’t touched between 17 Oct and the fix?

What we don’t know yet

CISA added both CVEs to KEV on 26 Oct, its signal of active exploitation [6][7]. Amazon reports broad exploitation attempts [20]. Public sources still name no confirmed victims, and Amazon says it is unclear whether any of the pre-disclosure attempts on its honeypots would have succeeded in real-world systems [20]. Earlier, on 23 Oct, CrowdStrike had seen only probing and unsuccessful attempts [18]. Pentest-Tools says Cloudflare and Patchstack reported exploitation, but we haven’t found those reports [21].

Sources conflict on end-of-life branches: the CVE records list only 8.2–8.5 [5], Calif traces the bug to 5.4.0 [17] and AWS says 5.4–8.1 have “no upstream fix” [19], while PHP published source backports for 7.4, 8.0 and 8.1 [1]. For 109618, full RCE was validated on mod_php, with FPM susceptible by source analysis only [3]. Release times differ by source [2][9][10], the reported Hacker News leak is unconfirmed [21], and “70% of all websites” is Wiz’s figure [16].

Turn this issue into owners, dates and evidence

PHP2Shell is a tracking problem as much as a patch: each server, host and appliance needs an owner, a fix date and evidence that it was done. GRCompliance tracks risks, suppliers and evidence against ISO 27001 and NIS2 in one place. Try the live demo at demo.grcompliance.com, or self-host GRCompliance Core free from GitHub.

Subscribe free at killswitch.work to get every Killswitch issue with its slide deck. To go deeper on cloud security and supplier risk, Sectutor has books and kits from the author of the CCSP Excellence books, including the CCSP Kit and Single Point of Failure: Managing Europe’s Dependence on US Technology. Not investment, legal or audit advice.

Next steps

About the author. Emmanuel Aigbehi Walstra is a CISO who also serves as a virtual CISO (vCISO) for several organisations, with 30+ years in cybersecurity, 10,000+ people trained, and author of the CCSP Excellence books.

Sources

1. PHP: Security advisory — critical remote code execution vulnerabilities, update now (21 Oct 2026). www.php.net/archive/2026.php#2026-10-21-5
2. PHP news archive 2026: advance notice (20 Oct), release notes incl. PHP 8.2 end of life (21 Oct), informational advisory on CVE-2026-115560 (23 Oct). www.php.net/archive/2026.php
3. PHP: GHSA-w8hw-w9fx-j79w, CVE-2026-109618 (21 Oct 2026). github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
4. PHP: GHSA-6wmf-4rv5-p3rp, CVE-2026-109619 (21 Oct 2026). github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
5. CVE records CVE-2026-109618 and CVE-2026-109619 (CNA: PHP Group; CISA and Siemens ADP entries). www.cve.org/CVERecord?id=CVE-2026-109618
6. CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21 Oct, revised 26 Oct 2026). www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching
7. CISA Known Exploited Vulnerabilities catalogue, JSON feed (version 2026.10.28). www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
8. CISA Sigma rule CISA_SIGMA_261429 PHP2Shell (modified 23 Oct 2026). github.com/cisagov/SIGMA_Rules/blob/develop/CISA_SIGMA_261429_CVE_2026_109618-109619_PHP2Shell_TLP_CLEAR.yaml
9. CERT-EU Security Advisory 2026-018, v1.2 (23 Oct 2026). www.cert.europa.eu/publications/security-advisories/2026-018/
10. ENISA, CERT-EU, DG CNECT, Europol EC3, CSIRTs Network: joint statement (21 Oct 2026). www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
11. NCSC-UK: Critical security issue affecting PHP (21 Oct, updated 23 Oct 2026). www.ncsc.gov.uk/news/critical-security-issue-affecting-php
12. NCSC-NL: php2shell operational information and affected-software list (updated 26 Oct 2026). github.com/NCSC-NL/php2shell
13. CERT/CC: VU#763488 Memory corruption vulnerabilities in PHP (22 Oct 2026). Further reading; not cited in the text above. kb.cert.org/vuls/id/763488
14. NVD: CVE-2026-109618 (CVSS 3.1 9.8, NIST). nvd.nist.gov/vuln/detail/CVE-2026-109618
15. NVD: CVE-2026-109619 (CVSS 3.1 8.1, NIST). nvd.nist.gov/vuln/detail/CVE-2026-109619
16. Wiz: PHP2Shell research write-up (21 Oct 2026). www.wiz.io/blog/php2shell-php-rce
17. Calif: PHP2Shell, a tale of two PHP remote vulnerabilities. calif.io/php2shell/
18. CrowdStrike: Obstacles to weaponizing PHP2Shell likely constrain immediate exploitation (23 Oct 2026). www.crowdstrike.com/en-us/blog/obstacles-to-weaponizing-php2shell-likely-constrain-exploitation/
19. AWS Security Bulletin 2026-143-AWS: PHP web runtimes (updated 23 Oct 2026). aws.amazon.com/security/security-bulletins/2026-143-aws/
20. AWS Security Blog: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
21. Pentest-Tools: PHP2Shell — what it is, how to detect, how to patch. pentest-tools.com/research/php2shell-rce
22. Directive (EU) 2022/2555 (NIS2), Articles 21 and 23. op.europa.eu/en/publication-detail/-/publication/9b84d482-85bd-11ed-9887-01aa75ed71a1
23. ISO/IEC 27001:2022, Annex A control titles. www.iso.org/standard/27001

All sources accessed 26 Oct 2026; the CISA alert [6], KEV catalogue [7] and Amazon post [20] re-checked 29 Oct 2026. Not legal advice. Killswitch is a defensive briefing: every claim is sourced and there is no exploit code. Lines marked “our read” or “Killswitch recommendation” are our analysis, not source text. Not investment or audit advice either.