Two critical PHP runtime flaws, what is fixed, and what to check. Status as of October 22, 2026.
The short answer. PHP2Shell is the name for two critical PHP runtime flaws, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution on servers that handle web requests. PHP released fixes on October 21, 2026. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor backport), then check for signs of compromise. This story is moving fast, so the status below is as of October 22, 2026.
PHP2Shell covers two memory-handling flaws in the PHP engine itself, not in WordPress, a plugin or any single application. Both are rated critical (CVSS v4.0 score 9.2). Because the flaw is in the runtime that processes web requests, anything running on a vulnerable PHP can be exposed, including WordPress, Drupal, Joomla and custom applications.
The impact is unauthenticated remote code execution with the privileges of the web worker. According to Huntress, which summarises Wiz's research, a separate memory-disclosure path could also expose passwords, tokens, API keys and certificates.
| Date (2026) | Event |
|---|---|
| October 17 | Amazon's honeypot recorded a PHP2Shell exploitation attempt, four days before public disclosure |
| October 20 | Details leaked before coordinated disclosure and before patches existed; researchers confirmed the flaws were real |
| October 21 | PHP released fixed versions earlier than the original embargo; technical write-ups followed, and Wiz demonstrated unauthenticated RCE against WordPress, Drupal and Joomla |
| October 21 | Huntress reported no in-the-wild exploitation on its partners' systems at 4:30 pm ET, while noting others reported attacks emerging |
| October 22 | Cloudflare had deployed initial WAF rules; Palo Alto Networks said all PAN-OS and Panorama versions were affected with no fixed release yet; Searchlight Cyber released an open-source scanner |
Treat the exploitation picture as unsettled. A working exploit exists, one pre-disclosure attempt was recorded, and reports of wider attacks were still developing. Check the sources below for updates.
| PHP branch | Fixed version |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
PHP 8.1 and earlier are no longer supported upstream and are affected. PHP provided minimal source backports for 7.4, 8.0 and 8.1 for teams that build from source or lack a long-term-support vendor. Linux distributions and LTS vendors received patches before publication, so check your vendor's package rather than judging by version number.
PHP says every installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. mod_php is the most exposed: a demonstrated exploit lets a single unauthenticated request trigger the flaw before any application code runs.
Do not forget bundled PHP. Control panels, appliances, containers and vendor products often ship their own PHP. Your CMS version does not tell you which runtime serves the request.
session.upload_progress.enabled = Off in php.ini mitigates the known abuse cases (a restart may be needed). Treat it as a stopgap and plan an upgrade.Huntress's detection guidance centres on one signal: a PHP worker (php-fpm, php-cgi, httpd, apache2) starting processes it normally never starts.
sh, bash, cmd.exe, powershell.exe, python or perl.curl, wget, nc or certutil.exe./dev/tcp/, fsockopen or mkfifo.whoami, id or uname -a.If you find any of these, isolate the server and preserve the web server and PHP logs before rebuilding. A patch closes the flaw. It does not remove a webshell that was planted earlier. For response planning, see our AI security incident response guide and the signs an application is compromised.
Many AI products sit on ordinary web stacks: a WordPress site with a chatbot plugin, an admin dashboard, an API gateway or a vendor appliance. If the runtime underneath is taken over, no prompt-level control, guardrail or model hardening helps. The attacker is inside the server, with access to whatever the process can read, which often includes API keys for your model provider.
That is the same lesson as in agent security: protect the layer beneath the model, keep credentials narrowly scoped, and limit what a compromised process can reach. See AI agent credential security. HexTyx tests AI application behaviour, such as prompt injection and tool abuse. It does not scan your PHP version or patch level, so use your vulnerability scanner or hosting provider for that.
Run the free playground scanner against your AI application and see what an attacker could make it do.