PHP2Shell: Two critical PHP vulnerabilities and how to respond

Published research: October 21–22, 2026

Two critical vulnerabilities in the PHP runtime have triggered an urgent security response across the web application ecosystem. Disclosed on October 21, 2026, CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell, affect PHP's internal memory handling and can potentially allow unauthenticated remote code execution (RCE).

Both vulnerabilities received a critical CVSS v4.0 score of 9.2. Unlike application-level weaknesses that depend on vulnerable business logic, these flaws exist in PHP itself, potentially exposing websites and services even when their application code follows secure development practices.

For security teams, the immediate priorities are to identify affected PHP runtimes, reduce exposure where necessary, deploy fixed versions, and verify that remediation was successful.

Vicarius also provides two community scripts to support the response:

• CVE-2026-109618 mitigation script: PHP2Shell critical RCE in PHP

• CVE-2026-109619 detection script: PHP stale global state use-after-free RCE

These resources support detection and risk reduction. They are not replacements for installing the official PHP security updates.

What is PHP2Shell?

PHP2Shell refers to two newly disclosed memory-safety vulnerabilities in the core PHP runtime.

The weaknesses were disclosed through coordinated research involving Wiz Research and the PHP security team, with Google describing the role of AI-assisted vulnerability discovery and patch validation in the research process.

Both issues involve unsafe handling of PHP's internal runtime memory and state during web request processing.

Under certain conditions, an attacker can manipulate how PHP handles a request, potentially leading to memory corruption, information disclosure, or execution of unauthorized code.

The important distinction is that these vulnerabilities do not require an insecure PHP application function to exist. The attack surface includes the runtime handling requests, which makes infrastructure-level remediation particularly important.

The PHP security team considers Apache deployments using mod_php to carry the greatest demonstrated risk, although other PHP environments also require urgent attention.

CVE-2026-109618: Remote code execution through out-of-memory corruption

CVE-2026-109618 is a critical memory corruption vulnerability involving PHP's handling of out-of-memory conditions.

When PHP encounters a memory allocation failure, execution may stop while certain internal request structures are only partially initialized.

During subsequent cleanup, the runtime may mistakenly interpret invalid internal data as legitimate data, creating a memory corruption condition that may be exploitable.

Why does this matter?

Memory exhaustion is not necessarily limited to unusual workloads. Web-facing applications routinely process requests, form data, uploads, and other inputs that may influence resource consumption.

An attacker who can steer execution toward the vulnerable failure path may be able to trigger the dangerous cleanup behavior.

Successful exploitation could result in remote code execution under the permissions of the affected PHP process.

How to mitigate CVE-2026-109618

Installing the fixed PHP version is the recommended remediation.

When immediate patching is not possible, PHP's advisory describes temporary measures that can reduce exposure to specific attack paths. These include:

• Configuring memory_limit=-1 at an appropriate administrative level to remove PHP's configurable memory-limit failure path, while recognizing that underlying allocation failures remain possible.

• Restricting request and upload sizes at PHP and web-server or proxy layers.

• Using container or cgroup limits as resource and availability boundaries.

• Validating that application-specific overrides do not undermine the intended safeguards.

These measures should be tested before deployment because they can affect application behavior and resource consumption.

Vicarius community resource: CVE-2026-109618 PHP2Shell mitigation script

Review the script, confirm that its assumptions match your environment, and validate its effects before production rollout. Temporary mitigation does not establish that the vulnerability has been fully eliminated.

CVE-2026-109619: Remote code execution through stale global state

CVE-2026-109619 involves a separate PHP runtime memory-management weakness.

The vulnerability occurs when request-owned internal state remains accessible after the memory supporting that state has been freed.

A later request handled by the same PHP worker may encounter that stale state before the normal initialization sequence restores it.

This creates a use-after-free condition, potentially enabling memory corruption and remote code execution.

Why persistent PHP workers increase the importance of detection

PHP deployments often use worker processes to serve multiple requests.

Reusing workers improves performance, but it also makes correct isolation between requests essential.

If internal state survives beyond its intended lifetime, a subsequent request may encounter data that should no longer exist.

This is one reason vulnerability detection cannot be limited to reviewing application source code. Teams also need visibility into the actual PHP runtime versions and deployment configurations used in production.

