PHP2Shell (CVE-2026-109618): am I affected and what should I do?

What happened

On 21 October 2026 the PHP project published two critical vulnerabilities in the PHP core:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): “RCE via OOM corruption”, remote code execution without login, CVSS 4.0: 9.2. According to the CVSS vector, the attack is complex and requires preconditions (AC:H, AT:P).
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): “RCE via stale global state”, a use-after-free between two requests in the same worker, also CVSS 4.0: 9.2.

According to the advisory, full code execution was demonstrated against mod_php with default settings. For PHP-FPM, the advisory says no complete exploit has been demonstrated yet; FrankenPHP is considered likely susceptible, and for LiteSpeed (LSAPI) application-specific exploits are likely. The PHP release announcement lists PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed as affected.

Affected and fixed versions

The advisory names updating as the only complete mitigation. Which PHP versions still get updates at all is shown in the end-of-life overview.

Is it being exploited?

• Amazon Threat Intelligence observed a first exploitation attempt on a honeypot on 17 October, four days before disclosure, and several proof-of-concept exploits from different actors on 21 October. According to Amazon it is unclear whether any attempt succeeded.
• According to Cloudflare, WAF rules were active for all customers from 03:02 UTC on 21 October, about nine hours before disclosure, and Cloudflare observed attack traffic.
• According to Censys data reported by heise, of nearly 11 million PHP services in Germany, around 4.2 million showed a vulnerable version number on 23 October. Because distributions backport fixes, a version number alone does not prove a system is vulnerable.
• CISA called for immediate patching on 21 October. As of 23 October, neither CVE was listed in CISA’s KEV catalog. Why that is no reason to wait is explained in the article on CVSS, EPSS and CISA KEV.

Am I affected? How to check

On every system that serves PHP requests:

php -v

Make sure you check the PHP version that actually answers requests. CLI and FPM can be different versions:

php-fpm -v

In repos with Docker, the version is usually in the base image:

grep -rn "FROM php:" --include=Dockerfile* .

Other places where PHP versions live in repos: .php-version, composer.json ("require": {"php": ...} only states the allowed range, not the running version), CI configs such as .github/workflows/*.yml (php-version:) and infrastructure code.

Pitfalls

Distributions with backports. Debian, Ubuntu and RHEL often patch without raising the PHP version number. php -v then shows an “old” version that is nevertheless fixed, or the other way round. What counts is the package version according to your distribution’s security tracker.

Workers keep running. After the update, PHP-FPM workers and mod_php keep running the old code until they are restarted. With Docker this means rebuilding the image and replacing the containers, for example:

docker compose build --pull && docker compose up -d

Pinned images. FROM php:8.3-fpm pulls the fixed version on the next build, FROM php:8.3.35-fpm does not. Also check images that are rarely rebuilt.

Package scanners don’t see it. Dependabot and other SCA tools check packages from composer.lock. A vulnerability in the PHP interpreter is not a Composer package. More in the comparison with Dependabot.

What to do now

1. List all systems and repos running PHP, including rarely deployed ones.
2. Update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or to the fixed package for distribution PHP.
3. Restart PHP-FPM, the web server or the containers.
4. Verify on the running system with php -v and php-fpm -v.
5. If you were online and vulnerable, review logs for suspicious requests since 17 October.

If you cannot patch right away

These measures do not replace the update, they only reduce the risk until then:

• Put a web application firewall with PHP2Shell rules in front, if your provider offers them.
• Apply the configuration changes listed in the PHP announcement, such as session.upload_progress.enabled=0. According to PHP, these settings do not make a system safe.
• Take affected services offline if they do not need to be publicly reachable. According to heise, the German BSI recommended taking websites offline as a precaution.

On 23 October the PHP project also published an informational notice on CVE-2026-115560 (session upload progress), PHP rates this attack path as unlikely and likewise recommends session.upload_progress.enabled=0 until the next regular release.

Sources

• PHP Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• php.net: announcement of 21 October 2026
• php.net: notice of 23 October 2026 (session upload progress)
• AWS Security Blog: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure
• Cloudflare Blog: WAF protection for the PHP vulnerabilities
• heise: PHP2Shell, millions of PHP services in Germany are vulnerable
• heise: Updates roll out as websites go offline and attacks begin
• CISA alert of 21 October 2026