PHP2Shell Update: A Mirai Botnet Is Now Trying to Exploit the PHP Flaws. Here's What to Check Beyond Your Website

Update, Oct. 24, 2026. This follows our Oct. 21 post, PHP2Shell: Why Updating WordPress Won't Fix the Critical PHP Flaws. The fix hasn't changed. What's new is who is trying to use the flaws, what to look for, and a PHP setting that's worth confirming.

Attackers running a botnet, a network of hijacked machines rented out for attacks, are now attempting to exploit the two PHP flaws known as PHP2Shell, SecurityWeek reported Friday. As of Saturday morning, Oct. 24, we found no report of a confirmed successful break-in in the wild.

What's new since Wednesday

A Mirai botnet has joined in. Sophos says attackers tried to use PHP2Shell to install "Potassium," which it describes as "a likely Mirai botnet variant." Mirai-family malware turns infected machines into tools for flooding other networks with traffic. Sophos says the attempt it analyzed was blocked, so the malware was never delivered.
A correction worth knowing about. On Thursday Sophos first reported a successful exploitation. Later that day it corrected itself, saying its data shows "scanning and a small number of failed exploitation attempts" and "no evidence of a successful compromise." Its later updates on Friday added detection signatures and did not change that finding.
Others see the same pattern. Arctic Wolf linked two Potassium files to the servers hosting attack payloads, but says its data doesn't show the attacks actually downloading or running them. Hunt.io traced the traffic it saw to "an established Mirai-style IoT botnet" active since at least May 2026 that "just added php2shell to its spreading kit." Google's John Hultquist told The Record his team has not validated exploitation in the wild, but that "exploitation may have already begun in a limited fashion and the threat is viable and very serious."
The exploits are getting better. Researchers have said reliable attacks are hard to pull off. VulnCheck now says it has built one that works against PHP's recommended production settings on common x86-64 servers. It's available only to VulnCheck's paying customers, and the company said it expects attackers to catch up.
Still not on CISA's "known exploited" list. CISA updated its Known Exploited Vulnerabilities catalog on Friday afternoon and added two unrelated flaws. As of Saturday morning, neither PHP2Shell flaw (CVE-2026-109618 or CVE-2026-109619) is listed, and neither is the newer CVE-2026-115560. CISA adds a flaw to that list when it has evidence of real-world exploitation. Its Oct. 21 alert still says to patch immediately.
A setting PHP wants you to keep. On Oct. 23, PHP's developers suggested setting session.upload_progress.enabled=0 until their next regular release. They say it closes "an unlikely RCE vector," now tracked as CVE-2026-115560, that needs an "unusual combination of configuration and application code." The same setting was already listed as a stopgap in PHP's Oct. 21 advisory, so if it was applied then, PHP says to leave it in place. There's no new PHP release for this yet; PHP says a full advisory will come with the next regular release. This setting does not replace the patch: Datadog notes it doesn't fully protect against PHP2Shell.

Why it still matters

Nothing here makes PHP2Shell less urgent. "Mirai" in the headlines doesn't mean your website will turn up on the evening news. It means automated attack tools are sweeping the internet looking for unpatched PHP. That's a numbers game, and small businesses that haven't patched are part of it. Qualys, looking at its own customers' data, counted only 199,000 PHP instances patched within 12 hours of disclosure, and "roughly 110 million" running PHP 5.4 through 8.1, versions that no longer get official fixes, SecurityWeek reported.

Don't stop at the website. CISA notes that "PHP is often a component of other software," so it may be running inside things you don't think of as web servers.

Clear takeaway

No confirmed break-ins yet doesn't mean you can wait. Get it in writing today that your PHP is on 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor build with both fixes), keep session upload progress turned off, and then check every device and app in your office that has a web login, not just your website.

What to do today

Finish the patch. If your host or IT person hasn't confirmed in writing that you're on PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a vendor package with the fix), follow up today, and make sure PHP was restarted after the update. If you're on 8.1 or older, CISA's advice is still to take the system offline until it's updated.
Ask about the setting. Ask whoever runs the server whether session.upload_progress.enabled is turned off, as PHP suggests.
List your boxes with web logins. Make a list of every device or app with a web login page: storage (NAS) boxes, firewalls, camera recorders, phone systems and vendor portals. Ask each vendor whether the product uses PHP and whether it has an update. Make sure none of those login pages can be reached from the open internet.
Hand your IT provider the indicators. Sophos and Hunt.io have published attacker IP addresses and signs to search for. These include requests whose user-agent contains "php2shell," a file named nfs in the /tmp folder, and connections to the addresses Sophos lists. A match means someone tried. It doesn't mean you were breached.
Keep watching. CISA advises monitoring for PHP processes "launching shells or downloading tools." If you find something, keep the logs and get help before you wipe anything.

How Brotherly Technology can help

Brotherly Technology can confirm your PHP version with your host, check your firewalls, storage and other devices for exposed web panels, and search your logs for the published indicators. If you're not sure where PHP runs in your office, call us today.