On October 21, 2026, the PHP development team released emergency security updates addressing two critical vulnerabilities in the PHP runtime: CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell.
Both vulnerabilities received a CVSS v4.0 score of 9.2 and could potentially enable unauthenticated remote code execution (RCE), putting affected applications and the systems they connect to at risk.
The scale of potential exposure is significant. According to W3Techs, PHP powers approximately 69.3% of websites with a known server-side programming language.
What makes PHP2Shell particularly concerning is that the vulnerabilities exist within the PHP runtime itself. Even applications built with secure coding practices may be exposed, without an exploitable flaw in their own source code.
This article examines how both vulnerabilities work, their potential impact, the affected PHP versions, and the steps organizations should take to reduce their exposure.
If your organization’s assets are currently at risk, see how Conviso can help right now.
PHP2Shell: Fixed Versions and Immediate Actions
Organizations running affected PHP environments should prioritize immediate remediation. The following overview highlights the fixed PHP releases and the essential steps security teams should take to identify exposure, deploy updates, and investigate potential compromise.
PHP2Shell: Disclosure and Exploitation Timeline
The PHP2Shell disclosure followed months of coordinated security research and remediation. Threat intelligence published after the release also revealed exploitation attempts predating public disclosure. All dates are UTC:
- August 11, 2026: Calif and OpenAI independently report the underlying out-of-memory vulnerability to the PHP security team. Wiz reports additional attack vectors on August 24, and OpenAI reports further vectors on September 18.
- October 17, 2026: Amazon Threat Intelligence identifies a PHP2Shell exploitation attempt in MadPot telemetry originating from
103.216.220[.]92, four days before public disclosure. - October 20, 2026: CVE identifiers circulate publicly alongside incorrect severity information. The coordinated security release, originally planned for October 22, is moved forward to October 21.
- October 21, 2026, 14:00 UTC: The scheduled coordinated disclosure takes place. PHP announces security releases 8.5.12, 8.4.27, 8.3.36, and 8.2.35, addressing CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0.
Amazon's findings reinforce the need to investigate potential exploitation before the public disclosure date, rather than assuming that attacks began only after patches became available.
Understanding the Vulnerabilities
PHP is widely used to build websites, APIs, content management systems, and enterprise applications. It powers platforms such as WordPress, Drupal, and Joomla, as well as numerous custom applications.
Its runtime processes incoming HTTP requests, manages memory, initializes internal structures, executes application code, and releases resources when requests finish.
The two newly disclosed vulnerabilities affect how PHP manages internal memory and request-specific state:
- CVE-2026-109618 (CVSS 9.2)
Root cause: memory corruption during out-of-memory handling.
Potential impact: remote code execution. - CVE-2026-109619 (CVSS 9.2)
Root cause: stale internal state after memory deallocation.
Potential impact: remote code execution.
The most concerning aspect is that exploitation may occur without requiring authentication or an application-specific vulnerability.
CVE-2026-109618: Memory Corruption During Out-of-Memory Handling
CVE-2026-109618 affects how PHP handles memory allocation failures during request processing.
During normal execution, PHP initializes internal data structures and allocates memory to process incoming requests.
However, when memory allocation fails, execution may be interrupted while certain internal structures remain partially initialized.
The subsequent cleanup process can incorrectly treat these structures as valid, potentially resulting in memory corruption.
At a high level, the vulnerable behavior can be described as:
- An incoming request causes PHP to allocate and initialize internal structures.
- A memory allocation failure interrupts initialization.
- The runtime enters an error-handling or cleanup path.
- Cleanup logic processes data that may not have been fully initialized.
- Memory corruption creates a potential path toward code execution.
A Closer Look at the Vulnerable Code
A concrete example of the underlying memory-safety issue can be found in PHP's Zend Engine, particularly in the hash table implementation (Zend/zend_hash.c).
In the affected code path, the hash table's internal counters may be updated before a new key has been successfully allocated. If memory allocation fails at that point, execution can terminate while the table still reports an entry that was never fully initialized.
The relevant sequence can be simplified as follows:
idx = ht->nNumUsed++;
ht->nNumOfElements++;
p = ht->arData + idx;
p->key = key = zend_string_init(
str, len, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT);
The critical issue is the ordering of operations: the table records a new entry before the allocation that makes that entry valid has completed.
If the allocation triggers an out-of-memory bailout, subsequent cleanup may process the incomplete entry as though it were fully initialized, creating a memory-corruption risk.
The official PHP remediation also addresses the broader out-of-memory handling mechanism, replacing unsafe early exits with a more controlled failure strategy.
References: PHP Security Advisory · Red Hat Technical Analysis
This vulnerability illustrates why memory safety remains important even in environments typically associated with higher-level programming languages.
Although application developers primarily write PHP code, parts of the runtime are implemented in native code, where incorrect memory management can introduce serious security weaknesses.
According to the PHP security advisory, the risk is particularly significant for deployments using Apache with mod_php, where an unauthenticated request may trigger the vulnerable behavior before application code executes.
CVE-2026-109619: Stale Global State Across Requests
CVE-2026-109619 involves a different memory-management problem.
PHP workers may process multiple requests during their lifetime. While request-specific resources should be properly initialized and released, some internal state may remain accessible after the memory supporting it has been freed.
This creates a stale-state condition.
A subsequent request handled by the same worker may interact with invalid internal state before normal initialization resets it.
The high-level sequence is:
- A request creates or modifies internal PHP state.
- The request terminates and its backing memory is released.
- A reference to that state remains accessible.
- A later request is processed by the same worker.
- The runtime may access the stale reference, creating a potential memory-safety violation.
A Closer Look at the Vulnerable State
The root cause of CVE-2026-109619 lies in how the PHP runtime manages global state that references request-owned memory.
A confirmed example involves fatal error backtrace handling in PHP 8.5. When fatal_error_backtraces is enabled, fatal error processing can store backtrace information in global state associated with the worker. If that state is not reset during shutdown, the worker may retain a reference after the request's memory has been released.
A subsequent request handled by the same worker can trigger a diagnostic before normal request initialization, causing PHP to access the stale reference.
The underlying lifecycle can be illustrated with the following simplified pseudocode:
/* Request A: publish request-owned state */
worker_global.backtrace = request_backtrace;
/* Request A ends: memory is released */
release_request_memory();
/* Missing reset leaves a stale reference */
/* Request B: early diagnostic accesses state */
process_diagnostic(worker_global.backtrace);
Illustrative pseudocode, not an excerpt from the PHP source code.
The critical issue is the mismatch between the lifetime of request-owned memory and the lifetime of the worker's global state. A pointer remains accessible beyond the lifetime of the memory it references.
This is a use-after-free (CWE-416) condition that can lead to memory disclosure or, under exploitable conditions, remote code execution.
The official advisory also documents a separate confirmed path involving session upload progress, where session-related state can survive an interrupted request and be accessed during the processing of a later request.
Reference: PHP Security Advisory: CVE-2026-109619
This issue is especially relevant because the vulnerability crosses request boundaries.
A security weakness introduced during one request may influence how the runtime handles a later request, making the problem fundamentally different from typical application-level input validation failures.
PHP2Shell Fix: How PHP Redesigned Out-of-Memory Handling
The PHP2Shell remediation goes beyond correcting individual memory-safety errors. For supported PHP branches, the security update introduces broader changes to how the runtime handles out-of-memory conditions and manages internal state during error recovery.
Replacing Unsafe Bailouts with Controlled Error Handling
Before the fix, an out-of-memory condition could trigger an abrupt execution bailout while internal structures were only partially initialized. Subsequent cleanup operations could then encounter inconsistent data, creating opportunities for memory corruption.
The updated implementation introduces a more controlled failure-handling mechanism, including changes associated with UnwindExit. Instead of immediately interrupting execution at potentially unsafe points, PHP can allow certain memory allocations to complete before reporting an out-of-memory error.
This reduces the risk of leaving internal structures in an inconsistent state during error handling.
Introducing a Separate Hard Memory Limit
The update also introduces a new PHP configuration directive:
memory_hard_limit_percent
With the updated behavior, memory_limit acts as a soft limit in many allocation scenarios. A separate hard ceiling prevents memory consumption from growing indefinitely.
The default hard-limit behavior described in the patch is:
- For memory limits below 1 GB, the hard ceiling is generally 200% of
memory_limit. - For larger memory limits, the hard ceiling provides an additional 1 GB of headroom.
- When the hard ceiling is exceeded, PHP terminates the process through
_exit(137).
This distinction allows the runtime to defer certain failures until a safer execution point while retaining a mechanism to stop excessive memory consumption.
Correcting Internal State Management
The full security update also addresses the lifecycle of internal global state, reducing the risk that references to request-owned memory remain accessible after that memory has been released.
This is particularly relevant to CVE-2026-109619, where stale references can create use-after-free conditions across requests handled by the same PHP worker.
Together, these changes address the underlying failure-handling and state-management problems rather than relying exclusively on disabling individual vulnerable features.
Affected PHP Versions and Environments
According to the PHP security team and Google Cloud, the vulnerabilities affect PHP versions from 5.4 through 8.5.11.
The following security releases address both vulnerabilities:
PHP 8.1 and earlier versions are no longer supported by the regular upstream release process. However, some operating system vendors and long-term-support providers may supply backported fixes.
The PHP security team has also made minimal source backports available for selected older branches. Organizations should verify the actual patch status of their deployed packages rather than relying exclusively on version strings.
Affected deployment models may include:
- Apache with mod_php
- PHP-FPM
- PHP-CGI
- FrankenPHP
- LiteSpeed
- Containerized PHP applications
- Third-party products embedding vulnerable PHP runtimes
The PHP security team considers mod_php particularly high risk because of a demonstrated attack path that can be reached before application code executes.
PHP2Shell: What Is the Real Impact?
Although both PHP2Shell vulnerabilities can potentially lead to unauthenticated remote code execution, their exploitation mechanisms introduce distinct security risks.
CVE-2026-109618: Code Execution During Request Processing
This vulnerability can be triggered when PHP encounters an out-of-memory condition while processing request data. The resulting memory corruption may be exploited during request cleanup, potentially before the application's own code begins executing.
Potential impact: An attacker may achieve code execution without exploiting a flaw in the application's business logic or bypassing its authentication mechanisms. Successful exploitation could expose application credentials, sensitive data, and other resources accessible to the PHP process.
CVE-2026-109619: Exploitation Across Requests
This vulnerability involves an internal PHP state that remains accessible after its underlying memory has been freed. A subsequent request handled by the same PHP worker may interact with that stale state, creating an opportunity for memory corruption and code execution.
Potential impact: An attacker may exploit the reuse of PHP worker processes to achieve code execution across request boundaries. This makes persistent PHP worker environments particularly relevant when assessing exposure.
Why This Matters for Organizations
In both cases, successful exploitation may give an unauthenticated attacker the privileges of the affected PHP process, potentially enabling credential theft, unauthorized data access, service disruption, or further compromise of connected systems.
The critical distinction is that PHP2Shell can expose applications through the runtime itself, even when the application code contains no directly exploitable vulnerability.
PHP2Shell Remediation: How Organizations Should Respond
The PHP security team states that updating to a fixed version is the only complete remediation.
Temporary mitigations may reduce exposure to known attack paths, but they do not eliminate the underlying vulnerabilities.
Step 1: Identify Affected Assets
Security teams should inventory PHP installations across production, staging, development, containers, and third-party products.
A useful starting point for a local installation is:
php -v
However, the CLI version may differ from the PHP runtime serving web requests. Organizations should verify the version and patch status of each actual serving process, container image, and managed runtime.
For containerized environments, security teams should inspect base images and deployed artifacts rather than relying only on application dependency manifests.
Step 2: Prioritize Based on Exposure and Business Criticality
Not every vulnerable asset presents the same operational risk.
Prioritization should consider internet exposure, affected runtime, application criticality, sensitive data access, process privileges, and available security controls.
For example, an internet-facing payment application using a vulnerable PHP runtime may require a more urgent response than an isolated internal development environment.
Both require remediation, but the order should reflect their potential business impact.
Step 3: Apply Security Updates
Organizations should upgrade affected PHP runtimes to the fixed versions or install verified vendor-supported security backports.
For containerized environments, remediation may require rebuilding images, redeploying applications, and verifying that running workloads no longer contain vulnerable PHP components.
After applying updates, restart all PHP workers and validate that the patched runtime is effectively loaded.
Step 4: Apply Official Temporary Mitigations When Patching Is Not Immediately Possible
If immediate patching is not feasible, the PHP security team recommends configuration-based measures to reduce exposure to known exploitation paths.
For CVE-2026-109618, the recommended temporary measures include:
memory_limit = -1
post_max_size = 8M
The memory_limit setting must be enforced at the server or PHP-FPM pool level so applications cannot override it. The post_max_size value should be adjusted according to legitimate upload requirements; environments requiring file uploads may need a higher limit, such as 32M. Appropriate container or cgroup memory limits should also be enforced.
For CVE-2026-109619, disable session upload progress:
session.upload_progress.enabled = 0
Additionally, for PHP 8.5 environments, disable fatal error backtraces:
fatal_error_backtraces = 0
After changing these settings, restart all PHP workers and verify the effective configuration in the web-serving runtime.
Important: These mitigations address specific exploitation paths and do not fully eliminate either vulnerability. Organizations should prioritize upgrading to a patched PHP release as soon as possible.
For complete deployment-specific instructions, consult the official PHP security advisories.
Step 5: Validate Remediation and Investigate Suspicious Activity
After deployment, security teams should verify the effective runtime version and patch status, not merely whether a package update was requested.
They should also review relevant security telemetry for suspicious process execution, abnormal request patterns, unexpected file modifications, and indicators of possible compromise.
A successful patch does not automatically establish that a previously vulnerable system was never compromised.
What PHP2Shell Teaches Us About Application Security
PHP2Shell is a reminder that application security risks do not begin and end with application code.
Even organizations that follow secure development practices can face critical exposure when vulnerabilities emerge in the technologies their applications depend on. And when a threat is disclosed, the real challenge is not simply understanding the vulnerability. It is knowing which applications are exposed, what is at stake, and how quickly teams can respond.
This is where the maturity of an AppSec program is put to the test.
A mature program connects application visibility, business context, vulnerability intelligence, and coordinated remediation. It enables organizations to move from reacting to individual CVEs to managing risk continuously, before the next critical vulnerability forces an emergency response.
The lesson of PHP2Shell is clear: organizations cannot prevent every new vulnerability, but they can build the capability to understand their exposure and respond before a technical weakness becomes a business crisis.
Are you prepared for the next global attack?
How Conviso Platform Can Help Organizations Manage Similar Risks
Addressing critical vulnerabilities requires more than identifying a CVE. Organizations need to understand where the affected technology is deployed, how exposed each application is, and whether remediation has been completed.
The Conviso Platform provides capabilities that can support these activities throughout the application security lifecycle.
Risk Insights: Application Visibility and Risk Context
Risk Insights helps organizations organize application assets, understand their business criticality, and consolidate application security risks.
In a scenario involving critical runtime vulnerabilities, this context can help security teams identify which applications should be investigated and remediated first.
The value lies in connecting technical exposure to business impact.
Vuln Intelligence: Consolidation and Prioritization
Vuln Intelligence consolidates findings from multiple security sources, including SAST, DAST, SCA, penetration tests, and external scanners.
When PHP runtime exposure is identified by an appropriate source and ingested into the platform, these findings can be correlated with application context and prioritized for remediation.
This reduces the need to manage critical findings across disconnected tools and spreadsheets.
AI Secure Code: Software Composition and Development Security
AI Secure Code provides SAST, SCA, SBOM, secrets detection, and infrastructure-as-code analysis capabilities.
These controls can help teams maintain visibility over application components and identify relevant security weaknesses during development.
However, PHP runtime vulnerabilities require special consideration.
A PHP interpreter installed in an operating system package or container base image may not appear in an application's Composer dependency manifest.
Therefore, detecting these specific CVEs requires appropriate runtime, operating-system package, or container-image visibility. Application SCA alone should not be considered sufficient.
Web and API Scan: Continuous Application Testing
Web and API Scan supports recurring security assessments of web applications and APIs.
This can help organizations identify application-level weaknesses and maintain testing coverage throughout the development lifecycle.
Nevertheless, dynamic scanning should not be presented as a guaranteed detection method for PHP2Shell.
The underlying memory-safety flaws may not be observable through conventional application vulnerability checks, and active exploitation attempts may introduce operational risk.
Web and API Protection: Defense in Depth
Web and API Protection provides edge-based application protection capabilities, including WAF functionality.
Appropriately configured WAF controls may help reduce exposure to selected malicious request patterns while patches are deployed.
However, protection against PHP2Shell must be validated against the relevant attack techniques and supported rules.
A WAF is not a substitute for updating the vulnerable PHP runtime.
Conclusion
CVE-2026-109618 and CVE-2026-109619 demonstrate that critical application security risks do not always originate in application source code.
Vulnerabilities in language runtimes, infrastructure components, and shared dependencies can expose otherwise well-developed applications to serious threats.
The immediate priority is clear: identify affected PHP deployments, apply verified security updates, investigate potential compromise, and validate remediation.
The broader lesson is equally important.
Organizations need continuous visibility into their application ecosystem, contextual vulnerability prioritization, and coordinated remediation processes.
A mature AppSec program connects these activities, helping security and development teams respond effectively when critical vulnerabilities emerge.
Learn how Conviso Platform can help your organization centralize application security risks, prioritize remediation, and strengthen its AppSec program.
References
Official Security Advisories and Disclosures
- PHP Security Advisory, October 21, 2026
- CVE-2026-109618, PHP Security Advisory
- CVE-2026-109619, PHP Security Advisory
- PHP Foundation: PHP Security Release and Security Improvements
Technical Fixes and Source Code
- PHP 8.2: Full Out-of-Memory and Global State Fix
- PHP 7.4: Minimal Security Mitigation
- PHP 8.0: Minimal Security Mitigation
- PHP 8.1: Minimal Security Mitigation
- PHP Manual: Core Configuration Directives
- PHP 8 ChangeLog: Security Fixes and Release History
Threat Intelligence and Industry Analysis
- Google Cloud: Responding to Core PHP Vulnerabilities
- ENISA: Joint Statement on Critical PHP Vulnerabilities
- AWS Security Blog: PHP2Shell Exploitation Before Public Disclosure
Application Security
.png)
