php2shell: Two Critical PHP Vulnerabilities Expose Web Servers to Remote Code Execution

Two critical PHP vulnerabilities: CVE-2026-109618 and CVE-2026-109619, collectively known as php2shell, can allow unauthenticated remote code execution (RCE). Both carry a CVSS v4.0 severity score of 9.2.

Exploitation attempts have been reported: Security researchers have observed attack traffic targeting both vulnerabilities. Public exploit research has demonstrated successful RCE in a defined laboratory configuration, although the extent of successful real-world compromise remains unknown.

Any vulnerable PHP web runtime may be exposed: The vulnerabilities affect PHP itself, rather than individual applications or plugins. Apache mod_php presents the highest demonstrated risk, but PHP-FPM and other web deployments also require updates.

Emergency patches are available: PHP released versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 on October 21, 2026. Organizations should install these versions or distribution packages confirmed to contain both fixes.

Temporary mitigations provide limited protection: PHP has published configuration-based measures to reduce exposure to specific exploitation paths. These do not provide complete protection, and a patched runtime remains necessary.

Patching does not eliminate an existing compromise: Organizations must investigate previously exposed systems for suspicious process activity, unauthorized file modifications, persistence mechanisms, and potentially stolen credentials. Once any compromise is contained, they should apply additional hardening guardrails to limit the potential blast radius.

Two critical vulnerabilities in PHP, collectively known as php2shell, have introduced an urgent security risk for organizations running PHP-based web applications.

Tracked as CVE-2026-109618 and CVE-2026-109619, the vulnerabilities can allow unauthenticated attackers to execute malicious code through vulnerable PHP web runtimes. Successful exploitation may provide attackers with access to application credentials, databases, internal services, and other systems reachable from the compromised server.

Unlike vulnerabilities affecting individual applications or plugins, php2shell targets PHP’s underlying runtime. This means that widely used platforms such as WordPress, Drupal, Magento, and Laravel may be exposed when running on a vulnerable PHP installation, regardless of the application’s own patch status. According to W3Techs, PHP is used by approximately 69% of websites whose server-side programming language is known, and WordPress alone powers roughly 40% of all websites.

On October 21, 2026, the PHP security team released emergency fixes for both vulnerabilities following the early disclosure of technical details.

Attack traffic and exploitation attempts have since been reported by security researchers. Public exploit code has also demonstrated remote code execution under specific laboratory conditions. While these developments establish credible exploitation risk, the number of successful compromises across production environments has not been determined.

For organizations operating internet-facing PHP infrastructure, the priority is clear: identify affected systems, deploy verified patches, reduce exposure where immediate remediation is not possible, and investigate for evidence of compromise.

PHP is widely deployed across enterprise websites, customer-facing applications, content management systems, e-commerce platforms, and internal business services.

Its broad deployment footprint creates a significant potential attack surface, particularly where organizations operate multiple PHP versions across web servers, containers, appliances, and third-party software.

The two php2shell vulnerabilities involve distinct flaws in PHP’s internal request processing and memory handling.

CVE-2026-109618: Remote Code Execution via Out-of-Memory Corruption

This vulnerability occurs when PHP encounters memory exhaustion while internal request data is only partially initialized. Subsequent cleanup operations may incorrectly process invalid data, creating conditions that can lead to arbitrary code execution.

CVE-2026-109619: Remote Code Execution via Stale Global State

The second vulnerability involves request-owned internal state that remains accessible after its underlying memory has been freed. A subsequent request processed by the same PHP worker may interact with that stale state before normal initialization resets it.

Both vulnerabilities can enable unauthenticated code execution under vulnerable conditions. Other potential effects include memory disclosure and service disruption.

The highest demonstrated exploitation risk involves Apache mod_php, where an attack may occur before application code executes. However, other web deployment models, including PHP-FPM, remain in scope and require remediation.

This distinction is important: patching an application, removing a vulnerable plugin, or introducing a WAF rule does not update the underlying PHP interpreter.

