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):
|
Vulnerability
|
What goes wrong
|
|
|
Out-of-memory handling can interrupt PHP while internal request data is only partly set up. Request cleanup can then treat that invalid data as valid ( PHP advisory). |
|
|
Internal state belonging to one request can survive after its memory has been freed. A later request handled by the same worker can then use that stale state ( PHP advisory). |
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).
-
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.
3. Attackers can't plant a script to read your secrets. This is the setting that matters most after a breach. With the "Script will only work with other encoded files" option (--conj), protected scripts only work alongside other encoded files from the same project. The manual's own example: if a.php holds a password, an attacker can't swap in their own c.php that runs echo $password, and can't create a d.php that includes a.php to print it (
SourceGuardian 13 User Manual). SourceGuardian recommends always using this option when a project contains usernames, passwords or database names.
4. Dropped web shells won't execute. You can install the loader server-wide and set sourceguardian.restrict_unencoded = "1" in php.ini. PHP will then refuse to run any script that isn't SourceGuardian-protected (
SourceGuardian 13 User Manual). A web shell uploaded through php2shell, or any other bug, fails with a loader error instead of running.
5. Keep secrets in the encrypted area. Custom constants can be stored inside the encrypted part of a protected script, or in an external license file, and read with sg_get_const() (
SourceGuardian 13 User Manual).
SourceGuardian supports PHP 5.x, 7.x and 8.x, including PHP 8.5 (
SourceGuardian). PRO also integrates with CI/CD pipelines, so encoding can happen automatically on every deployment (
SourceGuardian blog).
What encoding does not do
To be clear about the limits: SourceGuardian does not fix php2shell, and it is not a substitute for patching. While your application is running, it still has to use its database credentials, so they exist in the PHP worker's memory. A memory-disclosure bug like the one Wiz demonstrated could expose them whether or not your code is encoded. Encoding removes the easy wins: plain-text config files, a copyable codebase and working web shells. It forces an attacker to work much harder for much less.
Use it as one layer of defence-in-depth alongside the other basics:
-
Patch PHP promptly.
-
Run a WAF in front of your sites.
-
Give your database user only the privileges the application needs.
-
Restrict database access to your application hosts.
-
Rotate credentials after any suspected compromise.
php2shell is a reminder that your application's security also depends on the runtime underneath it. Patch now. Then assume that one day an attacker will get a shell on one of your servers, and make sure that when they do, your source code and the credentials inside it are useless to them.
