PHP2Shell Explained: Critical PHP Vulnerabilities Enable Unauthenticated Remote Code Execution

On October 21, 2026, the PHP development team released urgent security updates addressing two critical vulnerabilities in PHP's core runtime. Tracked as CVE-2026-109618 and CVE-2026-109619, the flaws were assigned a CVSS v4.0 severity score of 9.2 and can enable unauthenticated remote code execution under affected conditions.

Collectively discussed as PHP2Shell, these vulnerabilities highlight a fundamental security risk for web infrastructure. When a flaw exists in the language runtime itself, the consequences can extend beyond a single application, framework, plugin, or content management system.

The research demonstrated exploitation against WordPress, Drupal, and Joomla, along with application-independent memory disclosure. The underlying issue is in PHP itself, meaning custom applications and other PHP-based services may also be affected. Official PHP2Shell research · PHP security release announcement.

1. What Is PHP2Shell?

PHP2Shell is the name used for a family of critical vulnerabilities affecting the PHP runtime. The research identifies two related memory-safety failure patterns involving memory exhaustion and stale global state across requests.

PHP is widely used for server-side application development. It powers websites, APIs, content management systems, e-commerce platforms, administrative panels, and many other internet-facing services.

Common PHP-based technologies include:

• WordPress: A content management system used for blogs, business websites, and publishing platforms.
• Laravel: A PHP framework used to build web applications and APIs.
• Drupal and Joomla: Content management systems used for websites and web applications.
• Symfony: A framework and component ecosystem used in custom PHP applications.
• MediaWiki: The software behind Wikipedia and many other knowledge bases.

These products do not all contain the same application-level code. However, they can rely on the same underlying PHP runtime.

That distinction is central to understanding PHP2Shell.

If a vulnerability resides in a plugin, removing or updating that plugin may resolve the immediate issue. If a vulnerability resides in PHP's core request-processing and memory-management behavior, updating the application alone does not fix the runtime underneath it.

The official research demonstrated that even an otherwise simple PHP application can be affected when running a vulnerable PHP version.

2. Why These Vulnerabilities Matter

A typical web request passes through several layers before the application returns a response.

A simplified PHP deployment looks like this:

1. A client sends an HTTP request.
2. The web server receives and routes the request.
3. A PHP execution component processes the request.
4. PHP parses input, manages request data, and executes application code.
5. The application produces a response.
6. The server sends the response to the client.

The exact arrangement depends on the deployment. PHP may run through PHP-FPM, Apache's mod_php, CGI-based execution, or another supported server integration.

PHP2Shell is significant because the vulnerable behavior exists within the runtime layer. An attacker may be able to trigger a vulnerable code path through a request before the application's normal authentication or authorization logic can protect it.

This changes the security boundary.

Application authentication can protect a dashboard, administrator account, or restricted API endpoint. It cannot reliably compensate for a remotely reachable flaw in the runtime that processes incoming requests before those controls are reached.

The research reports pre-authentication remote code execution in representative application environments, with exploitation requirements varying between the two vulnerability classes.

3. The Two Vulnerabilities Behind PHP2Shell

The PHP2Shell research identifies two CVEs. Both have a reported CVSS v4.0 score of 9.2, but they involve different failure patterns.

The following sections explain the concepts at a high level without providing exploit payloads or instructions for attacking vulnerable servers.

CVE-2026-109618: Out-of-Memory Handling and Memory Corruption

Applications have to manage memory while processing requests. PHP allocates memory for request data, variables, strings, arrays, objects, and other runtime structures.

To prevent a script from consuming unlimited resources, PHP provides a configurable memory_limit. When a script exceeds its permitted allocation, PHP can raise a fatal error and begin its shutdown process.

The critical security question is what happens during that failure.

Error handling, resource cleanup, and shutdown logic must remain safe even when the runtime is under memory pressure. If an exceptional condition causes internal state to become corrupted or a cleanup path to operate on invalid data, the result can be more serious than a failed request.

According to the PHP2Shell research, CVE-2026-109618 involves memory corruption associated with out-of-memory handling. Under affected conditions, the failure can be leveraged for remote code execution.

The important distinction is that an out-of-memory error is not automatically a code-execution vulnerability. The security problem arises when the runtime's handling of that condition violates memory-safety guarantees.

For defenders, this means that request-size restrictions and resource limits are useful operational controls, but they cannot be assumed to eliminate every path to the underlying flaw.

CVE-2026-109619: Stale Global State Across Requests

PHP applications frequently run through worker processes that handle multiple requests over time. Depending on the deployment and lifecycle of a worker, runtime structures may persist beyond a single request.

