If you run PHP anywhere, this one is worth your attention today. The PHP2Shell flaws have moved from “people are scanning and failing” to “someone got code execution on a honeypot.” That changes the urgency of patching.
What the source reports
According to BleepingComputer, PHP2Shell is the collective name for two critical remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619. They have now been successfully exploited in the wild.
The activity was caught by Adel Karimi, detection and response lead at Perplexity. His honeypots recorded confirmed remote code execution against an Apache mod_php installation running PHP 8.4.26. Karimi described it this way: “This is now confirmed RCE with usable memory disclosure, not just a crash followed by a suspicious process.” The response included an 800 KiB decoded cookie dump, and a function address derived from that dump using the public exploit’s offsets showed up in the later execution payload.
Karimi was also careful about scope. He said the evidence shows the chain working on an “intentionally favorable single-worker mod_php profile.” It is not a measure of how reliable the exploit is on other worker counts, PHP builds, or applications.
Marcus Hutchins of Expel, who has been tracking a stream of alleged PHP2Shell exploitation reports, confirmed the findings. He called it “by far the highest quality confirmation of in-the-wild php2shell exploitation” he had seen so far.
The timeline
The sequence matters here, so here it is as reported:
- The PHP security team asked admins to prepare for security updates one day before releasing them.
- The patches shipped on Wednesday, October 21.
- Details of the flaws, including the CVE IDs and mitigation advice given to some critical infrastructure providers, leaked online before the patches went live. Some proof-of-concept exploits were also published. The PHP security team said none of those were functional.
- Cloudflare, Hadrian, watchTowr, Previdian, and Patchstack all detected exploitation attempts before public disclosure, but flagged them as unsuccessful.
- Amazon Threat Intelligence saw attackers targeting the flaws four days before patches were released.
- Until Karimi’s findings, Dataminr’s TRACE team described the activity as limited to scanning, fingerprinting, and non-working exploits, with no known compromises.
CISA shared a SIGMA detection rule for PHP2Shell exploitation attempts on Friday. As of the article, it had not flagged the flaws as exploited in the wild.
A separate unpatched PHP bug
There is a second item in the same story. On Friday the PHP security team shared mitigations for a new RCE vulnerability, CVE-2026-115560, which has no patch yet. Per the source, it can only be exploited on systems “with an unusual combination of configuration and application code.”
Until a fix ships, the PHP developers advise setting session.upload_progress.enabled=0. The source notes this is the same mitigation that was recommended before the PHP2Shell patches came out.
Why the scale matters
The article cites VirusTotal estimates that PHP runs roughly 70% of all websites. It also puts the number of PHP hosts exposed online at more than 5.1 million, with roughly 3.8 million having at least one port open to attacks. Even if only a small slice of those are vulnerable and exploitable, that is a large pool for attackers to work through.
My analysis
This section is my own read, not something the source states.
The caveat is real, but don’t lean on it. Karimi was clear that the demonstrated chain was on a favorable single-worker mod_php setup. That tells me exploitation is not yet proven to be easy everywhere. It does not tell me you are safe. Exploits tend to get more reliable over time, especially once a working public chain exists. The article says the exploit’s offsets were public, and the function address in the payload was derived from them. I would treat the reliability gap as a window that is closing, not a safety margin.
The pre-patch activity is a warning about disclosure. Leaked CVE IDs and mitigation advice, followed by multiple vendors seeing attempts before the patch, shows attackers were ready to move. The early attempts failed, but the interest was there. Now there’s a working example to build from.
mod_php deployments deserve extra scrutiny. The confirmed case was Apache with mod_php. I can’t say from the source how other setups like PHP-FPM compare, so I won’t guess. But if you run mod_php, I’d put those hosts at the front of the queue.
The unpatched bug is a reminder to check configuration, not just versions. Patching fixes PHP2Shell. CVE-2026-115560 needs a config change today. That is a different kind of work, and it’s easy to miss if your process only tracks version numbers.
Practical takeaways
- Patch PHP now. The fixes have been available since October 21. If you’re on a vulnerable build, prioritize internet-facing hosts first.
- Find your PHP. Inventory every host and container running PHP, including old apps nobody owns. The source’s numbers suggest plenty of exposed hosts are out there.
- Prioritize Apache mod_php. That’s the stack where exploitation was confirmed.
- Set
session.upload_progress.enabled=0where you can. The PHP team recommends it for the unpatched CVE-2026-115560, and it was recommended earlier for PHP2Shell too. Check first that nothing in your applications relies on upload progress tracking. - Deploy the SIGMA rule. CISA published one for PHP2Shell exploitation attempts. Run it against your logs, and look backward as well as forward, since attempts were seen before the patches.
- Hunt for crashes and odd child processes. Karimi’s wording, “a crash followed by a suspicious process,” describes the kind of pattern earlier, less successful attempts left behind. Web server worker crashes followed by unexpected processes are worth investigating.
- Don’t wait for an official exploited flag. CISA hadn’t marked these as exploited in the wild at the time of the article. Two credible researchers have confirmed it. If your process waits on a catalog entry, you may be late.
Bottom line
The situation went from noise to confirmed compromise on a test system within days of the patch release. Patch, apply the config mitigation, and check your logs. It’s a few hours of work now versus an incident later.
Sources
- PHP2Shell security flaws now sucessfully exploited in the wild — BleepingComputer, 2026-10-26
