PHP2Shell (CVE-2026-109618, CVE-2026-109619): How to Patch, Check and Hunt

What PHP2Shell is

CVE-2026-109618 and CVE-2026-109619 are memory-safety bugs in PHP itself, not in WordPress, Drupal or any other application built on it [1][2]. That is what makes them unusual: the vulnerable code ships inside every PHP build, so an organization can be exposed without running a single line of vulnerable application code [2].

• CVE-2026-109618, out-of-memory corruption. When PHP runs out of memory while it is still setting up internal request data, the cleanup that follows can treat half-built data as valid [1].
• CVE-2026-109619, stale global state. State that belongs to one request can survive after its memory has been freed, and a later request handled by the same worker can use it [1]. PHP's advisory lists memory disclosure as a confirmed impact as well as code execution [3].

PHP rates both CVSS v4.0 9.2, Critical [3]. An earlier circulating listing showed 10.0; the PHP Foundation says that score was wrong [3]. The name "php2shell" describes the outcome researchers demonstrated: a web request that ends in a shell on the server [5].

CrowdStrike reports verifying, in its own testing, that a single anonymous POST could make an Apache mod_php worker run an attacker-chosen command, and that the attack was quiet: no worker crash, normal HTTP 200 responses, and nothing unusual in application logs [2]. Successful exploitation runs commands as the web server user, which is the usual starting point for web shells, credential theft from configuration files and lateral movement [2].

Who is affected

PHP's advisory covers "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed," and says the risk is highest for mod_php [1]. The vulnerable code paths go back years: CrowdStrike traces them to PHP 7.x and earlier, and states that every PHP release in the 7.x and 8.x series is affected [2].

Sources: PHP [1], Tenable [3], watchTowr [4].

Linux distributions and LTS vendors received the patches in advance, so a distribution package may carry the fix under its own version number [1]. Check your vendor's advisory rather than reading the version string alone.

Exposure also depends on configuration. CrowdStrike's research found the out-of-memory path is reachable when memory_limit is small relative to post_max_size (roughly memory_limit < 4 × post_max_size). Stock defaults do not meet that condition, but hosts that raise upload limits often do, and a single site on shared hosting can be put in that state by its own .htaccess or virtual host settings [2]. PHP treats every web-serving installation as at risk, so a default configuration is not a reason to wait [1].

Is PHP2Shell being exploited?

Yes, attempts have been reported, and several researchers expect exploitation to grow.

• Amazon Threat Intelligence logged an exploitation attempt against its honeypots on 17 October 2026, four days before the patch, and further attempts on 21 October with signs of multiple actors. Amazon recommends that investigations look back to 17 October [3].
• watchTowr reports observing exploitation of both CVEs in the wild against its honeypot network from 21 October [4].
• Cloudflare reported early attacks on 21 October and deployed WAF rules for known attack paths as a stopgap [3].
• Huntress reported no exploitation on its partners' systems as of 21 October at 4:30 pm ET, while noting others were seeing attacks [5].

Neither CVE was in CISA's Known Exploited Vulnerabilities catalog as of its 21 October 2026 update [6]. Code claiming to exploit these CVEs is circulating; PHP's team found no functional public exploit at release time, and any such code should be treated as potentially malicious [3].

How to check whether you are exposed

Start with an inventory, because PHP hides in more places than the web team's servers: control panels, appliances, vendor software and bundled CMS platforms all carry their own copy [5].

On each host, check the version and the settings that matter:

php --version
php -i | grep -E "^(memory_limit|post_max_size|upload_max_filesize|Loaded Configuration File)"

The CLI can read a different php.ini from the one your web server uses, so confirm the values your FPM pool or Apache module actually loads (for example with phpinfo() on a protected page you remove afterwards) [2]. Prioritize anything internet-facing.

What to do now

1. Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor's fixed package. Start with internet-facing servers [1].
2. Restart every PHP worker after updating. A patched binary does not help a worker that is still running the old code.
3. Replace or isolate unsupported branches. PHP 8.1 and older get no project updates; until a vendor fix or upgrade lands, take the system off the public internet or put it behind a VPN [1][5].
4. Look back to 17 October. Patching closes the door but does not tell you whether someone already came through it [3]. Use the detection steps below.
5. Rotate secrets on any host where you find signs of compromise, starting with database credentials and API keys stored in application configuration.

Temporary mitigations if you cannot update today

PHP is explicit that these reduce exposure to specific attack paths and "do not make an installation safe" [1]. Use them only to buy time.