Relevance and Impact for Your Organization

Successful exploitation of php2shell can provide attackers with code execution under the permissions assigned to the PHP web worker.

Depending on the host’s configuration, privileges, and network access, this may allow attackers to:

Execute unauthorized commands on vulnerable web servers.

Deploy web shells or establish persistence.

Access application configuration files, database credentials, API keys, and other sensitive information.

Retrieve or modify data accessible to the compromised application.

Communicate with internal APIs, databases, and connected infrastructure.

Establish a foothold for further compromise or lateral movement.

Disrupt availability through worker crashes, resource exhaustion, or malicious changes.

Although exploitation initially occurs within the web worker’s permissions, the potential impact can extend beyond the affected application.

Enterprise web servers frequently maintain trusted connections to backend databases, identity services, internal APIs, cloud workloads, and other business-critical systems. These relationships can expand the consequences of a successful compromise.

Three factors make the vulnerabilities particularly important for security teams.

1. Exposure Extends Beyond Individual Applications

Because php2shell affects the PHP runtime, organizations cannot determine exposure simply by checking whether a specific application or plugin is updated.

Every PHP installation that processes web requests must be assessed.

This includes runtimes installed through operating system packages, container images, hosting platforms, control panels, and software that bundles PHP internally.

Security teams should distinguish between the PHP version available through the command-line interface and the version serving web requests. These may differ, potentially creating false confidence that a vulnerable service has been patched.

2. Public Exploit Research Increases the Urgency

Security researchers have reported attack traffic and exploitation attempts targeting both vulnerabilities.

A public exploit repository reports successful remote code execution against PHP 8.4.26 running Apache mod_php in a defined laboratory configuration. A separate repository provides executable verification proofs of concept but does not claim to contain a complete RCE exploit.

These findings demonstrate that exploitation techniques are becoming publicly accessible.

However, a successful laboratory demonstration does not establish exploit reliability across different production environments, and reported attack attempts do not necessarily indicate successful compromise.

Organizations should nevertheless anticipate continued exploitation activity and prioritize exposed systems accordingly.

3. Legacy Systems May Remain Vulnerable Longer

PHP 8.1 and earlier versions no longer receive regular security releases from the PHP project.

Some operating system distributions and long-term support vendors provide backported fixes, and PHP has supplied limited source-level backports for versions 7.4, 8.0, and 8.1.

Organizations must verify that an available package or source build addresses both vulnerabilities.

For legacy applications, migration may require code changes, dependency updates, compatibility testing, and coordination with business owners.

Until a verified fix is installed, organizations must rely on compensating controls to reduce exposure. Configuration changes alone are not sufficient to remediate php2shell.

Immediate Actions Within 24 Hours

1. Identify all affected PHP installations

Inventory PHP runtimes across the environment, including internet-facing web servers, internal applications, containers, appliances, control panels, and bundled interpreters.

For each installation, record the PHP version, package source, deployment model, internet exposure, and responsible business owner.

Verify the runtime handling HTTP requests rather than relying solely on command-line version checks.

2. Patch internet-facing systems immediately

Update vulnerable installations to the relevant fixed version:

Alternatively, install a distribution package explicitly confirmed by the vendor to address both CVE-2026-109618 and CVE-2026-109619.

Linux distributions may backport fixes without changing the upstream PHP version string. Verify patch status through the distribution’s security advisory.

Test critical applications before deployment, rebuild affected container images where necessary, and restart or replace all PHP workers to ensure the fixed runtime is active.

Confirm remediation against the version and package serving web requests.

Avoid running unverified public exploits or third-party scanning tools against production systems.

3. Apply temporary mitigations where patching is delayed

The PHP security team has published interim configuration changes that can reduce exposure to specific exploitation paths.

Disable session.upload_progress.enabled in the PHP startup configuration.

On PHP 8.5, also disable fatal_error_backtraces.

