PHP2Shell Operational Guidance

First published on 22 October 2026, last updated on 23 October 2026 at 16:45 CEST. This public operational guidance is provided to customers and published for the benefit of the wider community. TLP:AMBER information is disclosed through regular channels.

TL;DR

What: Two critical PHP vulnerabilities where disclosed, CVE-2026-109618 (RCE via OOM corruption) and CVE-2026-109619 (RCE via stale global state), collectively PHP2Shell. Both rated CVSS v4.0 9.2 (Critical). A third, lower-risk CVE (CVE-2026-115560) was disclosed on 23 October and will ship in the regular release cycle.
Who’s affected: Any PHP installation serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. Particular attention for Apache mod_php, where unauthenticated exploitation has been demonstrated.
Exploitation status: Active exploitation attempts observed by Amazon, Cloudflare, WatchTowr, and NVISO. No confirmed successful compromises or reliable public exploit yet, but PoC claims are circulating.
What to do: Patch to PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 immediately, prioritising internet-facing systems. Where patching is delayed, apply PHP’s vulnerability-specific mitigations (full details below). Verify that web-server processes are actually using the patched runtime.

What happened?

On 20 October 2026, information about two critical vulnerabilities in PHP surfaced publicly ahead of their planned coordinated disclosure. The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619, have each received a CVSS v4.0 score of 9.2 (Critical).

In response, the PHP security team announced an emergency security release scheduled for 21 October 2026 at 14:00 UTC (16:00 CEST), with the possibility of an earlier release if technical details become public or active exploitation is detected.

Both vulnerabilities are reported to potentially allow unauthenticated remote code execution (RCE). Successful exploitation could enable a remote attacker to execute malicious code on a vulnerable server, potentially compromising the applications and data hosted on it.

On 21 October 2026 at 13:30 UTC (15:30 CEST), the PHP security team released emergency patches addressing both vulnerabilities.

The following are the minimum fixed upstream PHP versions:

PHP branch	Fixed version
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 and older	No standard upstream release; vendor backports or migration required

On 23 October 2026, the PHP security team released an informational advisory about another vulnerability: CVE-2026-115560. This vulnerability requires specific combinations of configuration and application code. Because the PHP security team assesses the exploitation of this vulnerability as unlikely, the patch will be released in the regular release cycle, rather than an emergency patch like CVE-2026-109618 and CVE-2026-109619.

Why should organisations be concerned?

PHP is one of the most widely used server-side programming languages for web development. It underpins many websites, content management systems (CMS), e-commerce platforms, customer portals, and business applications.

Popular platforms such as WordPress, Drupal, Joomla, and Magento rely on PHP to execute application logic. Unlike a vulnerability affecting a specific plugin or individual web application, a vulnerability in PHP
itself may affect multiple applications that rely on the same underlying runtime. This makes the potential attack surface particularly broad.

Organisations may also be running PHP without necessarily being aware of it. PHP runtimes can be embedded in legacy applications, hosting environments, internal management portals, containers, and third-party software.

The potential consequences of successful remote code execution include:

Unauthorised server access: Attackers may execute commands within the security context of the affected PHP process.
Data theft: Sensitive information, application secrets, credentials, or customer data accessible to that process could be exposed.
Website compromise: Attackers can modify application content, deploy malicious scripts, or establish persistence through webshells.
Operational disruption: Compromised applications could be taken offline, manipulated, or used to facilitate further attacks.
Lateral movement: A compromised server could provide an initial foothold for attacks against other connected systems.

What do we know about these vulnerabilities?

Three vulnerabilities have been associated with the PHP2Shell disclosure:

Identifier	Severity	Impact
CVE-2026-109618	CVSS v4.0 9.2 – Critical	RCE via OOM corruption
CVE-2026-109619	CVSS v4.0 9.2 – Critical	RCE via stale global state
CVE-2026-115560	Unknown	RCE