How to respond to CVE-2026-109619

PHP recommends upgrading to a fixed version.

For environments that cannot immediately update, the official advisory identifies configuration measures that block certain confirmed paths:

• Set session.upload_progress.enabled=0 at a configuration level applied before request parsing.

• Restart affected PHP workers after changing this setting.

• On PHP 8.5, set fatal_error_backtraces=0 and restart workers to block the confirmed fatal-backtrace path.

• Treat these measures as temporary risk reduction, not comprehensive protection.

Because other variants may remain possible, successful configuration changes cannot be treated as proof that a vulnerable PHP runtime is safe.

Vicarius community resource: CVE-2026-109619 PHP2Shell detection script

Use detection findings to identify potentially affected systems, prioritize investigation, and support remediation planning. A negative script result should not be interpreted as definitive proof that exploitation is impossible or that no compromise occurred.

Which PHP versions are affected?

The disclosures concern PHP versions dating back to PHP 5.4, including older unsupported releases and previously current branches.

The PHP project released the following fixed versions on October 21, 2026:

Organizations using Linux distribution packages should verify the vendor's security advisory rather than relying exclusively on the displayed upstream PHP version. Some long-term-support vendors backport security fixes into their existing package versions.

Where PHP versions are no longer supported, migration to a maintained release should be prioritized.

Which systems are exposed to PHP2Shell?

The PHP security advisory identifies multiple runtime environments requiring attention:

• Apache HTTP Server deployments using mod_php

• PHP-FPM environments behind Nginx or Apache

• Deployments using php-cgi

• FrankenPHP-based applications

• LiteSpeed PHP deployments

• Containerized and cloud-hosted PHP services

The presence of PHP does not automatically mean every deployment can be exploited in the same way. Actual exposure depends on runtime versions, execution model, configuration, request handling, and other technical conditions.

However, the vulnerability exists below the application layer.

A well-maintained application can still be exposed if its underlying PHP runtime is vulnerable.

Organizations should therefore review infrastructure and runtime inventories rather than relying solely on application vulnerability assessments.

A practical PHP2Shell remediation workflow

Responding to critical vulnerabilities requires more than identifying a CVE in a scanner.

Security and infrastructure teams must translate vulnerability intelligence into safe changes across their environments and then confirm those changes were applied.

Step 1: Identify every PHP runtime

Inventory PHP installations across physical servers, virtual machines, containers, application images, and managed services.

Check production, staging, development environments reachable from untrusted networks, and systems that may use a separate PHP binary or runtime from the one displayed by the command-line interface.

For example, a useful starting point is:

php -v

This identifies the version of the PHP CLI binary being invoked. It does not necessarily identify the version used by the web server or PHP-FPM workers.

Complete discovery must include the runtimes actually processing requests.

Step 2: Prioritize internet-facing applications

Start with systems that process untrusted web requests, particularly the configurations identified as highest risk by PHP's advisory.

Prioritization should consider:

• Whether the service is publicly reachable

• The installed PHP version and vendor patch status

• The deployment model and confirmed attack paths

• The application's access to sensitive data or connected systems

• Available security controls and exposure-reduction options

Avoid using the CVSS score alone to determine remediation order. Two systems affected by the same vulnerability may present different operational and business risks.

Step 3: Run appropriate detection checks

Security teams can use vulnerability inventory, configuration checks, vendor advisory mappings, and purpose-built detection scripts to determine where additional attention is required.

Vicarius provides a community resource for CVE-2026-109619:

Run or review the PHP stale global state detection script

Review the script's supported operating systems, permissions, logic, and output before relying on its findings.

Document potential exposure, affected assets, and any detection limitations.

Step 4: Apply security updates or temporary mitigation

The highest-priority action is installing the appropriate fixed PHP release or a verified vendor-backported security update.

Where patching requires additional testing or a maintenance window, teams can evaluate narrowly scoped temporary controls.

For CVE-2026-109618, review the Vicarius PHP2Shell mitigation script alongside the official PHP advisory.

Changes involving PHP resource handling should be tested against realistic application workloads and resource limits.

Temporary protections reduce risk while patching is underway. They should not become an indefinite alternative to remediation.

Step 5: Verify remediation

A completed software update job does not automatically prove that the running application is protected.