Restart all affected PHP workers.

Validate application compatibility before expanding deployment.

These settings block specific confirmed attack paths but do not prevent every possible exploitation method.

For CVE-2026-109618, PHP recommends enforcing memory_limit=-1 at the administrator level and restricting decoded request sizes, input fields, and multipart request components at the reverse proxy or web server.

These limits must apply before traffic reaches PHP, including requests without a usable Content-Length header.

Important Note: Setting an unlimited PHP per-request memory limit can increase denial-of-service risk. Organizations must assess server capacity, container resource controls, and availability requirements before implementation.

PHP also warns against using RLIMIT_AS or RLIMIT_DATA as substitutes because these controls may trigger the vulnerable allocation-failure path.

All interim changes should be tested with the responsible service owner.

These measures reduce exposure but do not eliminate the vulnerabilities. A fixed PHP build or verified distribution backport remains necessary.

4. Enable WAF protections and restrict direct origin access

Enable current managed WAF protections and monitor relevant alerts.

Verify that internet-facing requests cannot bypass the WAF or reverse proxy and reach the origin server directly.

Do not rely exclusively on rules matching PHP_SESSION_UPLOAD_PROGRESS. Although this parameter may help identify certain suspicious requests, CVE-2026-109618 does not require it.

WAF protections should be treated as additional defensive controls rather than a replacement for patching.

5. Isolate systems that cannot be patched promptly

Where updates cannot be deployed immediately, reduce exposure based on the application’s business requirements.

Recommended controls include:

Removing public access where feasible.

Restricting inbound traffic to approved sources.

Preventing direct connections to the origin server.

Segmenting web servers from management networks and sensitive internal systems.

Allowing outbound connections only to required destinations and backend services.

Enforcing network restrictions at host or network boundaries.

Validate application dependencies before making disruptive changes.

If a vulnerable internet-facing service cannot be patched or adequately isolated, consider temporarily taking it offline in coordination with the service owner.

6. Preserve logs and prepare for incident response

Ensure web access logs, PHP error logs, process telemetry, and network records are retained off-host.

Confirm backup availability, incident response ownership, and the organization’s ability to investigate potentially compromised web infrastructure.

Preserve relevant evidence before rebuilding systems or performing destructive remediation.

Follow-Up Actions Within 72 Hours

1. Conduct retrospective threat hunting

Review activity from October 20, 2026 onward, prioritizing internet-facing systems that remained vulnerable after public disclosure.

Correlate HTTP requests, PHP runtime errors, process execution, and network activity to identify suspicious patterns.

2. Investigate suspicious processes and web requests

Examine PHP and web worker processes that unexpectedly launch command shells, interpreters, networking utilities, or file-writing tools.

Review unusual HTTP submissions, including large form requests, long field names, control bytes, and anomalous multipart uploads.

Include application/x-www-form-urlencoded traffic in investigations. Multipart-only monitoring may miss demonstrated attack paths for CVE-2026-109618.

3. Identify persistence and unauthorized changes

Inspect web roots, temporary directories, PHP session storage, and scheduled tasks for suspicious files or modifications.

Review newly created accounts, unexpected application changes, and unusual outbound connections initiated by web servers.

4. Investigate potential credential exposure

If compromise is suspected, identify credentials and secrets accessible to the affected PHP worker.

This may include database passwords, cloud credentials, application tokens, API keys, and other sensitive configuration data.

Rotate or revoke potentially exposed secrets as part of coordinated containment and recovery.

5. Validate remediation and monitoring

Confirm that all web-serving PHP workers are running fixed builds and that exposed container images have been replaced.

Ensure monitoring remains active after patching and that suspicious hosts have been investigated before restoration.

Where compromise cannot be reliably excluded, consider rebuilding affected systems from trusted images.

If Compromise Is Suspected

Evidence of unauthorized command execution, web-shell activity, unexplained outbound connections, or suspicious persistence should trigger formal incident investigation.

