PHP2Shell, Day Two: The Fix Is Out, Attackers Were Probing Days Earlier, and What to Do Depending on Where Your Site Lives

Yesterday’s question was when the fix would arrive. Today’s is whether it reached your servers in time. PHP released the updates on Wednesday, and by Thursday morning the attack traffic against the two flaws, known together as PHP2Shell, was measured in the millions of attempts.

This briefing is based on SecurityWeek’s report on early exploitation, with additional detail from The Hacker News on Amazon’s honeypot findings and the patch release and PHP’s advisory, and from Amazon’s own write-up.

What changed since yesterday

The fixes shipped. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 close both flaws, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on CVSS version 4.0. CISA urged organizations to update to those versions immediately.
Someone knew early. Amazon’s threat intelligence team says its MadPot honeypots logged an exploit attempt on October 17, while the bugs were still under embargo. It came from a commercial anonymization network, and Amazon says it does not know how the attacker got the details ahead of time.
The embargo frayed at the end. According to the PHP Foundation, as reported by The Hacker News, the research firm Calif mistakenly posted a video of its working exploit around 20:00 UTC on October 20 (4 p.m. Eastern), and vendor Chainguard published built images containing the fix about six hours before the official release, giving attackers a patch to study.
The volume exploded. Cloudflare CEO Matthew Prince said his network saw thousands of attempts in the 10 hours before the announcement, tens of thousands in the 45 minutes after it, hundreds of thousands within two hours, and millions by Thursday.

How bad is it right now?

Noisy, but not yet a confirmed disaster. Amazon describes PHP2Shell as now broadly exploited in the wild. watchTowr, however, says most of the exploit code being sprayed around either does not work, only probes for timing differences, or crashes the target, and SecurityWeek reports that the organizations tracking the activity described the attempts as unsuccessful. VulnCheck saw one Chinese IP address fail in an attempt to plant a webshell. JFrog has spotted fake exploits and prank malware on GitHub. No source has reported a confirmed break-in of a specific server.

That is not a reason to wait. Censys counted roughly 1.57 million internet-facing hosts on October 21 that reported an identifiable PHP version and were not patched. VulnCheck counts more than 700,000 hosts on PHP 3.x through 7.3 and nearly 400,000 more on 7.4, 8.0 or 8.1, all of which are past end of life.

The risk is not theoretical for businesses either. The Hacker News reports that HR software provider BambooHR took its service offline in the U.S., Canada and Ireland as a precaution, warning customers that payroll would be interrupted.

Your action list, by where the site lives

1. Shared or managed hosting

You probably cannot patch PHP yourself, so ask your host directly whether its PHP runtimes carry the October 21 fixes and when your account was updated. Some hosting vendors are moving fast: CloudLinux, for example, has released fixed packages for its ea-php and alt-php builds. Updating WordPress, plugins or themes does not change the PHP runtime underneath.

2. Your own virtual or physical server

Update the PHP packages, then restart Apache, PHP-FPM and any long-running PHP workers, because the old code stays in memory until they restart. PHP’s advisory rates servers using Apache’s mod_php as the highest risk. If you rely on Linux distribution packages, check the package changelog for the two CVE numbers rather than the version string. Distributions received the patch early and may ship it under an older-looking version number.

3. Containers and build pipelines

Rebuild images on a patched base, redeploy, and confirm the old containers are actually gone. A fixed image sitting in a registry protects nothing while the old one is still serving traffic.

4. End-of-life PHP (8.1 and older)

The PHP project does not ship updates for these branches. Its security team has published source backports for 7.4, 8.0 and 8.1 for people building from source or waiting on a vendor. If neither applies, plan an upgrade, and in the meantime consider taking the site offline, which CISA and the U.K.’s National Cyber Security Centre have suggested for systems that cannot be fixed quickly, or at minimum put it behind a web application firewall as a stopgap. Note that PHP 8.2 itself reaches end of life on December 31, 2026.

5. PHP you did not know you had

Appliances, control panels, intranet tools and old marketing microsites often carry their own copy of PHP. Check them with each vendor.

After you patch: were you hit before you got there?

Configuration tweaks circulated before the release, such as disabling session upload progress, are not a complete fix, according to PHP’s advisory. Only updating fully protects a server. Because the exploit can also read memory from PHP workers, passwords, tokens and API keys handled by a vulnerable server could have been exposed.

The researchers suggest looking for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oddly large PHPSESSID cookies, and unexplained PHP worker restarts.
CrowdStrike warns that a successful attack can leave almost nothing behind except a single memory-limit fatal error in the web server log, the kind of entry that usually gets dismissed as noise.
The FBI advises watching for PHP processes that unexpectedly launch command shells or download files.
If anything looks off, rotate the secrets stored on or used by that server, such as database passwords and API keys.
The fix adds a new hard memory limit, so recheck memory_limit and post_max_size against what your application actually needs.

What this means for your company

For most small and mid-size businesses, the work today is mostly questions and follow-up. Make a list of every website, portal and web-based tool your company runs or pays for. For each one, find out who is responsible for PHP and get written confirmation that it was updated, or a date when it will be. Keep that list afterward, because the next runtime-level flaw will need the same answers. If you handle the servers yourself, patch and restart today, then review logs back to at least October 17. If a site cannot be patched, take it offline until it can. A few hours of downtime costs far less than a compromised server that exposes customer data.

Need help finding every PHP system your business depends on, confirming it is patched and checking for signs of earlier compromise? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.