PHP2Shell (CVE-2026-109618 and CVE-2026-109619): How to Patch, Mitigate and Detect Attacks

What Is PHP2Shell?

PHP2Shell is the name used for two related memory-safety flaws in the core PHP runtime. They sit below your application code, so a fully updated CMS or framework does not protect you on its own. The PHP security team describes them in two advisories:

• CVE-2026-109618, "RCE via OOM corruption": if PHP runs out of memory while it is still setting up a request, the request data is only partly initialized. Cleanup can then treat that invalid data as valid (GHSA-w8hw-w9fx-j79w).
• CVE-2026-109619, "RCE via stale global state": internal state owned by one request can survive after its memory is freed. A later request on the same worker may then use that stale state (GHSA-6wmf-4rv5-p3rp).

Both advisories list the weakness as use after free (CWE-416), and both carry the CVSS v4.0 vector AV:N/AC:H/AT:P/PR:N/UI:N with high impact to confidentiality, integrity and availability. In plain terms: an attacker needs only network access, no account and no user action. PHP says the confirmed impact of CVE-2026-109619 is heap use after free, memory disclosure and remote code execution with the web worker's privileges.

PHP says it validated complete remote code execution over HTTP against Apache mod_php with default input and memory limits and a normal multi-worker prefork setup (PHP advisory). Help Net Security reports that a working exploit showed a single unauthenticated request can trigger the attack before any application code runs (Help Net Security).

The flaws were reported to PHP by several researchers, including Wiz Research, which disclosed them together with the PHP project (Google Cloud).

Who Is Affected

According to Help Net Security and Huntress, which cite the PHP project, every PHP installation that serves web requests is affected. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed (Help Net Security, Huntress).

The official advisories list these supported branches as affected:

Timeline: From Leak to Patch

The disclosure did not go to plan. On 20 October 2026 the CVE identifiers circulated on Hacker News and social media before the planned release, according to Tenable. watchTowr confirmed the leak and said the embargo had been set for Thursday, 22 October (Tenable, Huntress).

PHP then published an advance notice and released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026. The CVEs were assigned the same day (PHP.net, Google Cloud).

Help Net Security reports that Linux distributions and LTS vendors received patches before publication, so check your distribution's security feed as well as php.net.

Is PHP2Shell Being Exploited?

Reports on 21 October differ, so plan as if attacks have started:

• watchTowr says it observed exploitation in the wild as of 21 October through its global honeypot network (watchTowr).
• Tenable reports that Cloudflare is "seeing early attacks emerging," and that code claiming to exploit the flaws is circulating publicly, though Tenable had not verified it (Tenable).
• Huntress said it had not yet seen exploitation across its partner base as of 10am ET on 21 October (Huntress).

At the time of writing, watchTowr lists CVE-2026-109618 as not yet in the CISA Known Exploited Vulnerabilities catalog. You can check the latest status for both CVEs in the CVE Search tool.

Exposure is large. Tenable cites an estimate of over 1.3 million internet-exposed hosts that are potentially vulnerable, and W3Techs data showing PHP behind 69.3% of websites whose server-side language is known (Tenable).

How to Check Your PHP Version

You cannot patch what you have not found. Check every server, container image and hosting account that runs PHP, including staging sites and forgotten microsites.

• On a server: run php -v on the command line. Also check the version the web server actually uses, because the command-line PHP can differ from the PHP-FPM or Apache module version.
• On WordPress: go to Tools, then Site Health, then the Info tab, and open the Server section to see the PHP version.
• On shared or managed hosting: look in your hosting control panel, or ask your host's support team directly whether they have deployed the 21 October PHP updates.
• In containers: check the PHP version in each image and rebuild from a patched base image. Google Cloud notes that custom images, GKE and App Engine flexible need a redeploy with patched PHP (Google Cloud).
• From outside: some servers announce their PHP version in an X-Powered-By header. Our Security Header Analyzer shows the headers your site sends. A missing header does not prove you are safe.

php -v
# If you run PHP-FPM, check the FPM binary too (name varies by distribution)
php-fpm -v 2>/dev/null || php-fpm8.3 -v 2>/dev/null

How to Patch PHP2Shell

PHP is clear that updating is the only complete fix. The release notes for PHP 8.5.12 say: "There are no complete mitigations, updating is the only safe choice" (PHP.net).

• Supported branches: update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 through your operating system's package manager, your PHP repository, or the official PHP downloads page. Windows builds are available there too.
• Restart every PHP worker after the update. A PHP-FPM pool or Apache process that keeps running still uses the old code in memory.
• PHP 7.4, 8.0 and 8.1: PHP provided minimal source backports for people building from source or without an LTS vendor. Otherwise, ask your distribution or LTS vendor for a fix, or upgrade to a supported branch.
• PHP 7.3 and older: there is no fix from PHP. Plan an upgrade and, until then, take the site off the public internet or place it behind a VPN or web application firewall (WAF), as Huntress advises.
• Hosted sites: if your host manages PHP, ask them for written confirmation of the patched version and the date it was deployed.
• Plan ahead: PHP 8.2 receives security fixes only until 31 December 2026, so schedule your move to 8.3 or newer now.

