On this page
9.2
CVSS v4.0 score for each CVE
2
Critical CVEs, both unauthenticated RCE
4
Supported branches with fixed releases
21 Oct
Patch release and first attack attempts
What happened on 21 October
On Wednesday 21 October 2026 the PHP project shipped emergency security releases for two vulnerabilities that the research community quickly named PHP2Shell. In its release post, the PHP Foundation said plainly: “it is imperative that you update now”.
The release came a day earlier than planned. CVE identifiers leaked online on 20 October with a wrong CVSS score (a 10.0 that was never PHP’s rating), a researcher’s proof-of-concept video was published by mistake that evening, and a container vendor shipped fixed images more than six hours before the coordinated release. PHP moved the release forward to limit the window.
The scale is why this matters. The PHP engine sits under WordPress, Drupal, Joomla, Laravel, Magento and a large share of custom web applications. Wiz Research, one of the teams that reported the bugs, estimates PHP runs about 70% of websites, and in testing it demonstrated unauthenticated code execution against the latest WordPress, Drupal and Joomla container images.
The two vulnerabilities in plain language
Both bugs are memory-safety flaws in how PHP cleans up after a request fails. Neither depends on a bug in your application code.
- CVE-2026-109618
Memory corruption during out-of-memory handling (GHSA-w8hw-w9fx-j79w)- CVE-2026-109619
Stale request state reused after it is freed (GHSA-6wmf-4rv5-p3rp)- Severity
CVSS v4.0 9.2 (Critical) for each- Attack
Remote, unauthenticated, over HTTP- Impact
Code execution as the PHP worker user; memory disclosure- Fixed in
8.5.12, 8.4.27, 8.3.36, 8.2.35
CVE-2026-109618: out-of-memory corruption. When a request hits PHP’s memory_limit at the wrong moment, PHP can abandon the request while some internal data is only half set up, then later treat that data as valid. A crafted multipart request (the format used for forms and file uploads) can exhaust memory even when its size looks within configured limits. According to the PHP Foundation, on Apache with mod_php an unauthenticated request can trigger this before any application code runs, and full code execution was demonstrated with default settings.
CVE-2026-109619: stale state across requests. A fatal error, such as memory exhaustion or an execution timeout, can leave internal state pointing at memory freed at the end of a previous request. The next request handled by the same worker can then use that freed memory. Rapid7’s analysis lists two confirmed paths: fatal-error backtraces on PHP 8.5, where fatal_error_backtraces is on by default, and session upload progress, which is enabled by default and works even if the application never calls session_start().
Why a 'Hello World' app is enough
Because the flaws sit below the application, Wiz reports that even a minimal PHP app on an affected version can leak process memory. That memory can hold passwords, session tokens, API keys and certificates from other users’ requests. A clean application security record does not protect you here.
Which servers are affected
Any PHP installation that serves web requests is in scope until it runs a fixed version. That includes Apache mod_php, PHP-FPM behind Nginx or Apache, php-cgi, FrankenPHP and LiteSpeed. Third-party products that embed PHP, such as appliances, control panels and hosting stacks, can be affected too.
Highest risk: Apache mod_php
Cleanup runs even when request startup fails, so an attack can succeed before your code executes. Patch these first, starting with internet-facing hosts.
High: PHP-FPM
FPM kills a worker when startup fails, which blocks one path. Code execution is still confirmed through the session upload progress path and application code paths.
In scope: php-cgi, FrankenPHP, LiteSpeed
Every web-facing SAPI is listed as affected. Treat them like FPM until your vendor confirms otherwise.
Containers and images
A running container keeps the PHP it was built with. Rebuild images on a fixed base, redeploy, and retire old tags.
Fixed versions by branch
- PHP 8.5
- Affected before 8.5.12 → update to 8.5.12
- PHP 8.4
- Affected before 8.4.27 → update to 8.4.27
- PHP 8.3
- Affected before 8.3.36 → update to 8.3.36
- PHP 8.2
- Affected before 8.2.35 → update to 8.2.35 (end of life 31 Dec 2026)
- PHP 7.4, 8.0, 8.1
- No official release; minimal source backports, distro or LTS vendor packages, or upgrade
- PHP 7.3 and older
- No fix; upgrade to a supported branch
Linux distributions and long-term-support vendors received the patches in advance, so check your distribution’s security tracker for its own package version. PHP also warned that the popular rpms.remirepo.net repository would not carry updates on release day; CERT-EU advises its users to switch to distribution packages or build from source.
Is anyone exploiting PHP2Shell?
Attack attempts started on day one.
20 Oct, ~15:00 UTC
CVE identifiers leak online with an incorrect release time and CVSS score. No technical details leak.
20 Oct, ~20:00 UTC
A researcher mistakenly publishes a video of a working proof of concept. PHP brings the release forward to 21 October.
21 Oct, 03:02 UTC
Cloudflare enables firewall rules for all customers by default, describing them as a stopgap.
21 Oct, ~13:30–14:00 UTC
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 released, with backports for 7.4, 8.0 and 8.1.
21 Oct, 14:19 UTC
watchTowr reports active exploitation attempts against both CVEs on its honeypot network.
23 Oct
A third RCE issue, CVE-2026-115560, is added to advisories. Details are withheld until the next PHP release.
The Hacker News reports that Cloudflare saw attackers change payloads to slip past its rules, and that several organisations, including Dutch government services, took systems offline as a precaution. Rapid7 found that the public proofs of concept each work only on a narrow combination of operating system, PHP version and web server, but it expects a more portable exploit to appear. As of 22 October, watchTowr noted that neither CVE was in CISA’s Known Exploited Vulnerabilities catalog; that can change quickly, and it is not a reason to wait.
Quiet logs are not proof of safety
The bugs fire below the application layer, so application logs may show little. Rapid7 notes that the absence of log entries does not prove a server is safe. Wiz suggests watching for unusual multipart requests followed by memory-limit errors, bursts of HTTP 500 responses, unexpectedly large or malformed PHPSESSID cookies in responses, and unexplained PHP worker churn.
How to patch PHP2Shell, step by step
- Inventory every PHP runtime that answers web requests. Include web servers, containers, staging hosts, control panels and appliances. Start with anything internet-facing.
- Check the version that is actually running, not just the CLI. The command-line PHP and the FPM or Apache module can be different builds.
- Install the fixed package for your branch from your distribution, LTS vendor or php.net. On end-of-life branches, use a vendor backport or upgrade.
- Restart all PHP workers: PHP-FPM pools, Apache, LiteSpeed or FrankenPHP. Until they restart, the vulnerable engine is still in memory.
- Rebuild and redeploy container images on a patched base image, then remove old tags from registries and deployment manifests.
- Verify by requesting a
phpinfo()page on a private path or checking the version reported by each pool, then delete any test page. - Rotate secrets on exposed hosts that were internet-facing and unpatched, since memory disclosure can leak tokens and keys from other requests.
Useful commands for steps 2 and 4:
# CLI version (may differ from the web SAPI)
php -v
# PHP-FPM version; the binary name varies by distro, e.g. php-fpm8.3
php-fpm -v
# Which SAPI and settings the web server really uses: check from a short-lived,
# access-restricted phpinfo() page, then delete it
# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm # or: sudo systemctl restart apache2
# RHEL / Rocky / Alma
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm # or: sudo systemctl restart httpdAdjust package names to your branch. On shared hosting, ask your provider which PHP build your account runs and when it was restarted; you usually cannot patch the runtime yourself.
Interim mitigations if you cannot patch today
PHP is explicit that no configuration change fully mitigates these vulnerabilities. If a server cannot be updated within hours, the safest option is to take it off the internet. If that is not possible, the measures below from PHP’s advisories, as summarised by CERT-EU and Rapid7, reduce exposure. Apply them at the administrative level so applications cannot override them, then restart every worker.
; php.ini, or the PHP-FPM pool via php_admin_value / php_admin_flag
; CVE-2026-109619 (and CVE-2026-115560): disable session upload progress
session.upload_progress.enabled = 0
; PHP 8.5 only: disable fatal error backtraces
fatal_error_backtraces = 0
; Bound request bodies: 8M if you take no uploads, 32M if you do
post_max_size = 8M
upload_max_filesize = 6M# Apache with mod_php: set in the vhost or server config, not .htaccess
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 8MFor CVE-2026-109618, the advisories also describe enforcing memory_limit=-1 so the out-of-memory path is harder to reach. That removes PHP’s own memory ceiling, so pair it with a container or cgroup memory limit and isolate workers. Do not use RLIMIT_AS or RLIMIT_DATA, which can trigger the vulnerable allocation-failure path.
- Setting these values with
ini_set()or a.user.inifile is too late; they must apply before the request is parsed. - Hiding errors with
display_errors,error_reportingor the@operator does not prevent the stale-state bug. - If your application never accepts
multipart/form-data, block it at the reverse proxy or WAF before it reaches PHP. - Cap request body size, part counts and headers per part at the front end, including requests without a usable
Content-Length. - Keep WAF rules from Cloudflare, Akamai, AWS, Fastly, Google or Microsoft on, but treat them as a stopgap: attackers are already reshaping payloads.
What this means for your security programme
PHP2Shell is a runtime vulnerability, and runtimes are where many patch programmes are weakest. Teams patch WordPress plugins and Composer packages on a schedule, while the PHP binary under them is owned by a base image, a hosting provider or an operations team that is not watching application advisories. That gap is exactly what an attacker uses.
Three lessons are worth acting on now:
Know your runtimes
Keep an inventory of language runtimes and versions per host and image, not just application dependencies. You cannot patch what you cannot find.
Patch to an SLA
Unauthenticated, internet-facing RCE needs a patch target measured in hours, not weeks. ISO 27001 Annex A 8.8 expects exactly this kind of risk-based timeline.
Test after you patch
An external penetration test confirms that what you think is patched is what attackers actually reach, including forgotten hosts and old containers.
Disclosures like this are also arriving faster. PHP’s own timeline credits AI-assisted research from several teams, and Wiz says AI cut the effort needed to chain bugs and adapt exploits to different versions and memory layouts. Expect shorter gaps between disclosure and working exploits, and plan patch windows on that basis.
If you need help finding every exposed PHP system or proving the fix landed, Sumrite’s network VAPT and web application VAPT cover internet-facing hosts and the applications on them, and our cloud security assessment reviews container images and runtime configuration. For the process side, see our guides to ISO 27001 Annex A 8.8 technical vulnerability management and internal vs external penetration testing.
Sources
- PHP Foundation: Today’s PHP security release, and how we’re strengthening PHP security (21 October 2026)
- CERT-EU: Security advisory 2026-018, Critical vulnerabilities in PHP
- Rapid7: CVE-2026-109618 and CVE-2026-109619: Critical unauthenticated remote code execution in PHP
- Wiz Research: PHP2Shell: AI uncovers critical RCE vulnerabilities
- watchTowr: PHP2Shell FAQ
- The Hacker News: PHP issues emergency patches for two critical PHP2Shell RCE flaws
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the name used for two critical memory-safety vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, disclosed on 21 October 2026. Both are rated CVSS v4.0 9.2 and can let an unauthenticated attacker run code on a web server with the privileges of the PHP worker.
Which PHP versions are affected by CVE-2026-109618 and CVE-2026-109619?
Every PHP 8.2, 8.3, 8.4 and 8.5 release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12, plus older end-of-life branches. Researchers report the underlying bugs reach back as far as PHP 5.4. PHP 7.4, 8.0 and 8.1 get only minimal source backports, and PHP 7.3 and older get no fix.
Is my WordPress, Drupal or Laravel site affected?
Probably, if it runs on an unpatched PHP version. The flaws are in the PHP runtime, not in the CMS or framework, so updating WordPress, Drupal, Joomla or Laravel does not fix them. You or your host must update PHP itself and restart the PHP workers.
Is PHP2Shell being exploited?
Exploitation attempts began on the day of disclosure. Cloudflare reported attack traffic and payloads changing to evade its rules, and watchTowr reported exploitation attempts against both CVEs on 21 October. As of 22 October neither CVE was in CISA's Known Exploited Vulnerabilities catalog, and no confirmed breach of a specific server had been published.
Can I mitigate PHP2Shell without updating PHP?
Only partly. PHP says no configuration change fully mitigates these vulnerabilities. Disabling session.upload_progress, turning off fatal_error_backtraces on PHP 8.5, tightening request limits and putting a WAF in front reduce exposure while you patch, but the security release is the only complete fix.
Do I need to restart PHP after updating?
Yes. PHP-FPM pools and Apache processes keep the old engine in memory until they restart. After installing the fixed package, restart PHP-FPM or Apache and confirm the running version, not just the installed one.
What is CVE-2026-115560?
A third PHP remote code execution issue added to public advisories on 23 October 2026. PHP has withheld details until its next release and says it only affects unusually configured applications. Setting session.upload_progress.enabled=0 and restarting workers is the advised interim step.
