php2shell after the patch: exploitation and what to check

On October 21, PHP released fixes for two flaws (known as php2shell) that can allow arbitrary code execution without authentication. I covered how to tell which servers are affected, and the mitigations for when you can’t update yet, in the previous article. This article adds only what became clear in the half day or so after the fixes came out, and only what helps people who have already updated, or are about to, make decisions.

What has happened since the fixes came out#

Times are Japan Standard Time (JST, UTC+9).

Date and time	Event
October 21, 12:02	Cloudflare turns on its WAF rules by default on every plan that uses the WAF, including Free
October 21, 16:41	Chainguard publishes images with the fix more than 6 hours ahead of schedule (per the PHP Foundation)
October 21, around 23:00	PHP publishes the fixed versions (8.5.12, 8.4.27, 8.3.36, 8.2.35)
October 21, 23:19	watchTowr reports that it is seeing exploit attempts against both flaws (per The Hacker News)
After the fixed versions	Ubuntu publishes fixed packages (USN-8948-1)
October 22	JPCERT/CC, Japan’s computer emergency response team, publishes an alert (Japanese)
October 22, morning	Exploit attempts observed by Cloudflare reach the millions (per The Hacker News)
October 24	PHP discloses a third flaw (CVE-2026-115560) without an emergency fix (per The Register)

In its FAQ, watchTowr says it has seen real exploitation of both flaws on its network of decoy servers (honeypots). According to The Hacker News, watchTowr had said as of 20:26 JST the same day that it had not seen any. Cloudflare writes that it saw attack traffic against customer sites while the details were circulating ahead of schedule, and that attackers were rewriting their payloads to get around its rules.

According to The Hacker News on October 23, some of the attacks tried to plant “Potassium”, a botnet derived from Mirai. Sophos’s analysis describes it as an updated version of a known variant with DDoS capabilities.

On the other hand, as of that same article there were still no reports of a successful intrusion into a specific server. Sophos, Previdian, SOCRadar and Wordfence all say they have not confirmed a successful case. When I checked on October 25, neither flaw was on the list of vulnerabilities with confirmed exploitation (KEV) that the US CISA publishes.

The reason to hurry anyway is that the attack tooling is in place. According to Krebs on Security, Wiz, one of the companies that found the flaws, thinks large-scale exploitation is likely, aimed at planting backdoors for remote control over the web (web shells). Wiz compares the flaws to Log4Shell in 2021 and expects some organizations to take a long time to fix them.

Check the changelog, not the version number#

With distribution PHP, the version number shown by php -v does not change after the fix. Following Debian’s advice, The Hacker News says to check whether the CVE numbers appear in the package changelog rather than relying on the version number. In my test environment (Ubuntu 24.04.5 LTS, October 22), updating php8.3-cli gave the following.

$ dpkg-query -W php8.3-cli
php8.3-cli	8.3.6-0ubuntu0.24.04.13
$ php -v | head -1
PHP 8.3.6 (cli) (built: Oct 19 2026 15:16:58) (NTS)
$ zcat /usr/share/doc/php8.3-cli/changelog.Debian.gz | grep -E 'CVE-2026-10961[89]'
    - debian/patches/CVE-2026-109618_109619.patch: Avoid state corruption via
    - CVE-2026-109618
    - CVE-2026-109619

php -v still shows 8.3.6, the same as before the update, while the changelog contains both CVE numbers. For RPM packages, search the output of rpm -q --changelog <package name> the same way. PHP that runs on the web comes from packages separate from the CLI, such as php8.3-fpm and libapache2-mod-php8.3. Check that every one of them is at the same version.

Even for 8.1 and earlier, which the PHP team does not update, distributions sometimes ship fixes. Ubuntu fixed PHP 8.1 on 22.04 in 8.1.2-1ubuntu2.28. According to Ubuntu’s CVE page, fixes for the older 7.4 and 7.2 come through Ubuntu Pro, and fixes for 7.0 and 5.5 through Legacy Support, an add-on subscription to Ubuntu Pro. Ubuntu Pro is free for personal use on up to 5 machines.

Gaps that remain after updating#

The Hacker News warns that updating applications such as WordPress or Laravel does not update the PHP running underneath them. PHP comes from a server package, a hosting provider or a container image, and each one needs updating. After updating, restart Apache, PHP-FPM and any long-running PHP workers. Until you restart, old processes keep running the unfixed code.

A third flaw (CVE-2026-115560) was also disclosed on October 24. According to The Register, it can also allow code execution, but only with rarely used settings, such as switching the session serialization format at runtime. So PHP is not issuing an emergency fix and will fix it in the next regular release. Until then, setting session.upload_progress.enabled=0 in php.ini avoids it. Updating to the fixed versions above does not fix this third flaw.

If a hosting provider manages your PHP, confirm with the provider that the fix has been applied. For PHP inside products and appliances, the SANS Internet Storm Center has compiled vendors’ responses. The examples it lists are Cisco, OPNsense, pfSense and Palo Alto Networks. SANS expects more updates for open source firewalls and routers that use PHP, and asks that their web admin interfaces not be exposed to the internet.

According to The Hacker News, the fixed versions add a new hard memory limit. When a process hits it, the process ends and the shutdown handlers do not run. After updating, it seems worth reviewing whether memory_limit and post_max_size match what your application needs. If you set memory_limit=-1 as a mitigation, you will likely need to revert it after updating.

If you use Cloudflare’s WAF#

Cloudflare has described its php2shell protections and how to check your settings in the blog post “Cloudflare deploys protections against php2shell vulnerability”.

On the Free plan, the rules are on automatically. On paid plans (Pro, Business, Enterprise), Cloudflare asks you to confirm that the Managed Ruleset is running in block mode. You can see blocked traffic in the dashboard under Security > Security Analytics > Events by filtering on the rule ID. Cloudflare says the WAF is not a substitute for updating, and recommends keeping the protection on after you update.

What to look for if you suspect an intrusion#

According to Wiz, this attack runs in a layer below the application, so it may leave almost no trace in application logs. Wiz says to watch for these signs:

• Memory limit errors or HTTP 500 responses right after unfamiliar multipart requests
• PHPSESSID cookies in responses that are unusually large or malformed
• PHP workers that keep cycling or restarting for no clear reason

An early exploit shared by the SANS Internet Storm Center sent multipart requests containing a long file name of about 5MB. SANS says that although the code is unreliable, it gives clues about what to look for in real attacks.

Cloudflare saw attack traffic even before the fixed versions came out. It seems wise to preserve your access logs and error logs from the advance notice through your update before they rotate away. That applies to servers you have already updated too.

According to Wiz and The Hacker News, it has been demonstrated that attackers can read the memory of PHP workers without executing code. That memory can hold passwords, authentication tokens, API keys and certificates from other requests. On servers where you find the signs above, you will likely need to rotate the secrets stored there.