• For CVE-2026-109618: set memory_limit = -1 with php_admin_value in the FPM pool or Apache config so applications cannot override it, keep post_max_size small (PHP suggests 8M, or 32M where uploads are required), and enforce request size and field limits at the web server or proxy [1].
• For CVE-2026-109619: set session.upload_progress.enabled = 0 in php.ini, the FPM pool or the server config, and on PHP 8.5 also fatal_error_backtraces = 0. Do not rely on ini_set() or .user.ini for this [1].
• Restart all workers after any configuration change [1].
• A WAF helps only for traffic that passes through it. Cloudflare's rules cover known vectors on Cloudflare-routed traffic and are described as a stopgap [3].

How to tell whether you were already hit

The attack leaves little in web telemetry, so the evidence is on the host [2]. The highest-value signals:

• A PHP or web worker starting a shell or a tool. Alert on php-fpm, php-cgi, httpd or apache2 spawning sh, bash, cmd.exe, powershell.exe, python, perl, curl, wget, nc or certutil [5].
• Reconnaissance commands from a web process, such as whoami, id, uname -a or ipconfig [5].
• Reverse-shell patterns in command lines, such as /dev/tcp/, fsockopen or mkfifo [5].
• New or changed files in the web root, especially web shells, and new cron jobs, scheduled tasks or accounts [5].
• A specific log pattern: "Allowed memory size of N bytes exhausted" together with "in Unknown on line 0". CrowdStrike notes this means the failure happened before any PHP script ran, and that it is often dismissed as noise [2].

If you find any of these, isolate the host, preserve the web server and PHP logs before anything rotates them, and hunt for web shells and persistence before you rebuild [5].

What CrowdStrike Falcon customers have

CrowdStrike says the Falcon platform detects the post-exploitation behavior these flaws lead to, including web shell deployment, suspicious child processes spawned by PHP or web server processes, and malicious command execution [2]. For finding exposure, CrowdStrike describes Falcon Exposure Management checks for these CVEs, including sensor-based checks for PHP installed outside the package manager [2]. For Falcon Next-Gen SIEM, CrowdStrike has added a PHP2Shell section to its Emerging Threat Response dashboard and published a correlation rule template for PHP memory exhaustion during request startup [2]. These are CrowdStrike's descriptions of its own coverage.

How Vijilan helps

PHP2Shell is a patch ticket and a hunting job at the same time, and the hunting job is the one that tends to get skipped.

• ThreatDefend™ customers run on CrowdStrike Falcon, watched 24/7 by Vijilan analysts who investigate a web worker that starts a shell rather than just logging it.
• ThreatRespond™ brings the same 24/7 coverage to the EDR you already own, if you are not on Falcon.
• NextDefend™ can bring web server and PHP logs into CrowdStrike Falcon Next-Gen SIEM, where the memory-exhaustion pattern and process signals are correlated instead of dismissed.
• ThreatAssess™ shows which of your internet-facing systems expose PHP, which is where this attack starts.

If you are not sure whether you are exposed, or whether anything ran before you patched, talk to our SOC team.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two critical remote code execution vulnerabilities in the PHP engine, rated CVSS v4.0 9.2. They can let an unauthenticated attacker run commands on a web server through HTTP requests, before any application code runs.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP 8.1 and older receive no update from the PHP project; use a fixed package from your Linux distribution or LTS vendor, or upgrade to a supported branch.

Is PHP2Shell being exploited in the wild?

Exploitation attempts have been reported. Amazon Threat Intelligence logged an attempt on 17 October 2026, before the patch, and watchTowr and Cloudflare reported attacks from 21 October. Neither CVE was in CISA's Known Exploited Vulnerabilities catalog as of 21 October 2026.

Does PHP2Shell affect WordPress, Drupal or Magento sites?

Yes, indirectly. The flaws are in PHP itself, so any application running on a vulnerable PHP version serving web requests can be exposed, regardless of whether the application is up to date. Updating the CMS does not fix it; updating PHP does.

Can I mitigate PHP2Shell without updating?

Only partially. PHP lists temporary settings, such as memory_limit = -1 and session.upload_progress.enabled = 0, that block specific attack paths, but says they do not make an installation safe. Updating is the only complete fix.

How do I know if my server was compromised by PHP2Shell?

Look for PHP or web server processes starting shells or tools like curl and wget, reconnaissance commands such as whoami run by a web process, new files in the web root, new cron jobs or accounts, and log lines reading "Allowed memory size of N bytes exhausted" with "in Unknown on line 0". Review activity back to 17 October 2026.

Is PHP running from the command line affected?

PHP's advisory names installations serving web requests: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. It does not discuss the CLI. Update every PHP build regardless, because the same binary often serves both.