This creates a requirement for strict request isolation. Data and pointers associated with one request must not remain usable after the objects or memory they reference have been released.

A use-after-free vulnerability occurs when software continues using memory after it has been freed. That memory may have been reallocated for a different purpose, causing the program to interpret unrelated data as an object or structure it previously owned.

The PHP2Shell research identifies a related failure pattern involving stale global state that survives across requests.

At a conceptual level, the sequence is:

1. A request creates or modifies runtime state.
2. Request cleanup releases resources that are no longer valid.
3. Some state incorrectly retains a reference to released or invalid memory.
4. A later operation encounters that stale state.
5. Depending on the affected path and memory layout, the result may include memory disclosure or code execution.

This is a simplified explanation of the underlying class of bug, not a complete reconstruction of the exploit.

The security implications can be severe because worker reuse is a normal performance optimization in many PHP deployments. The runtime must ensure that state from a previous request cannot compromise the integrity or confidentiality of a subsequent request.

4. What Can an Attacker Do?

The demonstrated impact includes unauthenticated remote code execution and sensitive process-memory disclosure. These are distinct outcomes, although they can be related.

Remote code execution

Remote code execution, commonly abbreviated RCE, means an attacker can cause a vulnerable system to execute instructions or code under the privileges of the affected process.

In a PHP web deployment, this may allow an attacker to act with the permissions of the PHP worker or web-server account.

Depending on those permissions and the server's configuration, potential consequences include:

• Reading application configuration and accessible files.
• Accessing database credentials stored in application configuration.
• Reading or modifying website content.
• Installing persistent malicious code within writable locations.
• Accessing secrets available to the application process.
• Attempting to move into other services or accounts that the compromised process can reach.

Remote code execution does not automatically mean root access or complete control of the underlying machine. The initial level of access depends on process privileges, operating-system restrictions, filesystem permissions, and isolation controls.

However, even execution as a restricted web-server account can be serious when that account can access valuable application data.

Sensitive memory disclosure

The research also describes application-independent memory disclosure.

A PHP worker's memory may contain information handled during current or previous requests. Depending on the application and runtime state, this can include authentication tokens, API keys, passwords, session-related data, or other secrets.

Memory disclosure is important even when an attacker cannot achieve code execution.

For example, an exposed credential may permit access to an external API, database, storage service, or another application. A stolen session token may allow an attacker to impersonate a user, subject to the token's validity and security controls.

Memory disclosure can also be harder to identify using monitoring designed specifically to detect malicious command execution. A server may leak sensitive information without producing the same signals as a conventional RCE attack.

5. Is PHP2Shell Only a WordPress Vulnerability?

No.

WordPress was one of the applications used to demonstrate exploitation, but the underlying vulnerabilities affect PHP itself rather than a specific WordPress component.

The research also demonstrated exploitation in Drupal and Joomla environments.

This matters because the security boundary is different from that of an ordinary application vulnerability. A custom PHP application does not become immune simply because it uses no popular CMS, has no vulnerable plugin, or contains no obvious insecure application code.

The relevant questions are:

• Which PHP runtime version is executing the application?
• Is that runtime reachable through web requests?
• Has the vendor or distribution applied the appropriate security fix?
• Are all execution paths and workers running the corrected runtime?

The same principle applies to frameworks such as Laravel and Symfony. Framework updates and secure application code remain important, but they do not replace a security update to the underlying PHP engine.

6. Which PHP Versions Are Affected?

The official PHP2Shell advisory identifies fixed releases across the currently supported branches listed below.

Any earlier release in those branches should be treated as vulnerable unless the relevant vendor confirms that it contains a backported fix.

The research also identifies affected older PHP releases. PHP 8.1 and earlier are outside the PHP project's current supported branches, although some distributions and third-party vendors may supply security patches for older versions.

For legacy deployments, do not assume that an old version is safe because it no longer receives upstream updates. Check the relevant distribution or hosting vendor's advisory and verify the actual installed package.

Official references:

• PHP2Shell research and remediation guidance
• PHP security announcements
• PHP downloads

7. How to Check Your PHP Version

The PHP version reported by your terminal may not match the version serving your website.

For example, a hosting account may use one PHP version for command-line scripts and a different version for its web applications. Different domains, subdomains, containers, or PHP-FPM pools may also use separate runtimes.

On a Linux server

Check the command-line version:

php -v

This identifies the CLI interpreter. It does not prove that Apache, PHP-FPM, or another web-facing handler uses the same version.

For PHP-FPM deployments, identify the installed packages, configured pools, and active service versions. On a distribution that uses systemd, service discovery can help:

