On 21 October 2026, the PHP project released an emergency security update for two critical vulnerabilities in the PHP runtime, CVE-2026-109618 and CVE-2026-109619. Together they are known as php2shell. Both are rated CVSS v4.0 9.2 (Critical), and both can let an unauthenticated attacker run code on your server with nothing more than specially crafted HTTP requests (CrowdStrike).
This post covers what php2shell is, how the industry has responded, what you should do today, and where SourceGuardian fits in. Patching closes the hole. Encoding your code limits what an attacker can take if they get in anyway.
What php2shell is
The two flaws sit in PHP's core memory management and error handling, which almost every request passes through (The PHP Foundation):
Some of the details make this one especially serious:
-
It affects PHP itself, not your application. Wiz says even a simple "Hello World" app on an affected version can be vulnerable, and that every PHP release of the last decade, back to PHP 5.4, is affected by at least one of the issues.
-
Every common deployment model is at risk. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team rates mod_php as the highest risk, because an unauthenticated request can trigger the attack before any application code runs (PHP advisory).
-
Popular platforms have been shown to be exploitable. Wiz demonstrated pre-authentication remote code execution against stock WordPress, Drupal and Joomla images. It also showed remote leaks of PHP worker memory, which can expose passwords, authentication tokens, API keys and certificates (Wiz).
-
Attacks have started. watchTowr saw its first in-the-wild exploitation attempts around the time the patches were published, and Hadrian reported exploitation "at scale" (SecurityWeek). Singapore's Cyber Security Agency has warned of widespread exploitation attempts and several public proof-of-concept exploits (CSA Singapore).
How the disclosure unfolded
The root cause was first spotted during PHP's 2024 external security audit by Quarkslab. Its full impact only became clear in 2026, when Ryan A at Calif, OpenAI and Wiz each reported working attack paths (The PHP Foundation). Much of that research ran through OpenAI's Patch the Planet programme, which used frontier AI models to find critical bugs before attackers did.
The CVE IDs leaked on 20 October, so PHP brought the release forward by a day to 21 October at 14:00 UTC (The PHP Foundation).
How the industry responded
A large coordinated response followed:
-
Cloudflare rolled out WAF rules on all plans, including Free, from 21 October at 03:02 UTC. It also launched a new "full transaction detection" feature that checks the origin server's response as well as the request (Cloudflare).
-
Microsoft published Azure Front Door and Application Gateway WAF mitigations, which it describes as a "temporary, supplementary measure" (Microsoft Tech Community).
-
Akamai, Imperva, Fastly, Sucuri and CloudLinux (Imunify360) also shipped rules. All of them still tell customers to patch (php2shell.eu, php2shellcheck).
-
Ubuntu and other Linux distributions received the patches early and shipped fixed packages (Ubuntu).
-
CrowdStrike, Sophos, Elastic, Tenable and Huntress published detection and response guidance (CrowdStrike, Sophos, Elastic, Tenable, Huntress).
Every vendor says the same thing: a WAF buys you time, but it is not a fix. A WAF also does nothing if attackers can reach your origin server directly (php2shell.eu). Sophos adds that in-process protections may not help either, because on mod_php the bug can be triggered before any application code runs (Sophos).
What you should do now
-
Update PHP. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. You can also use your distribution's patched packages. If your host manages PHP, ask them to confirm they have applied the update. PHP 8.1 and older no longer get official fixes, so contact your LTS vendor or upgrade (PHP advisory).
-
If you can't patch straight away, apply the interim settings. Set memory_limit=-1 so applications can't override it, set a low post_max_size, set session.upload_progress.enabled=0, and on PHP 8.5 set fatal_error_backtraces=0. Then restart every worker. The PHP team is clear that these settings reduce exposure but do not make a server safe (PHP advisory).
-
Keep your WAF on in block mode, and make sure your origin server can't be reached around it (php2shell.eu).
-
Look for signs of compromise. Watch for unusual multipart requests followed by memory errors or repeated HTTP 500 responses, oversized or malformed PHPSESSID cookies, and unexplained worker restarts (Wiz). Alert on PHP processes that launch shells or download tools, and check your web root for new files and web shells (Huntress).
-
Rotate secrets if you might have been exposed. Because the bugs can leak worker memory, treat database passwords, API keys and session secrets on unpatched, internet-facing servers as potentially exposed (Wiz).
What happens after an attacker gets in
This is the part most advisories skip. CrowdStrike notes that a successful exploit gives command execution as the web server user. It calls this "the standard foothold for deploying web shells, harvesting database and API credentials from configuration files, and pivoting into internal networks" (CrowdStrike).
On a typical PHP server, that step is easy. The attacker opens wp-config.php, .env or config.php and reads the database host, username and password in plain text. They can also copy your entire codebase, including your business logic and licensing checks.
Patching stops the next attacker. It does nothing about what has already been taken. That is the problem SourceGuardian is built to solve.
How SourceGuardian limits the damage
SourceGuardian compiles PHP source code into binary bytecode and then adds an encryption layer. The encoded files run only through the SourceGuardian Loader. This changes what an attacker on a compromised server can actually get:
1. Stolen files can't be read. Your source code isn't on the server. There is only encrypted bytecode, so opening a config file or downloading your codebase gives the attacker nothing readable. That includes any database credentials stored inside protected files. SourceGuardian PRO goes further and splits the bytecode into logical blocks, randomly mixes them and then encrypts them (SourceGuardian PRO).
2. Stolen files won't run anywhere else. Encoded scripts can be locked to an IP address, domain, MAC address or machine ID. The domain, IP or machine ID is also used as part of the encryption key, so the files can't be decrypted and run on another machine (SourceGuardian 13 User Manual). Copying your application to the attacker's own server doesn't work.
