PHP2Shell: Critical PHP Vulnerabilities, What to Do About Them

Two critical PHP core vulnerabilities disclosed on October 21, 2026 under the name PHP2Shell — CVE-2026-109618 and CVE-2026-109619, each rated CVSS 9.2 — allow unauthenticated attackers to achieve remote code execution and leak sensitive data from PHP process memory, with Wiz Research demonstrating exploits against WordPress, Drupal, and Joomla. The flaws sit in the PHP runtime itself, so applications can be exposed even when their own code is secure, and the bugs had existed for years before AI helped researchers turn the memory-safety issues into working exploits. Fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12; Astra advises patching, restarting PHP workers, and confirming the version actually running in production.

PHP powers roughly 70% of websites on the internet. WordPress, Drupal, Joomla, and thousands of custom applications run on it. At Astra, we’ve spent years protecting these applications with firewalls, malware scanning, and vulnerability detection. So when vulnerabilities show up in PHP’s core engine, it’s worth paying attention. On October 21, 2026, two critical PHP vulnerabilities were publicly disclosed under the name PHP2Shell . Both carry a CVSS score of 9.2 and can allow unauthenticated attackers to execute code on vulnerable servers. The interesting part isn’t just the severity. These bugs had existed for years. AI helped researchers turn complex memory-safety issues into working exploits. Here’s what happened, how the vulnerabilities work, and what you should do about them. Key takeaways - PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each rated CVSS 9.2. - The flaws sit in the PHP runtime itself, so WordPress, Drupal, Joomla, and custom PHP applications can be exposed even when their own code is secure. - Exploitation can lead to unauthenticated remote code execution RCE and leakage of sensitive data from PHP process memory. - Fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Patch, restart PHP workers, and confirm the version actually running in production. What is PHP2Shell? PHP2Shell refers to two CVEs affecting PHP’s core engine: | CVE | Severity | Key issue | |---|---|---| | CVE-2026-109618 | CVSS 9.2 | Upload-progress handling, memory corruption, and process-memory disclosure | | CVE-2026-109619 | CVSS 9.2 | Stale internal state and OPcache type confusion | The important distinction is that these are not WordPress plugin vulnerabilities or bugs in a particular CMS. The underlying issues exist in PHP itself. Wiz Research demonstrated unauthenticated remote code execution against WordPress, Drupal, and Joomla. But these are examples of affected applications, not an exhaustive list. A vulnerable PHP runtime can expose an application even when its own code is secure. How do the PHP2Shell vulnerabilities work? To understand PHP2Shell, you need to understand two concepts: use-after-free and type confusion. A use-after-free happens when software continues using a piece of memory after it has been released. A type-confusion bug happens when software interprets data as the wrong kind of object. Both can be dangerous because they allow an attacker to influence how a program reads, writes, or interprets memory. 1. CVE-2026-109618: PHP’s upload-progress handling PHP supports a feature called session upload progress. It lets applications track the progress of file uploads. The problem identified by Wiz involves how PHP handles internal state during request processing, particularly when an out-of-memory error interrupts normal execution. If PHP fails partway through processing a request, its cleanup routines may encounter internal data that was never fully initialized or that points to memory that has already been released. Under the right conditions, a subsequent request can interact with this stale state. Wiz demonstrated that this family of issues could be used to corrupt PHP process memory and achieve unauthenticated RCE on WordPress, Drupal, and Joomla. The researchers also demonstrated a related memory-disclosure issue that could expose sensitive data from a PHP worker. That data could include credentials, tokens, or API keys belonging to other requests. The security implication is important: a memory-safety flaw can expose more than the application handling the request. It can potentially expose data held in the same process. 2. CVE-2026-109619: Stale state and OPcache The second CVE involves additional problems with internal state retained across requests and with OPcache, PHP’s bytecode caching system. PHP workers and OPcache maintain internal references to objects and memory. Those references must remain valid as requests finish, new requests begin, and cached code is managed. If a reference survives after the memory it points to has been released, later execution can access invalid state. Separately, inconsistencies in how OPcache tracks runtime objects can cause a memory slot to be interpreted as an object of the wrong type. These are different exploitation paths, but both create opportunities for memory corruption. Wiz demonstrated unauthenticated RCE against Drupal and WordPress using the relevant exploit paths. The important point is that these are runtime-level weaknesses. Fixing a CMS plugin or reviewing application code alone does not resolve them. Why PHP2Shell is different from other PHP vulnerabilities There are three things worth paying attention to. 1. The attack surface is much larger than a single application. PHP runs across hosting providers, containers, CMS platforms, and custom applications. Security teams may not even have a complete inventory of every PHP runtime in their environment. 2. Memory disclosure can make exploitation easier. An attacker does not always need to jump straight to code execution. Information leaked from process memory can reveal addresses, credentials, or other data that makes subsequent exploitation easier. 3. AI changes the economics of exploit development. According to Wiz, frontier AI models helped researchers discover these issues and develop working exploits. The process involved chaining bugs, adapting to different memory layouts, testing, and debugging. This is where I think the bigger story lies. The code had existed for years. The fact that a bug has survived for a long time does not mean it is safe. And complexity is becoming a weaker barrier when AI can help researchers reason through it and iterate on working exploits. That cuts both ways. Attackers can move faster, but defenders can also use AI to find weaknesses and improve detection before they are exploited. Disclosure timeline The responsible disclosure process unfolded as follows: | Date | Event | |---|---| | August 19, 2026 | Wiz Research discovered the first vulnerability | | August 20, 2026 | Unauthenticated RCE was confirmed against Drupal | | August 21, 2026 | Unauthenticated RCE was confirmed against WordPress | | August 24, 2026 | The findings were reported to the PHP security team | | September 21, 2026 | PHP acknowledged the reports and began developing a coordinated fix | | October 21, 2026 | Fixed PHP releases became available and the vulnerabilities were publicly disclosed | The response required coordination between the PHP team, researchers, and security providers preparing patches, detections, and mitigations. How to fix PHP2Shell Patching is the primary remediation. Which PHP versions have a PHP2Shell patch? Official patched releases exist only for the four PHP branches that still receive security support. Every older branch is affected but has no official patched release. | PHP branch | PHP2Shell fix status | Security support until | |---|---|---| | PHP 8.5 | Patched in 8.5.12 | Dec 31, 2029 | | PHP 8.4 | Patched in 8.4.27 | Dec 31, 2028 | | PHP 8.3 | Patched in 8.3.36 | Dec 31, 2027 | | PHP 8.2 | Patched in 8.2.35 | Dec 31, 2026 ending soon | | PHP 7.4, 8.0, 8.1 | No official release. Minimal source backports only | End of life | | PHP 5.4 to 7.3 | No fix from the PHP project | End of life | Running PHP 8.1 or older? Upgrade to a supported branch, install a backported package from your Linux distribution or LTS vendor, or build PHP from source with the PHP security team’s backports for 7.4, 8.0, and 8.1. Systems older than PHP 7.4 should be upgraded, isolated, or decommissioned. Running PHP 8.2? Patch to 8.2.35 now, but plan a move to 8.3 or newer. Security support for 8.2 ends on December 31, 2026. Check the PHP security advisories for CVE-2026-109618 https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w and CVE-2026-109619 https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp for the technical details and remediation guidance. If your PHP comes from an operating system or hosting provider, check its advisory for the patched package. Distributions often backport fixes without changing the version number, so the version string alone may not tell you whether you are protected. Here’s what I’d prioritize: 1. Find every PHP runtime. Inventory PHP across web servers, containers, CMS installations, and applications managed by other teams. Don’t limit the audit to your primary production application. 2. Patch and verify. Install the appropriate fixed release. Restart PHP-FPM, web servers, and long-running workers as required. Verify the version actually running in production. Updating WordPress or another application does not update the PHP runtime beneath it. 3. Update WAF rules. Apply available protections from your WAF provider. These can provide an additional layer of defense, but the PHP security update remains essential. 4. Investigate potential exploitation. Review web server and application logs for unusual requests, unexpected PHP worker errors, unexplained process activity, and suspicious outbound connections. These signals are not proof of exploitation, but they can help guide an investigation. 5. Check older and less visible environments. Staging systems, forgotten CMS installations, legacy applications, and third-party managed servers are easy to miss. They still matter if they are exposed to the internet. How Astra helps customers detect PHP2Shell At Astra, our focus is not just finding vulnerabilities. It’s helping customers understand where they are exposed and what needs to be fixed. Astra’s Autonomous Pentest https://www.getastra.com/autonomous-pentesting and DAST https://www.getastra.com/dast capabilities are actively detecting PHP2Shell vulnerabilities for our customers. DAST helps identify exposure in running web applications, while Autonomous Pentest goes further by testing applications for exploitable weaknesses and validating attack paths https://www.getastra.com/blog/penetration-testing/how-autonomous-pentesting-kills-false-positives/ . This distinction matters. Knowing that a vulnerable technology exists in your environment is useful, but understanding whether an exposed application can be attacked helps security teams prioritize remediation. Detection is not a substitute for patching. Customers should still update affected PHP runtimes and verify remediation. A busy week for security teams PHP2Shell is not happening in isolation. This week has also brought a compromised LiteLLM release containing credential-stealing malware, a Railway security incident involving customer environment variables, and the disclosure of compromised eMudhra intermediate certificate keys. These are different incidents with different root causes. But they point to a shared challenge: trust in the software, infrastructure, and cryptographic systems we depend on. A vulnerable runtime, a compromised software release, exposed environment secrets, and compromised certificate keys are not the same problem. Yet each can create consequences far beyond the original component. For security teams, this is why asset inventory, dependency visibility, credential hygiene, and continuous validation matter. You cannot respond quickly to a risk you don’t know exists. The response also cannot stop at a single scan or a single patching cycle. Systems change, new vulnerabilities emerge, and yesterday’s trusted dependency can become tomorrow’s incident. Final thoughts PHP2Shell is a reminder that application security https://www.getastra.com/blog/security-audit/web-application-security/ does not stop at application code. Your application can be well written and still inherit serious risk from the runtime it depends on. The immediate priority is straightforward: identify affected runtimes, patch them, and investigate anything suspicious. The longer-term lesson is about AI. Vulnerabilities that were difficult to discover and exploit are becoming more accessible to researchers. Defenders need to use these same advances to discover weaknesses earlier and reduce the time between disclosure and remediation. The goal is not just to know which vulnerabilities exist. It’s to know where you’re exposed, validate the risk, and fix it before someone else gets there. PHP2Shell FAQs What is PHP2Shell? PHP2Shell is the name given to two critical vulnerabilities in PHP’s core engine, CVE-2026-109618 and CVE-2026-109619. Both are rated CVSS 9.2 and were publicly disclosed on October 21, 2026, together with fixed PHP releases. Which PHP versions fix the PHP2Shell vulnerabilities? Official fixes are available in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. PHP 8.1 and older are end of life and have no official patched release. The PHP security team published minimal source backports for 7.4, 8.0, and 8.1, and some Linux distributions and LTS vendors ship backported packages. Versions older than 7.4 have no fix from the PHP project. Does updating WordPress, Drupal, or Joomla fix PHP2Shell? No. PHP2Shell lives in the PHP runtime, not in CMS code or plugins. Updating your CMS leaves the vulnerable runtime in place, so the PHP installation itself must be upgraded and its workers restarted. Why are these PHP vulnerabilities considered so serious? They can allow unauthenticated remote code execution, and one exploit path can leak data from PHP process memory, such as credentials or API keys belonging to other requests. Because PHP runs a large share of the web, the potential attack surface is very large. Can a WAF protect against PHP2Shell? WAF rules from your provider can add a layer of defense while patches roll out, but they do not replace the PHP security update. How do I check if my applications are exposed to PHP2Shell? Inventory every PHP runtime you operate, including staging, legacy, and third-party managed servers, then verify the version running in production. Astra’s DAST and Autonomous Pentest can help identify exposed applications and validate whether they can be attacked. Who discovered PHP2Shell, and when was it disclosed? Wiz Research discovered the first vulnerability on August 19, 2026, and confirmed unauthenticated RCE against Drupal and WordPress within two days. The findings were reported to the PHP security team on August 24, 2026. PHP acknowledged the reports on September 21, 2026, and fixed releases and public disclosure followed on October 21, 2026. How does CVE-2026-109618 work? CVE-2026-109618 abuses PHP’s session upload progress handling. If an out-of-memory error interrupts a request partway through, PHP’s cleanup routines can touch internal data that was never fully initialized or that points to memory already released. A later request can then interact with that stale state, which Wiz used to corrupt process memory and achieve unauthenticated RCE. A related path can disclose data held in the PHP worker’s memory. How does CVE-2026-109619 work? CVE-2026-109619 involves internal state that PHP keeps across requests and OPcache, PHP’s bytecode cache. If a reference survives after its memory has been released, later execution can access invalid state, which leads to a use-after-free. Separately, inconsistencies in how OPcache tracks runtime objects can cause a memory slot to be read as an object of the wrong type. Both paths create opportunities for memory corruption. What should I do if I’m running PHP 8.1 or older? PHP 8.1 and older are end of life, so there is no official patched release. Upgrade to a supported branch, install a backported package from your Linux distribution or LTS vendor, or build PHP from source using the PHP security team’s backports for 7.4, 8.0, and 8.1. Systems older than PHP 7.4 should be upgraded, isolated, or decommissioned. Why doesn’t the PHP version number always show whether I’m protected? Operating system vendors and hosting providers often backport security fixes without changing the PHP version number. If your PHP comes from one of them, check their advisory for the patched package instead of relying on the version string alone. After patching, restart PHP-FPM, web servers, and long-running workers, then confirm the version actually running in production. What role did AI play in the PHP2Shell research? According to Wiz, frontier AI models helped researchers discover these issues and develop working exploits, including chaining bugs, adapting to different memory layouts, testing, and debugging. The vulnerable code had existed for years. The lesson is that complexity is a weaker barrier than it used to be, for attackers and defenders alike. What signs of PHP2Shell exploitation should I look for? Review web server and application logs for unusual requests, unexpected PHP worker errors, unexplained process activity, and suspicious outbound connections. These signals are not proof of exploitation, but they help focus an investigation. Because one exploit path can leak credentials or API keys from other requests, consider rotating secrets on any system where you find suspicious activity. Is Astra’s detection a substitute for patching PHP2Shell? No. Astra’s DAST and Autonomous Pentest help identify exposed applications and validate whether attack paths are exploitable, which helps you prioritize remediation. You should still update every affected PHP runtime and verify the fix.