The PHP team provided the following mitigation steps:

If you cannot update immediately: while only an update is a complete solution, the following
measures reduce exposure to specific attack paths but do not make an installation safe.

RCE via OOM corruption (CVE-2026-109618):

Set memory_limit=-1, preferably in a way applications cannot override, such as php_admin_value in the FPM pool or Apache configuration, and check that no pool, directory or application setting puts a finite limit back. This removes the controllable PHP memory limit failure, but an underlying allocation failure can still reach the vulnerable
path.

Set a low post_max_size. For applications that do not require file uploads, set post_max_size = 8M. If file uploads are necessary, set post_max_size = 32M. Keep upload_max_filesize below post_max_size. Consider enforcing limits at the web server or proxy level for decoded request size, input field count, multipart part count, header count, and nesting depth. These limits must also cover requests without a usable Content-Length.

Use a container or cgroup limit as an availability boundary, preferably with a policy that kills only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

RCE via stale global state (CVE-2026-109619):

Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini. This blocks the confirmed session paths but not other variants.

On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace path only.

Remove invalid or deprecated settings applied per request that emit diagnostics before initialization. Hiding diagnostics with error_reporting, display_errors or @ does not help.

Fix attacker-reachable fatal errors and execution timeouts, including failures in callbacks,
upload or import processing and cleanup.

RCE (CVE-2026-115560)

Set session.upload_progress.enabled=0 and restart every worker.

As a general recommendation, the PHP team advises updating PHP instances to PHP 8.5.12, 8.4.27,
8.3.36 or 8.2.35.

Understanding the risk

Remote code execution vulnerabilities allow an attacker, under certain conditions, to cause a vulnerable application or software component to execute code that the attacker controls. Successful remote code execution can result in defacement, database exfiltration, deployment of webshells or malware, and full compromise of the hosted application.

Has PHP2Shell been exploited in the wild?

As of 23 October 2026, there are active PHP2Shell exploitation attempts without evidence of successful compromise.

On 21 October 2026, Amazon’s security team reported detecting PHP2Shell exploitation attempts in its MadPot honeypot infrastructure and explicitly stated “PHP2Shell is now being broadly exploited in the wild”.

Amazon reported on:

17 October 2026: First identified exploitation attempt, four days before public disclosure.

21 October, 02:00–08:00 UTC: Additional exploitation attempts from multiple anonymised sources.

21 October, after patch publication: Additional PoCs appeared and were used against AWS sensors almost immediately.

Cloudflare confirms that it observed malicious traffic targeting its customers but did not provide proof that customer systems were compromised.

NVISO confirms network-wide attempts to exploit the vulnerabilities, without success so far and partially aligning with Sophos observations. We have also observed some attempts that crash the server.

WatchTowr also confirms exploitation attempts of both vulnerabilities in the wild.

The company VulnCheck claims to have a working exploit for CVE-2026-109618, but we have not been able to confirm it.

There are currently at least 748 public GitHub repositories related to PHP2Shell, some with more than a thousand stars. However, no publicly available exploit has yet been confirmed to reliably achieve full exploitation of the vulnerabilities.

Developing a reliable exploit is difficult, as it requires bypassing Address Space Layout Randomization (ASLR) while simultaneously exploiting the vulnerability to achieve stable code execution. Over time, crafting an exploit and sharing it publicly for free demands a growing investment of time and money, reducing the incentive to do so.

The absence of a publicly available exploit does not mean no working exploit exists. Researchers involved in the coordinated disclosure of the vulnerabilities have one, and it is plausible that threat actors have developed their own, even though no successful compromise has been reported so far.

How can organisations protect themselves?

NVISO recommends a risk-based response, starting with internet-facing and business-critical PHP deployments.

Identify potentially affected systems