Note that one community repository, rpms.remirepo.net, had no updates on release day, according to Help Net Security. If you rely on a third-party repository, confirm the version it installs before you mark the job done.

Temporary Mitigations If You Cannot Patch Today

If an update has to wait for a change window, PHP lists measures that reduce exposure. PHP stresses that they "do not make an installation safe." Set them in php.ini, the FPM pool or the server configuration, then restart every worker. Do not rely on ini_set() or FPM .user.ini files.

For CVE-2026-109618 (out-of-memory corruption), the PHP advisory suggests:

• Set memory_limit=-1 in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and pair it with a container or cgroup memory limit that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA.
• Lower post_max_size to 8M if you do not need uploads, or 32M if you do, and keep upload_max_filesize below it.
• Enforce limits at the web server or proxy on request size, input field count, multipart parts, header count and nesting depth, including for requests without a usable Content-Length.
• Reduce max_input_nesting_level, and block multipart form data at the front end if your application does not use it.
• For CVE-2026-109619 (stale global state): set session.upload_progress.enabled=0. On PHP 8.5, also set fatal_error_backtraces=0. Consider pm.max_requests=1 for PHP-FPM if performance allows. PHP says there is no complete generic configuration mitigation for this flaw.

Network controls help too. CERT-EU suggests isolating internet-facing applications until they are fixed, and the UK NCSC urges organizations to consider taking offline any system that cannot be fixed right away (Tenable, Help Net Security). Cloudflare has deployed an initial set of WAF rules for the known exploit vectors, but describes them as a stopgap only.

; php.ini or FPM pool (use php_admin_value in pools so apps cannot override)
session.upload_progress.enabled = 0
post_max_size = 8M          ; 32M if you need uploads
upload_max_filesize = 6M    ; keep below post_max_size
; PHP 8.5 only:
fatal_error_backtraces = 0

How to Detect Exploitation Attempts

At the time of writing, Huntress says no indicators of compromise have been confirmed. Its advice, based on Florian Roth's expectation, is that exploitation will most likely show up as suspicious child processes started by PHP (Huntress). Watch for:

• Parent processes php-fpm, php-cgi, php-cgi.exe, httpd or apache2 starting sh, bash, cmd.exe, powershell.exe, python, perl, curl, wget, nc or certutil.exe.
• Command lines that contain /dev/tcp/, fsockopen or mkfifo, which often point to a reverse shell.
• Reconnaissance commands run by the web server user, such as whoami, id, uname -a or ipconfig.
• New or changed PHP files in the web root, which may be web shells, plus new cron jobs, scheduled tasks or user accounts.

Huntress points to Florian Roth's process-watcher in observe mode as one way to spot this, and says it will publish Sigma and YARA rules once technical details are available. Vulnerability scanners are adding checks too: Tenable notes its PHP version detection plugins can find hosts to review now.

Preserve your web server and PHP logs before you rotate or clean anything. If you find signs of compromise, patching alone is not enough: treat the server as compromised and follow an incident response process.

# Processes whose parent is a PHP or Apache worker
ps -eo pid,ppid,user,cmd --forest | grep -A3 -E "php-fpm|php-cgi|apache2|httpd"

# PHP files changed in the last 3 days under the web root (adjust the path)
find /var/www -name "*.php" -mtime -3 -ls

Checklist for Small Business Owners and Site Admins

If you only have a few minutes, work through this list in order:

• List every website, staging site and server you own that runs PHP, including ones an agency or freelancer built for you.
• Check each PHP version and compare it with the fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• Update PHP, or ask your host to confirm they have, and restart all PHP workers.
• If you are on PHP 8.1 or older, ask your vendor for a backported fix and book an upgrade to a supported branch.
• If you cannot patch today, apply the PHP mitigations, restrict access with a VPN or WAF, or take the site offline.
• Review logs and processes for the warning signs above, and keep the logs.
• Make sure you have a recent, offline backup of each site before and after the change.

For more ways to harden a website, browse our web security guides, and follow updates on this story in our daily cybersecurity news briefing.

Final Thoughts: Patch First, Then Verify

PHP2Shell is serious because it lives in the language runtime that so much of the web depends on, it needs no login, and its details leaked before defenders had a head start. The good news is that the fix is simple for supported versions: update PHP and restart the workers.

Patch today, confirm the running version on every site, and then spend a few minutes checking for signs that someone got in first. That short routine closes the door and tells you whether anyone walked through it.