PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Critical PHP RCE, What to Patch Today and How to Detect It
PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2. They allow unauthenticated remote code execution on any PHP installation serving web requests. Fixes shipped October 21, 2026 in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35: patch the runtime, restart every worker, and verify the changelog.
On October 21, 2026, PHP patched two 9.2 remote code execution bugs in the language runtime itself, not in a plugin, a framework, or a misconfigured application. That changes what patch day means for a large share of the web. This post is current as of October 22, 2026, and will be updated as details emerge.
The short version: nearly every PHP installation that serves web requests is in scope, the vulnerable code dates back to 2012, and exploitation attempts were observed before the patch shipped [1][4][9]. If you run PHP, this is not a research project. It is an inventory, a patch, a verification, and a monitoring check.
The fix is a server side update, not an application update, and patching is the only complete fix [1]. Cloudflare calls its WAF rules a stopgap [4][10], Amazon Threat Intelligence advises investigating suspicious activity dating back to at least October 17 [4][9], and the PHP project says only updating is a complete fix [1]. If you are not sure what you run, the fastest start is an external vulnerability scan for the internet facing perimeter and a credentialed scan for patch level detail on the inside.
What is PHP2Shell?
In one line: two memory handling flaws in the PHP runtime let an unauthenticated attacker run code on your web server.
CVE-2026-109618 is driven by out of memory corruption. If a request hits PHP's memory limit at the wrong moment, PHP can be interrupted while internal request data is only partly initialized, and request cleanup can treat that half built data as valid, corrupting memory. On Apache with mod_php, a demonstrated exploit triggers the flaw with a single unauthenticated request, before any application code runs. RCE was also confirmed on PHP-FPM through application level code paths [1][3].
CVE-2026-109619 is driven by stale global state. A fatal error at the wrong point can leave internal state pointing at memory that belonged to an earlier request. A later request handled by the same worker can use that freed memory before normal initialization resets it. Researchers also report that freed worker memory can be returned to the requester, exposing data from other requests [2][5].
Sansec's write-up describes one flaw as a use after free in the upload progress unserializer and the other as a use after free in the fatal error backtrace path with an OPcache type confusion. Sources assign these mechanisms to the two CVE numbers differently (PHP's own mitigation list ties session.upload_progress to CVE-2026-109619), so treat the exact mapping as unsettled and patch against both [1][2]. Every known trigger is a multipart/form-data request that PHP parses before application code runs [2].
Three details make this worse than an ordinary library bug:
- The flaws sit in the runtime, not your application. WordPress, Laravel, Magento, and a custom internal tool are passengers on the same broken memory code. Updating an application does not update the PHP runtime, which comes from the server package, the host, or the container image [1][5].
- Default configurations contain the bugs. PHP's Session Upload Progress feature is enabled by default and is one confirmed path to CVE-2026-109619, so most default deployments already meet the precondition [2][5].
- The code is old. The affected code path dates to PHP 5.4.0, which shipped in 2012, more than a decade before the patch [2][5].
Who found them? Per the PHP Foundation, Calif reported an unconditional RCE with the out of memory root cause on August 11, 2026, Wiz reported attack vectors on August 24, and OpenAI independently reported the same root cause and sent further attack vectors on September 18. The Foundation says it uses AI tools to validate reports (it names OpenAI's Daybreak Red) and that people make every decision and every patch, and The Hacker News reports that Google's Gemini team collaborated on the fix. The Foundation also says a core developer first saw signs of the out of memory problem during a 2024 external audit, and that the fix then stalled for months, which it calls a structural failure of its own decision process [5][6].
Which PHP versions are affected and fixed?
All supported branches below the fixed releases are vulnerable. Older branches need a backport or an upgrade to a supported release [1][7].
| PHP branch | Vulnerable below | First fixed release | Notes |
|---|---|---|---|
| 8.5 | 8.5.12 | 8.5.12 | Fixed October 21, 2026 [1] |
| 8.4 | 8.4.27 | 8.4.27 | Fixed October 21, 2026 [1] |
| 8.3 | 8.3.36 | 8.3.36 | Fixed October 21, 2026 [1] |
| 8.2 | 8.2.35 | 8.2.35 | Fixed October 21, 2026 [1]. PHP 8.2 reaches end of life on December 31, 2026, so plan the next upgrade too [1] |
| 7.4, 8.0, 8.1 | all versions | none | End of life. The PHP security team published minimal source backports for building from source; prefer a distribution or LTS vendor package [1][5] |
| 7.3 and older | all versions | none | No fix from the PHP project; upgrade to a supported branch [7] |
Two practical notes before you start:
- Check the PHP version that actually serves web requests with phpinfo() or your package manager, not the command line binary. The CLI PHP can be a different version from the one PHP-FPM or Apache runs [5].
- Verify the fix by searching the package changelog for the CVE, not by reading a version string. On Debian and Ubuntu, that is zgrep against the changelog; on RHEL family systems, use the rpm changelog option. Linux distributions and LTS vendors received the patches in advance, so a patched build can carry an older looking version number [1][2].
Is it being exploited?
Confirmed: exploitation attempts have been observed, including before disclosure, and attack volume has climbed into the millions since the release [4][7][9]. Disputed: how widely the flaws actually exploit, and whether the observed attempts would succeed against real systems [2][4].
The timeline, with times in UTC:
| Date and time (UTC) | Event | Source |
|---|---|---|
| October 17 | Amazon's MadPot honeypot network records a php2shell exploitation attempt, four days before public disclosure. The attempt came from an IP tied to a commercial anonymization service | [4][9] |
| October 20, around 15:00 | The two CVE IDs begin circulating on forums and social media, with a wrong release time and a wrong CVSS score of 10.0; the real score is 9.2 | [6] |
| October 20, 19:30 | PHP publishes its pre announcement and moves the release forward to October 21 at 14:00 | [6] |
| October 20, around 20:00 | Calif mistakenly publishes a video of its working proof of concept; copies circulate on social media | [6] |
| October 21, 02:00 | Amazon detects multiple proof of concept exploits from different anonymized infrastructure, which it reads as multiple actors | [4][9] |
| October 21, 03:02 | Cloudflare WAF protections go live for all plans, including Free | [4][10] |
| October 21, 07:41 | Chainguard publishes patched images, more than six hours before the coordinated release | [5][6] |
| October 21, 14:00 | PHP releases 8.5.12, 8.4.27, 8.3.36, and 8.2.35 | [1] |
| October 21 | The UK NCSC urges immediate updates and taking systems offline that cannot be fixed in time; Cloudflare's CTO reports early attacks emerging | [5][7][9] |
| October 22 | Cloudflare has recorded millions of exploitation attempts, and attackers are mutating payloads to try to bypass the WAF | [4] |
Confirmed, in plain terms:
- Amazon Threat Intelligence says php2shell is now being broadly exploited in the wild, and the October 17 attempt predates disclosure [4][7][9].
- watchTowr reproduced both vulnerabilities and reports observing exploitation attempts against both [3].
- Cloudflare says it spotted thousands of attempts in the ten hours before announcement, hundreds of thousands within two hours of disclosure, and then millions [4].
- As of the CISA Known Exploited Vulnerabilities catalog update of October 21, 2026, neither CVE is listed [8]. CISA also published an alert on October 21 urging immediate updates to the fixed versions, and said it had not observed exploitation when it published [19].
Still disputed:
- Sansec updated its research on October 22 to say mass exploitation is less likely than first expected. Its testing found that public proof of concept code reportedly does not work against a default install, and most public exploits need a local file inclusion bug in the target application [2].
- The scale of real world compromise is unknown. Amazon notes it is unclear whether the pre disclosure attempts would have succeeded against real systems [4][9].
The honest read: the activity is real, the patch window closed on October 21, and whether a given payload works against your stack varies by hour. Verify your own exposure instead of waiting for a definitive verdict.
Who is exposed?
Every PHP installation that serves web requests, per PHP's advisory [1][3][5]:
| Layer | What to check |
|---|---|
| mod_php (Apache) | Highest demonstrated risk: a single unauthenticated request can trigger the attack before any application code runs [1] |
| PHP-FPM | RCE confirmed through application level code paths [3] |
| php-cgi | In scope per PHP's advisory [1] |
| FrankenPHP and LiteSpeed | In scope per PHP's advisory [1] |
| CMS and frameworks | WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony, and WHMCS are reported affected platforms; Magento and WordPress also appear in the broader reporting [2][3][7] |
| Hosting panels | Plesk, DirectAdmin, and cPanel update PHP through the panel, so check the panel's PHP version, not just your app's [2] |
| Appliances and managed platforms | Palo Alto Networks says all PAN-OS and Panorama versions are affected, with no fixed releases yet as of October 22; Fortinet and Cisco published advisories and are still checking products, with no confirmed vulnerable product yet [9] |
If a vendor manages PHP for you, the fix lands through the vendor. If you do not know who manages your PHP, that is the first question to ask.
How to fix it today
Work through this in order for every system that serves PHP.
The php2shell patch checklist
This six step sequence is a working baseline for patch day:
- Find every PHP runtime, including PHP that ships inside other products: content management systems, hosting panels, appliances, and container images that bundle their own copy. Start with internet facing servers, then business critical systems. One missed runtime leaves the whole exposure open [2][5].
- Update to the fixed release for your branch: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. On end of life branches, use a distribution or LTS vendor package, or the PHP security team's minimal source backports [1].
- Verify the changelog, not the version string. zgrep on Debian and Ubuntu; the rpm changelog option on RHEL family systems [2].
- Restart Apache, PHP-FPM, and every long running worker. The fix does not take effect in a worker that keeps running old code [5].
- Verify the running version again with phpinfo() against the web SAPI, not the CLI [5].
- Systems that cannot be patched right away: isolate them from the internet or take them offline, apply the interim measures below, and keep a WAF in front where you have one [5][9].
What to record for every PHP instance
A useful exposure list has one row per instance, not one summary line per team. Keep these fields so each finding can be fixed and then proved fixed:
| Field | Why it matters |
|---|---|
| Host name and IP address | Tells the owner which system to patch |
| Last seen | Separates live servers from stale inventory entries |
| Detected PHP version and branch | Compare it with the fixed releases: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 |
| How the version was detected | A banner, a credentialed login or an agent inventory are different levels of proof, and distribution packages can carry a fixed build under an older version number |
| Internet facing or internal | Sets the patch order |
| Fixed version or vendor package to move to | Turns the finding into a work item |
Every PHP 5.x, 7.x, 8.0 and 8.1 instance belongs on the list as vulnerable, because those branches have no official fix from the PHP project [1]. Refresh the list on a schedule instead of treating it as a one time project, because new containers and application installs reintroduce old PHP builds.
Two extra notes:
- Appliance users: check your vendor's advisory for PAN-OS, Panorama, Fortinet, and Cisco platforms before you declare victory. No fixed PAN-OS or Panorama release existed as of October 22 [9].
- Remi repository users: switch to distribution packages or build from source, because that volunteer repository had no update available when Help Net Security reported [9].
If you cannot patch right now
PHP's advisory lists configuration changes that reduce exposure to specific attack paths. They do not make an installation safe, and PHP says updating is the only complete fix [1].
| CVE | Interim measure | What it does | What it does not do |
|---|---|---|---|
| CVE-2026-109618 | memory_limit=-1, set where the application cannot override it (php_admin_value in the FPM pool or Apache config) | Removes the memory pressure trigger | Does not fix the underlying corruption path |
| CVE-2026-109618 | A low post_max_size (8M without uploads, 32M with uploads), with upload_max_filesize below post_max_size, plus request size limits at the web server or proxy | Shrinks the surface for crafted large requests | Does not fix the underlying corruption path |
| CVE-2026-109619 | session.upload_progress.enabled=0 in php.ini or server or pool config, not via ini_set or .user.ini, then restart every worker | Closes the default enabled Session Upload Progress path | Is not the only path, and does not fix other triggers [1][5] |
| CVE-2026-109619 | fatal_error_backtraces=0 on PHP 8.5 | Closes the fatal error backtrace path | Does not fix other triggers [1] |
Do not use RLIMIT_AS or RLIMIT_DATA as a mitigation; PHP's advisory advises against them [1]. Restart every PHP worker after any configuration change, or the old worker ignores the new setting [1].
For internet facing systems that cannot be fixed quickly, the UK NCSC's guidance is to take them offline or isolate them [5][9]. A downed payment page is a business conversation. An unpatched, internet facing PHP box is a compromise in progress.
How to tell whether you were hit
Both flaws are triggered by errors inside a request, so the logs are where the answer lives [3][5].
| What to look for | Why it matters |
|---|---|
| Unusual multipart requests followed by memory limit errors or repeated HTTP 500s | The known triggers are multipart/form-data requests that hit PHP's error paths [2][5] |
| Oddly large PHPSESSID response cookies | One of the flaws can return freed worker memory to the client in a PHPSESSID cookie, even if the application never calls session_start() [2][5] |
| Unexplained PHP worker crashes and restarts | Both flaws are triggered by errors inside a request, and unexplained worker restarts are a listed indicator [5] |
| Web server processes spawning shells or unusual child processes | What RCE looks like once it lands [3] |
| Unexpected file changes in web roots, new accounts, or new persistence | Post compromise indicators to check before and after you patch [3] |
| Outbound connections from PHP processes you cannot explain | A common follow on to code execution [3] |
Work down that table against your own access and error logs before you patch. It is the fastest way to find out whether you are in the verify camp or the respond camp.
Memory disclosure is part of this: the freed worker memory can contain data from other requests, including passwords, tokens, API keys, and certificates [2][7]. If you see an oversized PHPSESSID cookie, treat it as a potential data exposure event, not just a failed request.
What to preserve before you change anything: web server access and error logs, PHP error logs, a snapshot of the web root with timestamps, process and network connection listings, and any suspicious binaries or cron entries. Preserve evidence first, patch second.
When to call it an incident: web server processes spawning shells, unexpected file changes in web roots, new accounts or persistence, or outbound connections from PHP you cannot explain. Isolate the host and run a full incident response. Amazon advises investigating suspicious activity dating back to at least October 17, because attempts before disclosure are documented [4][9].
How Clone Systems helps you find and contain it
Vulnerability scanning and PCI ASV scanning
Clone Systems runs external and credentialed vulnerability scanning from one portal [12][15]. The external scan covers your internet facing perimeter with no software install, and the credentialed scan gives more accurate patch level detection. The CloneGuard portal continuously maps hosts, services, and applications, so the PHP box you forgot about shows up in the inventory.
One caveat that matters here: a PHP version string can mislead you, because Linux distributions backport fixes under older version numbers [1][2]. Findings should be confirmed against the package changelog, not trusted at face value.
For PCI: PCI ASV scanning is the external scan behind PCI DSS 4.0.1 requirement 11.3.2, and PCI DSS 4.0.1 requirement 6.3.3 expects critical and high-security patches to be installed within one month of release, ranked under your own risk process in requirement 6.3.1 [11]. The practical number: a passing ASV scan has no vulnerabilities scored CVSS 4.0 or higher, so an externally visible finding scored 9.2 fails the scan until it is remediated [1][13]. Clone Systems has been a PCI SSC Approved Scanning Vendor since 2007, and rescans are unlimited until the scan passes [13].
Continuous inventory with the CloneGuard agent
The CloneGuard agent is a small agent on each host: servers, cloud VMs, container hosts, and laptops. It inventories installed software, OS packages, runtimes, and services, checks patch state and configuration against CIS and vendor baselines, and matches new CVEs against the inventory as they are published. It runs on Windows, macOS, and the major Linux distributions, plus ARM64 Linux, with no per host scan credentials [14].
Detection and response with the managed SOC and SIEM
If you run endpoint agents with the managed SOC, the agents on Windows and Linux servers and workstations collect security logs, file changes, and process activity. Clone Systems writes roughly 1,900 detection rules, checks correlation rules every minute, and runs event rules in real time. Incidents are mapped to MITRE ATT&CK, and analysts are available 24/7 [16][17].
A clear line on what monitoring can and cannot do: it is not a substitute for the patch, and we do not present the endpoint agents or the SIEM as preventing or blocking exploitation of these CVEs [16][17]. What they do is surface the signs that follow an attempt or a compromise: web server processes spawning shells, unexpected file changes in web roots, new accounts or persistence, PHP worker crashes and restarts, and memory limit errors or repeated HTTP 500 patterns in the logs. Those are the kinds of behaviors monitoring watches for, not guaranteed detections.
Where the agent supports it, the Clone Systems Linux agent can block an address, deny a host, disable an account, collect evidence remotely, and isolate the host; each action is confirmed before it runs. On Windows, response runs through your existing endpoint tool [17].
Nothing Clone Systems provides replaces the patch. Scanning finds the exposure, the agent keeps the inventory current, and the SOC watches for what happens when someone starts testing your PHP.
Frequently Asked Questions
What is PHP2Shell? PHP2Shell is the name for two critical PHP runtime vulnerabilities, CVE-2026-109618 (OOM corruption) and CVE-2026-109619 (stale global state), both rated CVSS v4.0 9.2. They allow unauthenticated remote code execution, and they are fixed in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35.
Which PHP versions are fixed? Versions below the fixed releases are vulnerable: 8.5 before 8.5.12, 8.4 before 8.4.27, 8.3 before 8.3.36, and 8.2 before 8.2.35. PHP 7.4, 8.0, and 8.1 are end of life and get minimal source backports, while 7.3 and older need an upgrade to a supported branch.
Is PHP2Shell being exploited? Yes, exploitation attempts are confirmed, including an attempt on Amazon's MadPot honeypots on October 17, four days before disclosure. Cloudflare has reported millions of attempts since the release, though neither CVE was in the CISA KEV catalog as of October 21, 2026.
How do I know if my PHP is patched? Check the running web SAPI with phpinfo(), then search the package changelog for the CVE. A version string alone can mislead you, because distributions backport fixes under older looking numbers.
Is WordPress affected? WordPress runs on PHP, and the flaw is in the PHP runtime, not the application or its plugins. Updating WordPress does not fix it; patch the server side PHP package to a fixed release.
Does Cloudflare protect me? If your traffic routes through Cloudflare, WAF rules for these CVEs went live to all plans, including Free, at 03:02 UTC on October 21, 2026. Cloudflare calls them a stopgap that covers only traffic through Cloudflare, and it still says to patch your PHP.
Does a WAF stop PHP2Shell? A WAF can only filter the traffic that passes through it; it cannot fix a flaw in an unpatched PHP runtime. Even Cloudflare, which shipped its rules early, calls the protection a stopgap.
Does PHP2Shell affect PCI compliance? An unpatched exposure on an internet facing system shows up as a CVSS 9.2 finding in an external ASV scan. A passing scan has no vulnerabilities scored CVSS 4.0 or higher, so the site fails until the PHP runtime is patched and a rescan confirms it.
Should I take my site offline? For an internet facing PHP system that cannot be fixed immediately, the UK NCSC advises taking it offline or isolating it. Interim measures reduce exposure, but they are not a substitute for the patch.
Does updating my application code fix it? No, the fix is the server side PHP package, not the application. Update PHP to the fixed release for your branch, restart every worker, and verify the changelog.
Do I have to check every PHP runtime? Yes: containers, appliances, hosting panels, and forgotten test boxes all count. One missed runtime leaves the exposure open, and each one should be verified with the package changelog, not the version string.
Is there public proof of concept code? Yes, PoC code is circulating. The PHP security team did not identify a functional exploit in the PoCs it inspected at release time, and unverified exploit code is sometimes laced with malware, so treat it with caution.
Conclusion
PHP2Shell is a reminder that the runtime is the real attack surface, not the application on top of it. Two memory bugs, more than a decade old in the original code path, found by AI assisted researchers and patched in one coordinated release, are now being tested in the wild.
Patch first. Verify the changelog second. Keep monitoring third, because the activity is already happening and the verification window is open right now.
Scan your external perimeter, run a credentialed scan for patch level truth, put the CloneGuard agent on the hosts that matter, and let the managed SOC watch the logs while you patch. Contact the Clone Systems team if you want a second pair of eyes on your PHP estate [18].
References
[1] PHP Security Team, "Security Advisory: Critical remote code execution vulnerabilities in PHP," October 21, 2026. https://www.php.net/archive/2026.php#2026-10-21-5 [2] Sansec Research, "PHP2Shell," updated October 22, 2026. https://sansec.io/research/php2shell [3] watchTowr Intel, "PHP Remote Code Execution (PHP2Shell CVE-2026-109618 & CVE-2026-109619)," October 21, 2026. https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/ [4] Carly Page, The Register, "Hackers pile on PHP2Shell as AWS reveals attacks began before disclosure," October 22, 2026. https://www.theregister.com/cyber-crime/2026/10/22/hackers-pile-on-php2shell-as-aws-reveals-attacks-began-before-disclosure/5304749 [5] The Hacker News, "PHP Issues Emergency Patches for Two Critical RCE Vulnerabilities," updated October 22, 2026. https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html [6] The PHP Foundation, "Today's PHP Security Release, and How We're Strengthening PHP Security," October 21, 2026. https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/ [7] Satnam Narang, Tenable, "php2shell (CVE-2026-109618, CVE-2026-109619): Frequently Asked Questions About Critical PHP Remote Code Execution," October 21, 2026. https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote [8] CISA Known Exploited Vulnerabilities catalog, catalog data through October 21, 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog [9] Mirko Zorz, Help Net Security, "PHP2Shell: Critical PHP vulnerabilities patched, update now!," updated October 22, 2026. https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/ [10] Cloudflare, "Cloudflare deploys protections against php2shell vulnerability," October 21, 2026. https://blog.cloudflare.com/php-vulnerabilities-waf-protection [11] PCI Security Standards Council, "PCI Data Security Standard (PCI DSS)." https://www.pcisecuritystandards.org/standards/pci-dss/ [12] Clone Systems, "Vulnerability Scanning Services." https://www.clone-systems.com/network-vulnerability-assessment-services/ [13] Clone Systems, "PCI ASV Scanning." https://www.clone-systems.com/pci-asv-scan-external-vulnerability-scanning/ [14] Clone Systems, "Agent-Based Scanning." https://www.clone-systems.com/agent-based-scanning/ [15] Clone Systems, "Credentialed Scanning." https://www.clone-systems.com/credentialed-scanning/ [16] Clone Systems, "Managed SOC Service." https://www.clone-systems.com/managed-soc-service/ [17] Clone Systems, "Managed SIEM and EDR." https://www.clone-systems.com/managed-siem-edr-service [18] Clone Systems, "Contact." https://www.clone-systems.com/contact [19] CISA, "Critical Vulnerabilities in PHP Require Immediate Patching," October 21, 2026. https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching