What our teams did in the hours after disclosure, and what I recommend you do next to reduce exposure across cloud, hybrid and on-premises environments.
When a critical runtime vulnerability is disclosed, two clocks start at once. The first measures how long exploit traffic can reach vulnerable systems. The second measures how long it takes to patch safely: finding every affected system, testing dependencies and coordinating change across security, application and operations teams. A good response shortens both, and it does not trade one for the other.
PHP2Shell started both clocks. CVE-2026-109618 and CVE-2026-109619 are critical memory-safety vulnerabilities in the PHP runtime. Both have been assigned a CVSS score of 9.2 and may be triggered by crafted, unauthenticated HTTP requests. Successful exploitation could lead to remote code execution or disclosure of sensitive data held in PHP process memory. Because the flaws are in the runtime itself rather than a specific application, framework or plug-in, you may be exposed even when your application is current and securely configured.
That is why my recommendation is twofold. First, apply Radware runtime protection quickly, so exploit traffic can be blocked before it reaches vulnerable systems. Second, upgrade PHP to a fixed release, because patching is what remediates the underlying vulnerability. Protection is intended to give your teams the time to patch carefully; it does not replace the patch.
For Radware customers, PHP2Shell protections are already available across our cloud and on-premises security solutions, including Cloud Application Protection, AI Xploit Shield, AppWall, Alteon WAF Integrated and DefensePro. These protections help reduce exposure while customers upgrade affected PHP environments. I will share more details in this blog on the protections available for each solution.
Why PHP2Shell Requires Immediate Attention
According to public descriptions, CVE-2026-109618 can be triggered when an out-of-memory condition interrupts PHP while internal request data is only partially initialized. CVE-2026-109619 involves request state remaining accessible after its memory has been freed, allowing that state to be reused by a later request handled by the same worker.
In successful exploitation scenarios, carefully constructed requests may turn these memory-handling flaws into remote code execution or information disclosure. Potentially exposed data could include credentials, session information, tokens, API keys or other data available to the PHP process.
This is also why application authentication alone may not be enough: exploitation can occur while the runtime is processing the request, before your application’s authentication or authorization logic is ever reached. We treat PHP2Shell as both a patching priority and a runtime-protection challenge, and I encourage you to do the same.
What's the Problem, and How Is It Exploited?
Both vulnerabilities are memory-safety flaws in the PHP runtime's handling of a request that is interrupted part-way through, not flaws in any application's own code. Public descriptions map the two as follows. CVE-2026-109618: an out-of-memory condition during request parsing can abort processing while internal request state is only partly set up, after which PHP operates on that incomplete state and corrupts memory. CVE-2026-109619: when a fatal error ends a request, PHP can be left holding references to memory that is freed as the request ends; a later request handled by the same worker process can follow those stale references (a use-after-free in PHP's session and serializer code), exposing memory or executing attacker-controlled code. According to the same public descriptions, both paths are reached through PHP's session upload-progress feature over multipart/form-data uploads.
Based on publicly available information, exploitation requires no authentication and no special privileges. The target must run an affected PHP version with the session upload-progress feature reachable (it is enabled by default) and must accept multipart/form-data uploads that reach PHP request parsing. The attacker drives the vulnerable code path with the PHP_SESSION_UPLOAD_PROGRESS form field; public proof-of-concept exploits carry their payload in the uploaded part's filename. Impact: Successful exploitation could allow an attacker to crash PHP worker processes (denial of service), read sensitive data held in memory such as secrets and credentials available to PHP, or run commands as the web-server account and pivot further into the environment.
Who is Affected?
Organizations running affected versions of PHP to serve web applications may be exposed. This appears to be an industry-wide PHP vulnerability, not an issue specific to a particular application or security vendor.
According to publicly available usage surveys, PHP is a widely deployed language on the web, used by large content-management and e-commerce applications such as WordPress and Magento. Exposure depends on the PHP version each deployment runs, so it may extend across the industry rather than any single application or framework.
According to public advisories, the affected PHP versions are 5.4.0 up to (but not including) 8.2.35, 8.3.0 to 8.3.36, 8.4.0 to 8.4.27, and 8.5.0 to 8.5.12. They are fixed in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. End-of-life branches (PHP 5.x, 7.x, 8.0, and 8.1) are not expected to receive an official fix under the PHP project's published support policy and should be migrated to a supported, patched release.
Protect First, Patch Safely
When PHP2Shell was disclosed, our response ran on two tracks at once. Our Vulnerability Research Team developed protections for our cloud services and on-premises products. In parallel, Radware AI Xploit Shield analyzed the vulnerabilities and available exploit information to generate targeted runtime protections. Once validated, those protections were prepared for deployment through the relevant Radware enforcement points.
| 1. Understand |
2. Protect |
3. Remediate |
| Analyze the vulnerability, affected request patterns and emerging exploit techniques. |
Generate, validate and deploy runtime protections across the applicable enforcement points. |
Upgrade PHP, restart affected services and confirm the fixed runtime is active. |
One point I want to be clear about: runtime protection is a compensating control, not a replacement for patching. Its job is to reduce your exposure while permanent remediation proceeds through a controlled process, especially when an emergency runtime change needs compatibility testing or could affect a business-critical service.
Rapid Protection Through Radware Cloud Services
Radware Cloud Application Protection customers can obtain protection through Signature Update October 2026, version 8.0.0.638, rule ID 12330. We rolled out PHP2Shell protection signatures across the service. Because enforcement runs through Radware’s cloud infrastructure, there are no signature packages to install on individual appliances. This is the type of situation the cloud delivery model is designed to address: we analyze an emerging threat, validate the protection and distribute it across the cloud service rapidly.
You should still identify and upgrade affected PHP environments. Cloud-delivered protection is designed to reduce exposure while you remediate, but the underlying vulnerability remains until PHP is updated.
AI Xploit Shield: From Vulnerability Intelligence to Runtime Protection
AI Xploit Shield generated three custom signatures, ready to deploy into customer security policies. Traditional web application firewalls generally provide an essential baseline against common attack classes, including command injection, SQL injection, cross-site scripting, path traversal and protocol anomalies. Newly disclosed vulnerabilities, however, may involve unfamiliar payloads, request sequences or combinations of parameters that are not yet represented in an existing signature set.
Radware AI Xploit Shield adds a vulnerability-driven protection layer. It is intended to analyze supported penetration-test and vulnerability-scanner findings, determine whether existing Radware controls already address the risk and generate a tailored signature or a supported configuration change when additional protection is required. The protection can then be validated and deployed through Radware’s cloud infrastructure using the selected enforcement mode. In my experience, it is most valuable where patching can’t happen overnight:
- Business-critical applications that require testing before a runtime upgrade
- Legacy applications with complex software dependencies
- Third-party systems where customers do not control the development lifecycle
- Large application estates where remediation must be prioritized and phased
- Custom applications with environment-specific exposure paths
Protection for Alteon, AppWall and Radware WAF for Kubernetes Customers
If you operate Radware AppWall or Alteon WAF Integrated deployments, you can obtain PHP2Shell protection through WAF Signature Update October 2026, version 8.0.0.638, rule ID 12330.
- Verify the signature version currently installed and the timing of the next scheduled update.
- When immediate protection is required, initiate the applicable update rather than waiting for the normal schedule.
- Confirm successful installation and review the relevant security policy and enforcement settings.
- Engage Radware Technical Support before making changes in a sensitive production environment if assistance is required.
Protection for DefensePro Customers
For DefensePro, we released PHP2Shell protection in Signature File version 0009_0851_00, rule ID 22156.
- Verify the signature-file version installed on the relevant DefensePro devices.
- Initiate the applicable update when immediate coverage is required.
- Confirm that the update completed successfully and continue monitoring security events through established operational processes.
What I Recommend You Do Now
1. Apply the relevant Radware protection
Cloud Application Protection customers already receive the cloud-delivered protection. AI Xploit Shield customers should validate the applicable targeted protections with their Radware team. AppWall and Alteon WAF Integrated customers should install WAF Signature Update October 2026, version 8.0.0.638. DefensePro customers should install Signature File version 0009_0851_00.
2. Identify affected PHP environments
Inventory internet-facing applications and determine the PHP runtime version used by each environment. Include custom applications, APIs, administrative interfaces, content-management systems, commercial software, legacy services and hosted applications.
3. Upgrade PHP
Move affected environments to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, as appropriate. Organizations using older branches should migrate to a supported fixed version or obtain a patched package from their operating system or hosting provider. Restart services using PHP so active workers load the corrected runtime.
4. Investigate suspicious activity
Review application, WAF, web-server, endpoint and infrastructure telemetry for abnormal HTTP POST activity, unusual multipart requests, unexpected PHP or web-server memory errors, unexplained processes launched by the web-server account, unauthorized content changes and suspicious access to sensitive files or credentials.
5. Continue monitoring
Vulnerability research and exploit techniques may evolve after disclosure. Continue monitoring PHP security notices, Radware advisories and relevant signature updates after applying the initial protection.
Technical Resources
Disclaimer: This blog post is provided for general informational purposes only and reflects the views and understanding of the author as of the date of publication. It does not constitute legal, or other professional advice, and it does not create any warranty, guarantee or contractual commitment by Radware. Information about third-party software, vulnerabilities, versions and advisories (including PHP, related CVE identifiers and CVSS scores) is based on publicly available sources that Radware has not independently verified, may change as new information emerges, and should be confirmed against the official sources, such as the PHP project and the National Vulnerability Database. Product availability, features and signature coverage may vary by product, version and subscription, and may be modified without notice.
All product and company names are the property of their respective owners and are mentioned for identification purposes only, with no affiliation or endorsement implied. Statements about Radware's products, capabilities and response efforts describe Radware's own offerings and are not comparisons with those of any other party.
This post may contain forward-looking statements, including statements about expected product performance, which are subject to risks and uncertainties, and Radware undertakes no obligation to update them except as required by law. Customers should consult their Radware representative and their own advisors regarding their specific circumstances.