PHP2Shell: The 'End of the World' Vulnerability in PHP and How Major Companies Moved to Contain the Disaster

What Is the PHP2Shell Vulnerability?

On October 21, 2026, the PHP project announced emergency security releases for two critical vulnerabilities in the language core itself, collectively nicknamed PHP2Shell. The flaws, officially tracked as CVE-2026-109618 and CVE-2026-109619, carry a critical severity score of 9.2 on the CVSS v4.0 scale.

The problem is not in a PHP application (like WordPress or Drupal), but in the PHP runtime itself. This means any server running an affected version of PHP is exposed, regardless of how secure the code running on it is. The vulnerability allows an unauthenticated attacker (without logging in) to execute remote code (RCE) on the server, potentially leading to full server takeover or the leakage of sensitive data from memory.

Affected versions include everything from PHP 5.4 onwards, covering nearly 20 years of releases. The patched versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 5.x and 7.x branches are end-of-life and will not receive official fixes, forcing administrators to upgrade to a supported branch.

Why Is It So Dangerous?

The severity comes from a combination of three factors:

Widespread Adoption: PHP powers approximately 70% of websites on the internet, from small blogs to major e-commerce platforms [citation:2][citation:11].
Relative Ease of Exploitation: Although the chain is technically complex (requiring bypassing ASLR, controlling memory timing, and hitting the same Apache “Worker”), security researchers managed to reduce the number of requests needed for exploitation from tens of thousands to around 20 requests in some scenarios [citation:6].
Early Exploitation: Exploitation attempts began before the official disclosure. Amazon’s Honeypot network spotted the first attempt on October 17, four days before the patches were published. After the disclosure, Cloudflare recorded millions of exploitation attempts [citation:6].

Exploitation Impact: What Happens if the Attack Succeeds?

If an attacker successfully exploits the flaw, they gain command execution on the server with the privileges of the web service user (such as www-data or apache). This opens the door to:

Data Theft: Reading configuration files, databases, and API keys.
Malware Installation: Security researchers observed attempts to download botnets similar to Mirai [citation:6].
Espionage and Control: Using the server as a launching point for further attacks within the network.

How Did Major Global Companies Respond?

As the news spread, major companies moved quickly, each in its own domain:

Cloud Giants

Amazon (AWS): Detected attacks early and worked to update its services including Elastic Beanstalk, WorkMail, Amazon Linux, and Lightsail. It also confirmed that its internal systems automatically restrict malicious scanning [citation:7].
Google Cloud: Confirmed that its core infrastructure is not affected, but automatically updated PHP environments in App Engine. It required customers using Cloud Run to manually rebuild their images [citation:2].
Microsoft: (Search results did not provide specific details on Microsoft’s response, but it was among the companies that issued guidance to its customers).

Cybersecurity Firms

Cloudflare: Played a dual role: it revealed millions of exploitation attempts and provided WAF solutions for its customers to intercept attacks [citation:6].
CrowdStrike: Confirmed that exploitation is theoretically possible (it reproduced a successful attack in the lab), but did not observe successful exploitation in the wild as of writing. It added detection content to its Falcon platform [citation:7].
Palo Alto Networks: Issued guidance and temporary workarounds, and rated the vulnerability’s impact on its products as 8.7 [citation:7].
Sophos: Discovered that its legacy MyUTM portal was running an affected PHP version and took it offline temporarily [citation:7].

Hardware and Enterprise Software Vendors

Cisco: Issued an advisory covering over 30 products, but has not confirmed any as affected so far [citation:7].
Red Hat: Downplayed the severity, rating it 8.1 instead of 9.8, noting that reliable exploitation requires “precise heap manipulation and timing” [citation:7].
Industrial Sector (Siemens, Schneider Electric, ABB): This was the most concerning part. Schneider Electric announced that three of its products were affected. Siemens confirmed that Ruggedcom APE1808 devices were affected. ABB reported that industrial control systems (APROL) and other software were affected [citation:7].

How Did Free Software Projects and Distributions Respond?

Distributions were the first line of defense, and their response was swift and decisive:

Major Distributions

Ubuntu: Shipped fixes for all supported releases on the day of disclosure (October 21) [citation:7].
Debian: Addressed the flaw in its bookworm and trixie releases [citation:7].
Fedora / Red Hat / SUSE / Gentoo / Slackware: All released updated packages on the same day or the next day.
Other Distributions: Such as Alpine and Arch Linux, released updates through their usual repositories.

Free Software Projects

cPanel, Plesk, DirectAdmin: These popular hosting control panels released emergency updates. Most importantly, cPanel and Plesk provided fixes even for end-of-life PHP versions (7.4, 8.0, 8.1), given the severity of the situation [citation:7].
WordPress, Drupal, Joomla: These core PHP-based systems advised their users to update immediately, but did not need to release their own updates because the flaw is in PHP itself, not in their code.

What Should You Do If You Manage a Server?

The only complete remediation is immediate patching to one of the fixed versions. However, if you cannot do that immediately, there are temporary mitigations:

At the Firewall (WAF) level: Block requests with the Content-Type: multipart/form-data header if you do not need file uploads. This temporarily disables file uploads but closes the main attack vector [citation:2].
Disable session.upload_progress.enabled: This blocks one of the attack paths (CVE-2026-109619), but does not protect against the memory exhaustion path (CVE-2026-109618) [citation:8].
Set memory_limit: Although setting it to -1 (unlimited) may seem risky, in this case it prevents the “memory exhaustion” condition that the flaw exploits. However, this is not a magic fix [citation:8].
Restart Services: After updating, you must restart Apache, PHP-FPM, and any background processes running PHP. Updating files on disk is not enough if old processes are still running in memory [citation:3].
Rebuild Containers (Docker): If you use PHP inside a container, you must rebuild the image using the patched version. Updating the package on the host does not reach inside the container.

Summary

PHP2Shell is a harsh reminder that the internet’s infrastructure, despite its age and ubiquity, remains fragile. The speed of the community’s response (distributions, free software projects, and cloud giants) was impressive, but the flaw also exposed the problem of “forgotten devices”—old servers, NAS appliances, and industrial systems running PHP versions no one remembers. If you manage any system running PHP, updating now is not an option; it is a necessity.