systemctl list-units --type=service --all | grep -i php

Package names and service names differ by operating system and installation method.

On cPanel

For a typical cPanel account:

1. Sign in to cPanel.
2. Open MultiPHP Manager, if your hosting provider exposes it.
3. Check the PHP version assigned to each domain.
4. Confirm the available security-fixed versions with your hosting provider.
5. Check any separately configured command-line or scheduled PHP jobs.

If your provider manages PHP versions centrally, you may need the hosting provider to apply the update.

On managed hosting

If you cannot see or control the underlying PHP runtime, ask the provider to confirm that every web-facing PHP handler has received the PHP2Shell security fixes.

Do not rely solely on a version banner, a CMS dashboard, or a successful application test. Confirm the actual runtime and its patch status.

8. How to Patch PHP2Shell

Updating PHP to a security-fixed release is the primary remediation. Updating WordPress, Laravel, Drupal, Joomla, or another application does not itself update the PHP engine.

A practical remediation process follows.

Step 1: Inventory every PHP runtime

Identify PHP versions used by:

• Production websites and APIs.
• Subdomains and staging environments.
• Apache modules and PHP-FPM pools.
• Command-line jobs and scheduled tasks.
• Containers and application images.
• Internal dashboards and administrative interfaces.
• Vendor products that embed or bundle PHP.

A single server can run several different PHP versions. Updating only one does not protect the others.

Step 2: Install the appropriate security update

Use the official PHP release or a trusted operating-system or hosting-provider package containing the fix.

For the branches listed in the advisory, the fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.

If you use a distribution with backported security patches, verify the vendor's advisory and package status instead of comparing version numbers alone.

Step 3: Restart the relevant services and workers

After installing the fix, restart or reload the relevant PHP execution services as required by the deployment.

This can include PHP-FPM, Apache, or other PHP handlers, as well as long-running workers that may still be using an older runtime.

A package update is not sufficient if live processes continue executing the vulnerable binary or retain the old runtime state.

Step 4: Verify the active runtime

Recheck the PHP version and patch status for every affected domain and execution path.

Confirm that:

• Web requests use the corrected runtime.
• PHP-FPM pools and other workers have been restarted as necessary.
• Scheduled jobs use an appropriately patched CLI interpreter.
• Containers have been rebuilt or redeployed where required.
• No old PHP installation remains exposed through an alternate handler.

Step 5: Test the application

Run normal application checks after upgrading. Verify authentication, database access, file uploads, background tasks, and any features that rely on PHP configuration.

Security updates should be deployed promptly, but a controlled validation process helps detect compatibility issues without unnecessarily leaving vulnerable systems exposed.

The PHP team states that no complete configuration-only mitigation replaces updating to a fixed release. Source: PHP release announcement.

9. What If You Cannot Upgrade Immediately?

Some hosting environments, legacy applications, and managed platforms cannot be updated instantly. In those situations, temporary controls may reduce exposure to particular attack paths while a proper patch is arranged.

They should not be treated as proof that the system is safe.

The official PHP2Shell guidance discusses several possible measures, including:

• Disabling session upload-progress tracking if the application does not require it.
• Reviewing request-size and input-nesting limits.
• Reviewing PHP memory-limit behavior and its operational consequences.
• Disabling remote display of PHP errors in production.
• Reviewing fatal-error backtrace behavior where supported.
• Recycling PHP-FPM workers more frequently.
• Restricting the capabilities of PHP workers through operating-system security controls.

Each control has limitations. Some affect legitimate uploads or complex forms. Others reduce only specific exploitation paths, while worker recycling may introduce performance overhead.

One particularly important caution is that changing memory_limit to -1 is not a universal fix. It disables PHP's configured memory ceiling and transfers more resource-exhaustion risk to the operating system. If considered as a temporary measure, it requires appropriate operating-system resource containment and careful assessment of availability risks.

The official advisory also warns against assuming that operating-system limits such as RLIMIT_AS or RLIMIT_DATA are safe replacements for PHP's memory limit in this context.

These controls should be applied only after reviewing the official guidance and testing their effects. Do not delay patching while experimenting with configuration changes.

10. Does Cloudflare Protect Against PHP2Shell?

A web application firewall or reverse proxy can be a valuable additional security layer, but it is not a substitute for patching PHP.

Cloudflare and similar services may block some malicious requests based on their rules and detection capabilities. However, a protection layer cannot be assumed to identify every request capable of triggering a runtime memory-safety flaw.

The vulnerability is in the backend runtime. If a request reaches a vulnerable PHP handler and triggers an affected code path, the fact that the domain uses a CDN or WAF does not establish that the runtime is safe.