The priority is understanding where PHP is deployed. Organisations should inventory internet-facing websites, internal applications, hosting environments, containers, and third-party products relying on PHP. For each installation, identify the PHP version, hosting platform, application owner, business criticality, and external accessibility. Do not overlook legacy applications or PHP runtimes bundled with vendor-managed software.

Reduce exposure until patches are deployed

Where immediate remediation is not possible, organisations should consider restricting access to high risk PHP applications. Depending on business requirements, this may involve:

Restricting access through VPNs, network allowlists, or authenticated gateways.
Temporarily disabling non-essential internet-facing PHP services.
Segmenting web servers from sensitive internal environments.
Reviewing outbound connectivity and limiting unnecessary network access.
Applying validated vendor-provided protections or Web Application Firewall rules where
available.
A Web Application Firewall is not a replacement for patching, especially when the vulnerabilities’ technical characteristics have not been fully established.

CERT-EU has recommended considering isolation of internet-facing applications where immediate patching cannot be performed.

Prepare for emergency patch deployment

The PHP security team released emergency security updates on 21 October 2026 at 13:30 UTC. Organisations should deploy them promptly by identifying responsible system owners, following standard update procedures, arranging maintenance windows, and establishing appropriate rollback plans. When applying the releases:

Confirm the affected and fixed PHP versions.
Apply the relevant security updates, prioritising externally accessible systems.
Coordinate with managed hosting providers and software vendors where PHP is not directly
administered.
Validate application functionality after updating.
Verify that production web-server processes are using the patched PHP runtime.

It is important to note that updating a content management system or web application does not
necessarily update the underlying PHP installation.
Organisations using end-of-life PHP branches should evaluate migration to supported versions or obtain
confirmation of vendor-maintained security backports.

Strengthen detection and monitoring

Security Operations Centres should increase monitoring of PHP-based infrastructure, particularly for unexpected behaviour originating from web-server processes. Useful detection opportunities include:

Suspicious process execution: Monitor for PHP or web-server processes such as php-fpm, php-cgi, apache2, or httpd launching unexpected command interpreters, including sh, bash, or PowerShell.
Potential payload retrieval: Investigate unexpected execution of download utilities such as curl or wget by web-server processes, especially when followed by script execution.
Suspicious web activity: Review HTTP access logs, reverse-proxy telemetry, and WAF events for unusual request patterns, unexpected requests to PHP endpoints, or significant increases in server errors.
Signs of post-exploitation: Monitor newly created PHP files in web-accessible directories, unexpected outbound connections, suspicious scheduled tasks, modified services, or unauthorised user-account
changes. These are general behavioural detection opportunities associated with web-server compromise. They should not be interpreted as validated PHP2Shell-specific detection signatures. Where suspicious activity is identified, organisations should preserve relevant evidence and investigate whether compromise occurred before patch deployment.

Verify remediation and continue monitoring

Patching should be followed by verification. Security teams should confirm that affected systems have been successfully updated, necessary services have restarted, and no vulnerable runtime instances remain active.

Additional attention should be given to load-balanced environments, containers, staging environments, and systems maintained by third-party providers.

Because exploitation could occur before remediation, organisations should also review relevant historical telemetry and investigate signs of compromise.

What happens next?

With the patches now public, attackers are actively reverse-engineering them to produce reliable exploits. Exploitation attempts are already being observed in the wild (see above) and are expected to intensify in the coming days as public PoCs mature. Organisations should treat patching as time-critical and continue monitoring official PHP security announcements and trusted security advisories for further updates.

NVISO recommendations

Our immediate recommendations are to identify PHP deployments, prioritise exposed assets, reduce
attack surface, prepare emergency patching, and strengthen security monitoring. Given the critical severity and potential reach of these vulnerabilities, organisations should not wait
for confirmed widespread exploitation before taking preventive action.

NVISO’s Threat Intelligence and CSIRT teams continue to monitor this developing situation. If your organisation requires assistance assessing exposure, responding to potential exploitation, or
investigating suspicious activity, contact NVISO CSIRT.

References