PHP2Shell Is Now Exploited in the Wild: Working Shells, a New Unpatched Flaw and Over 5 Million Exposed Servers
On 26 October two security outlets reported that the PHP2Shell flaws are now being used successfully against real servers, and a new unpatched PHP flaw has surfaced. If you haven't updated yet, what should you do today? We separate what is confirmed from what remains uncertain.
In brief: The situation changed for the PHP2Shell flaws (CVE-2026-109618 and CVE-2026-109619) patched on 21 October. On 26 October 2026 both SecurityWeek and BleepingComputer, citing honeypot data from Adel Karimi, detection and response lead at Perplexity, reported that the flaws are now being used against servers with working shells. Karimi's sensors logged 35 shells across three honeypots on 24 October; the attack was a four-stage chain of HTTP requests (memory exhaustion, memory disclosure, then a shell command) that closely matched a public proof-of-concept exploit. Karimi and Expel's Marcus Hutchins were careful with the result: the test was on a single-worker Apache mod_php profile and does not show reliability on other configurations. BleepingComputer also reported a new unpatched RCE flaw, CVE-2026-115560, exploitable only on a specific mix of configuration and application code; until a fix ships PHP recommends
session.upload_progress.enabled=0. By VirusTotal estimates over 5.1 million PHP hosts are exposed online. Sources: SecurityWeek and BleepingComputer (as of 26 October 2026).
Last updated: 26 October 2026
A follow-up to the first article
In our PHP2Shell article we explained the flaws, the affected versions and the first steps. At that time there were exploitation attempts but no confirmed successful code execution. Today's development ends the comfort of “nobody is using it successfully yet.”
What is now clear
| Topic | Information |
|---|---|
| Evidence of real exploitation | Karimi reported confirmed remote code execution on a honeypot running Apache mod_php + PHP 8.4.26. The response contained an 800 KiB decoded cookie dump, and a function address derived from that dump appeared in a later payload |
| Honeypot data (24 October) | 35 shells across three honeypots; one IP launched 3 shells, another launched 32 across all three |
| Attack chain | Four-stage HTTP requests: memory exhaustion, memory disclosure, shell command. Traffic closely matches a public PoC |
| Second-stage payload | No second-stage download was observed |
| Expert comment | Marcus Hutchins (Expel) called it the highest-quality confirmation of in-the-wild PHP2Shell exploitation he had seen |
| CISA | On 23 October updated its alert with a Sigma detection rule; said it had not observed successful exploitation. As of the morning of 26 October the flaws were not in the KEV (Known Exploited Vulnerabilities) catalog |
| Patch | PHP released patches on 21 October |
| Exposure | PHP runs about 70% of websites; by VirusTotal estimates over 5.1 million PHP hosts are exposed online, about 3.8 million with at least one port open to attack |
What remains uncertain
- Reliability: Karimi stressed that the result came from a single-worker mod_php profile and does not show reliability on other configurations (e.g. PHP-FPM). So we can't conclude “every server falls equally easily,” but we can't say it's safe either.
- Wider compromise: A successful compromise outside honeypots was not confirmed in the SecurityWeek and BleepingComputer reports.
- Claims from other sources: Some sources say Mirai botnet operators have joined the attacks and that Cloudflare has seen millions of attempts. I could not verify these from a primary source; in the SecurityWeek piece they appear only as a related-link title or a cited figure.
The new unpatched flaw: CVE-2026-115560
According to BleepingComputer there is a new RCE flaw with no fix yet. It is exploitable only under a specific mix of configuration and application code. Until a fix, PHP recommends:
session.upload_progress.enabled = 0
PHP.net's 21 October announcement had listed the same setting as an interim measure for PHP2Shell (noting it does not make a system safe). For the new flaw, follow the official announcement and the php.net security page; I have not yet verified the details.
What to do today: 8 steps
- Apply the patch: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your provider's patched package). If you haven't yet, this is a today job, not a “this week” job.
- Verify the version: Record the output of
php -v; check all PHP installations including containers and staging. - Prioritise mod_php: Verification of exploitation was reported on mod_php; moving to PHP-FPM may be a long-term improvement (plan it with your system administrator).
- Apply the interim setting (can be considered alongside the patch):
session.upload_progress.enabled = 0. PHP recommends it for the new unpatched flaw. Test whether it affects application features (it does if you use an upload progress bar). - Review the logs: Unusual multipart requests, memory-limit errors, repeated HTTP 500, large/malformed
PHPSESSIDcookies, unexplained worker restarts. Your security team can use the Sigma rule CISA published. - Plan to rotate secrets: Leaking passwords, tokens and keys from process memory was reported as a possibility. Especially on internet-facing servers that ran unpatched, consider rotating
.env, database, API and SMTP secrets. - Don't rely on a WAF: WAF rules are extra protection, not a fix.
- Plan for unsupported versions: PHP 8.1 and older get no official patches; PHP 8.2's support ends on 31 December 2026.
For the detailed checklist and “how do you know whether you're affected,” see our first article. To build an urgent patch routine, see our patch management article.
A plain message for business owners
- The price of delay is now concrete: Working shells were seen five days after the flaw was announced. Patch delay is a real risk, not an abstract one.
- Ask your hosting company for written confirmation: “Have you applied the PHP2Shell patch, which version are we on and what are you doing about the new CVE-2026-115560?”
- Priority, not panic: First internet-facing systems that run PHP and hold sensitive data.
Maintenance and security with Aktaş Digital
In web applications, version inventory, urgent patch tracking and post-upgrade testing are part of the maintenance plan. To have your site's security status assessed, use our quote form. Related services: web applications.
Frequently Asked Questions
Is PHP2Shell really being exploited?
SecurityWeek and BleepingComputer reported working shells based on honeypot data from Adel Karimi of Perplexity. A broad successful compromise outside honeypots was not confirmed in those reports.
I patched; is there still a risk?
On patched servers these flaws are closed. But if the system was exploited before patching, secrets may be affected; also consider the interim setting for the new CVE-2026-115560.
Does CVE-2026-115560 apply to me?
According to BleepingComputer it can be exploited only under a particular mix of configuration and application code. I could not verify the details of that mix; ask your software team to check the official announcement.
I use PHP-FPM; am I safer?
The honeypot result was obtained on mod_php, and researchers noted reliability on other configurations such as PHP-FPM was not shown. So don't assume you're safe; apply the patch.
Should all my PHP sites be taken offline?
No. Patched versions are fine. If you can't patch and the site is high-risk, temporarily switching to maintenance mode is a reasonable precaution.
Conclusion
PHP2Shell has stopped being “theoretical:” working shells were observed and a new unpatched flaw is on the agenda. If your site runs PHP, the most important job today is moving to a patched version and confirming it in writing. First step: list the version of every PHP installation and put the unpatched ones in priority order.