Preserve relevant evidence and determine whether attackers gained access to application data, credentials, or connected internal systems.

Containment should account for the affected server’s legitimate business dependencies and the potential consequences of interrupting service.

Where malicious activity is confirmed, investigate the initial entry point, establish the scope of compromise, remove persistence mechanisms, and rotate potentially exposed credentials.

Patching a vulnerable runtime does not remove an attacker who has already established access.

Appendix 1: Technical Details

General Details and Affected Versions

Apache mod_php has the highest demonstrated risk, including exploitation before application code execution.

PHP-FPM and other PHP web-serving configurations also remain potentially affected and must be updated.

The PHP project released security updates for its supported branches on October 21, 2026.

Organizations running older versions should consult their operating system or long-term support vendor for applicable backported fixes.

PHP has also made minimal source-level backports available for PHP 7.4, 8.0, and 8.1.

A PHP version string alone is not sufficient to establish vulnerability status where vendor backports are used.

CVE-2026-109618: Exploitation Mechanism

CVE-2026-109618 involves unsafe request cleanup after memory exhaustion interrupts initialization.

Under vulnerable conditions, internal request data may be left in an invalid state. Subsequent cleanup may treat this data as properly initialized, creating the potential for memory corruption and remote code execution.

PHP’s interim guidance focuses on reducing attacker-controlled memory exhaustion conditions and limiting the amount and complexity of incoming request data.

Recommended controls include administrator-enforced memory settings and request limits at trusted web-facing infrastructure.

CVE-2026-109619: Exploitation Mechanism

CVE-2026-109619 involves internal request-owned state remaining accessible after its memory has been freed.

A subsequent request processed by the same PHP worker may interact with this stale state before initialization restores a valid state.

PHP recommends disabling session upload-progress tracking and, for PHP 8.5, fatal error backtraces to reduce exposure to confirmed exploitation paths.

These mitigations must be applied before request parsing and require worker restarts to take effect.

Neither measure provides complete protection against all potential exploitation variants.

Appendix 2: Monitoring and Detection

Indicators and Artifacts

Security teams should review activity beginning October 20, 2026.

The following behaviors are investigative leads rather than validated proof of php2shell exploitation.

A successful exploit may return an HTTP 200 response without causing a visible PHP crash.

Consequently, the absence of worker instability or obvious error responses does not exclude successful exploitation.

Detection Without EDR

On Linux systems without endpoint detection and response coverage, process-monitoring utilities can provide additional visibility into programs launched by PHP.

However, organizations should evaluate the privileges and operational impact of these tools before deployment.

Process monitoring will not identify malicious activity that occurs entirely within the PHP worker without spawning a separate process.

Hardening and Prevention

Beyond immediate patching, organizations should strengthen controls that limit the potential consequences of future web-server compromise.

Recommended measures include:

Maintaining an accurate inventory of supported and unsupported PHP installations.

Reducing privileges assigned to web worker processes.

Restricting web-tier access to management networks and sensitive backend services.

Enforcing network segmentation and controlled outbound connectivity.

Maintaining centralized, tamper-resistant application and process logs.

Monitoring unexpected child processes, file modifications, and unusual outbound connections.

Regularly validating backup integrity and recovery procedures.

Establishing clear ownership and remediation plans for legacy applications.

Effective protection requires more than closing the initial vulnerability. Organizations must also limit what an attacker can access after compromising a web server and maintain sufficient visibility to detect unauthorized activity.

PHP Security Advisory – October 21, 2026

PHP Security Advisory – CVE-2026-109618

PHP Security Advisory – CVE-2026-109619

Cloudflare – PHP Vulnerabilities and WAF Protection

watchTowr – PHP Remote Code Execution: php2shell

Patchstack – PHP Vulnerability Incident Timeline

Datadog Security Labs – php2shell Technical Analysis and Detection

Wiz Research – PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet

PHP Supported Versions