After deploying an update, validate that:

1. The installed runtime has the appropriate fix or vendor backport.

2. Web-facing PHP workers are using the updated runtime.

3. Containers or application services have been redeployed where necessary.

4. Application functionality and availability remain intact.

5. Exposure or vulnerability checks no longer identify the relevant unpatched runtime.

Capture the evidence of the installed fix and the running configuration.

This creates a clearer distinction between an attempted remediation and a verified security outcome.

Why patching PHP2Shell is an exposure management challenge

The PHP2Shell disclosures illustrate a challenge familiar to security teams: discovering a serious vulnerability can be much faster than safely removing its risk across every affected system.

A single organization may operate PHP through different Linux distributions, cloud services, containers, application teams, and legacy platforms.

Each environment can require a different update mechanism or maintenance process.

Some systems may be straightforward to patch. Others require compatibility testing, application-owner approval, or temporary exposure reduction.

This makes remediation a coordination problem as much as a vulnerability intelligence problem.

The most effective response connects four activities:

Discovery: Determine where affected software is running.

Prioritization: Understand which vulnerable systems create the greatest exposure.

Remediation: Deploy supported updates and appropriate temporary measures.

Validation: Confirm that the intended changes took effect and that residual risk is understood.

For organizations managing large endpoint and server estates, this approach helps reduce the time between discovering a critical vulnerability and obtaining evidence that exposure has been addressed.

How Vicarius supports vulnerability remediation

Vicarius approaches vulnerability remediation as an operational process, combining software and vulnerability visibility with different remediation methods.

Depending on the affected system and available remediation options, security teams may need to apply patches, execute approved scripts, or implement temporary compensating controls while a permanent fix is prepared.

The PHP2Shell disclosures demonstrate why these approaches should be connected.

Detection helps establish which systems require attention. Temporary mitigation can help reduce some attack paths. Official patches correct the underlying vulnerabilities. Validation establishes whether the intended remediation was successfully deployed.

Vicarius's vSociety community provides scripts and technical remediation resources that teams can evaluate as part of this process.

For PHP2Shell, start with these two resources:

CVE-2026-109618: Mitigation

View the PHP2Shell critical RCE mitigation script

CVE-2026-109619: Detection

View the PHP stale global state use-after-free detection script

These scripts should be reviewed and tested before deployment, and their results interpreted alongside official vendor guidance.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the collective name used for CVE-2026-109618 and CVE-2026-109619, two critical memory-safety vulnerabilities in PHP disclosed on October 21, 2026. Both can potentially lead to unauthenticated remote code execution.

What is the severity of the PHP2Shell vulnerabilities?

Both CVEs have a critical CVSS v4.0 score of 9.2. Their exploitation risk varies with the runtime version, configuration, and deployment environment.

Can PHP2Shell be exploited without authentication?

The PHP security team confirmed unauthenticated remote code execution risk, with a demonstrated pre-application-code attack path in mod_php deployments. This does not mean every PHP configuration has an identical exploit path.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

The fixed upstream versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Organizations using vendor-maintained distributions should check whether security fixes have been backported.

Can PHP2Shell be fully mitigated without patching?

No. PHP explicitly warns that temporary mitigations address only certain attack paths. Installing a fixed version or verified vendor security fix is the safe remediation.

How can security teams detect potential exposure?

Teams should inventory PHP runtimes, compare installed versions with vendor advisories, evaluate relevant configurations, and use suitable detection resources. Vicarius provides a detection script for CVE-2026-109619 on vSociety.

Are websites running WordPress or other PHP applications affected?

Any PHP-based application may warrant review if it uses a vulnerable PHP runtime. Whether a particular deployment is exploitable depends on the runtime and its configuration. Updating the CMS or application alone does not necessarily update PHP.

Final thought

CVE-2026-109618 and CVE-2026-109619 are an important reminder that critical application exposure can originate within the language runtime itself, not just in application code.

For security teams, the priority is clear: identify vulnerable PHP deployments, install official security updates, use temporary protections only where necessary, and verify that updated runtimes are running in production.

Explore the Vicarius PHP2Shell scripts on vSociety to support your investigation and remediation planning, or request a Vicarius demo to learn more about operationalizing vulnerability remediation across your environment.