For organizations using Cloudflare, useful defense-in-depth measures include:

• Keep applicable managed security rules enabled and updated.
• Review available security events and request logs.
• Restrict direct access to the origin server where practical.
• Ensure the origin accepts traffic only through the intended network paths.
• Patch PHP on the origin regardless of whether the domain is proxied.

A proxied DNS record is not the same as a patched server. If an origin remains directly reachable, traffic may also bypass the proxy's protections.

The correct strategy is to combine patched software, restricted exposure, monitoring, and sensible isolation controls.

11. How to Investigate Possible Compromise

Because the vulnerabilities can have serious consequences, administrators should consider whether a vulnerable server was exposed before the patch was applied.

Patching prevents exploitation through the fixed vulnerability, but it does not automatically remove malware or undo changes made during an earlier compromise.

A proportionate investigation should include the following steps.

Review access and security logs

Look for unusual request patterns, unexpected upload activity, abnormal error sequences, suspicious access to application endpoints, and other activity inconsistent with normal traffic.

The absence of an obvious malicious request does not prove that exploitation did not occur. Logging may be incomplete, and memory disclosure may not resemble a conventional command-execution event.

Check files and processes

Review unexpected changes to application files, newly created scripts, unfamiliar scheduled tasks, suspicious processes, and changes to web-server configuration.

Compare files against known-good releases or trusted backups where possible. Investigate unexplained changes instead of automatically deleting files that may be part of legitimate application behavior.

Rotate potentially exposed credentials

If compromise or secret disclosure is suspected, rotate relevant credentials from a trusted environment. Depending on the system, these may include database passwords, API keys, session-signing secrets, cloud credentials, and deployment tokens.

Also consider invalidating active sessions or tokens where appropriate.

Preserve evidence

For a potentially serious incident, preserve relevant logs, timestamps, process information, and forensic evidence before making destructive changes. Isolate affected systems when necessary and follow your incident-response process.

If an attacker achieved code execution, simply installing the patch may not be sufficient to restore trust in the server. Recovery may require rebuilding from a known-good image and restoring verified data.

12. Why Runtime Security Matters for Open-Source Projects

PHP2Shell also offers a broader lesson for developers who maintain open-source software.

An application's security depends on more than its own source code. It depends on the runtime, operating system, dependencies, server configuration, deployment process, and permissions under which the application executes.

Maintainers should therefore:

• Track security advisories for the languages and runtimes they depend on.
• Document supported runtime versions.
• Test updates against supported versions and deployment environments.
• Avoid unnecessarily broad filesystem and process permissions.
• Keep secrets out of public repositories and unnecessary process exposure.
• Provide clear upgrade guidance to users.
• Distinguish application fixes from infrastructure-level fixes.

For users of open-source projects, a well-maintained repository does not remove the responsibility to keep its runtime and dependencies updated.

This is especially relevant for shared hosting, where multiple domains may rely on centrally managed PHP versions, and for containerized deployments where an old base image can continue shipping a vulnerable runtime even after the application source has been updated.

13. What Developers and Hosting Providers Should Learn

PHP2Shell is a reminder that security failures can occur in the infrastructure beneath otherwise well-designed applications.

For developers, the lesson is to maintain an accurate inventory of the runtimes and services their software requires.

For hosting providers, the challenge is to identify affected PHP handlers across customer accounts, deploy security updates, restart the relevant services, and communicate clearly with customers who cannot update runtimes themselves.

For site owners, the priority is to verify the PHP version actually serving each domain, not merely the version installed in a terminal.

For security teams, the incident reinforces the value of monitoring for suspicious behavior and investigating whether vulnerable systems were exposed during the period before remediation.

No single control provides complete protection. Patching, least privilege, network restrictions, monitoring, and incident response all play different roles in reducing risk.

Conclusion

PHP2Shell demonstrates how a defect in a widely deployed language runtime can affect a diverse range of web applications.

The two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, involve different memory-safety failure patterns but share a critical implication: affected PHP runtimes can expose systems to unauthenticated remote code execution or sensitive memory disclosure.

The vulnerabilities are not restricted to WordPress, and application-level security measures alone cannot correct defects in the PHP engine.

The immediate priority is to identify every affected runtime, install a fixed release or verified vendor patch, restart the relevant services, and confirm that no vulnerable execution path remains. Where compromise is suspected, administrators should investigate beyond the patch itself.

Keep PHP updated. Verify the runtime serving your website. Treat temporary mitigations as temporary, and do not assume that a protected domain means its backend is patched.

For official technical details and the latest remediation guidance, consult PHP2Shell.com and the PHP security announcements.