0day Protection | Ruijie Security Lab In-depth Interpretation of PHP "php2shell" Remote Code Executi

On October 21,2026, the official PHP team released a security advisory, patching two "critical"-level vulnerabilities (CVE-2026-109618, CVE-2026-109619, known in the industry as php2shell, with domestic identifiers CNVD-2026-41674 / 41675), both carrying a CVSS score of 9.2.

At the same time, Japanese Prime Minister Sanae Takaichi made a rare direct appeal to businesses on a message posted on X, urging organizations running PHP-based websites to prepare for an emergency patch — and to consider temporarily taking sites offline if they couldn’t apply it fast enough. It’s an unusually technical intervention from a sitting head of government — normally the kind of guidance that comes from a national cybersecurity agency, not a prime minister’s own social media account.

FBI’s Cyber Division (@FBICyberDiv) account posted similar guidance on X, naming the two vulnerabilities by their CVE identifiers and recommending that organizations unable to patch immediately “take the system offline until it can be fully mitigated.” The post also advised inventorying where PHP runs across an organization’s environment, prioritizing internet-facing systems, watching for PHP processes spawning unexpected command shells, and reporting any signs of compromise to a local FBI field office or ic3.gov, alongside pointers to a CERT-EU advisory and CISA’s Known Exploited Vulnerabilities catalog. 

The official wording is unusually direct: there is no complete mitigation solution, and upgrading is the only safe option.

PHP is the most widely used server-side language on the internet. This is not a vulnerability that can be put off until later.

I. What kind of vulnerability is this

Simply put, to run faster, a web server does not spawn a new "worker" for every visitor; instead, the same worker handles the next visitor in sequence. Under normal procedures, before a worker attends to a new visitor, it will first clean up all the belongings left behind by the previous one.

These two vulnerabilities essentially cause the "cleanup" step to fail under certain conditions. An attacker sends a specially crafted upload request, disrupting the state held by the worker process; when the next visitor arrives, the worker is left with the residual state from the previous round. Exploiting this residual state, the attacker can inject and execute their own commands.

The result is: no account required, no password required, no need to trick anyone into clicking a link, and a single request could potentially take over the server.

What can you do after obtaining it? You can execute arbitrary commands as the website process, thereby taking control of the entire web service; you can also crash the service; additionally, you can read out passwords, tokens, API keys, and certificates stored in memory.

The most critical point to highlight: this has absolutely nothing to do with what program your website uses or what code you've written. As long as the PHP engine version is vulnerable, even a simple official website with only a few pages is well within the strike range.

II. Why this issue demands particular attention this time

High usage share: Among websites whose server-side language can be identified, approximately 75% use PHP; around 43% of all websites worldwide run on WordPress.

Wide-reaching impact: When the vulnerability was disclosed, approximately 22.6 million relevant instances were exposed on the Internet; meanwhile, around four-fifths of servers do not expose their exact PHP version to the public, so the actual scale of affected instances is bound to be even larger.

Actively Exploited in the Wild: The Proof of Concept (PoC) for this vulnerability has been publicly circulated, and real-world attacks have emerged on live networks. According to the observation data from Ruijie Security Cloud, even before the IPS rule library was updated, 68 relevant attack alerts were detected within the 24-hour window on October 21 alone, with multiple waves of attacks occurring throughout the day, indicating that attackers have been conducting bulk scanning and probing. The protection policy has detected and blocked multiple exploitation incidents targeting the PHP2Shell vulnerability.

Live Network Attack Packet Samples

There is one deployment pattern that poses the greatest risk: sites using Apache + mod_php face the highest level of risk, as attacks can be completed even before your web application starts up, completely independent of what application you are running.

PHP2Shell Attack Time Distribution Trend

III. How Enterprises Can Defend Themselves: No Need to Understand the Principles, Just Get Three Things Done

First: Check the version

Log in to the server and run the following command:
php -v

Refer to the table below: if the version number is lower than the "safety line", treat it as "infected" and don't take any chances.

Branch	Safety Line
PHP 8.5.x	≥ 8.5.12
PHP 8.4.x	≥ 8.4.27
PHP 8.3.x	≥ 8.3.36
PHP 8.2.x	≥ 8.2.35

As a side reminder: official support for PHP 8.1 and earlier versions has been discontinued. These servers often "seem fine with their current version number and have run stably for years", but they are still affected, and there will be no new official releases, so you need to contact your distribution or LTS vendor to confirm backported patches.

Second: Upgrade

# Debian / Ubuntu
sudo apt update
sudo apt install --only-upgrade php8.4-fpm php8.4-common php8.4-cli

# RHEL / CentOS / Rocky / AlmaLinux
sudo dnf update php\*

Re-pull the patched base mirror in the container environment (e. g., php: 8.4.27-fpm), and perform rolling restart after rebuilding.

Third: Restart — the Most Easily Overlooked Step

Upgrading without rebooting is as good as not fixing anything at all.

Resident processes like PHP-FPM and Apache load the old code from memory. Even after the installation package is replaced, the processes are still running the old code. You have to restart all workers, and invalidate OPcache as well if it's enabled.

If you skip this step, the previous two things will have been done completely in vain.

IV. Ruijie Network Protection Solution

Specific operation: Upgrade the IPS/WAF rule base to v20261022.130 [Note: This version (displayed in small print) already includes the detection capabilities for CVE-2026-109618 and CVE-2026-109619]. After enabling automatic upgrades in the "System → Feature Library Upgrade" menu, the feature library will be automatically updated via the Internet; For devices not connected to the Internet, you can log in to Ruijie Security Cloud official website to download the latest rule base for offline upgrade.

Ruijie Firewall IPS Alert

Ruijie Firewall WEB Application Protection Alert

Ruijie Security Laboratory has completed the verification of detection capabilities based on real-machine reproduction. Meanwhile, Ruijie Security Cloud continuously conducts live network monitoring based on logs reported by client-side firewalls, has detected and blocked multiple php2shell exploitation incidents through existing protection policies, and has synchronously supplemented special detection rules.

Protection Link	Ruijie Capabilities	Supported Models
Exploit Blocking	The IPS/WAF rule base v20261022.1304 has covered the exploit features of two CVEs, and is capable of identifying multipart upload traffic with attack signatures.	Ruijie Z/CF Series Firewalls
Attack Variant Identification	Skywork Lab completed testing capability verification based on real machine reproduction, and supplemented special rules for variants.	Ruijie Z/CF Series Firewall
Live Network Threat Monitoring	Security Cloud conducts continuous monitoring based on logs reported by customer firewalls. On October 21 alone, it detected 68 attack alerts and has blocked multiple exploitation incidents.	Ruijie Secure Cloud + Z/CF Series Firewalls

Boundary protection cannot serve as a substitute for upgrading.

This point must be made exceptionally clear: a WAF/IPS only serves as a temporary buffer. It cannot block all attack variants, nor can it prevent attackers from bypassing the CDN to connect directly to the origin server. When a "block successful" alert pops up on the device, it only means that this particular attempt was stopped, and does not mean that your host has been fixed.

The correct response sequence is: first add rules at the boundary to buy time → go back to the host to verify the actual PHP version → upgrade and restart the worker → then conduct forensics on the logs and database, for example, check whether there is any abnormal write operation in the user table of the web application.

Concluding Remarks

Just remember these three steps: check the version, upgrade, and restart
There is no need to understand memory or study the principles of vulnerabilities
Never put off till tomorrow what you can get done before leaving work today.
For further assistance, please access our website for more details.
https://www.ruijie.com/en-global/cybrey/cybrey-firewalls/