PHP2Shell: The Defenders Won This One. Here's Why That Matters.
By Jay Martin, CISO, Blue Mantis
PHP2Shell is worth paying attention to, not only because of the vulnerability itself, but because of how it was discovered.
First, the facts. PHP2Shell is the name given to two critical vulnerabilities in PHP, CVE-2026-109618 and CVE-2026-109619. Both carry a CVSS v4.0 score of 9.2, and both allow an unauthenticated attacker to execute code on a vulnerable web server. The flaws are in the PHP engine itself, not in any particular application, which means WordPress, Drupal, Magento, Laravel and a long list of other platforms are exposed even when their own code is clean. PHP released emergency fixes on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and has been clear that updating is the only safe answer. Older branches that are out of support have no official fix.
The timeline matters too. Details leaked a day before the patch was ready. Amazon’s honeypot network recorded an exploitation attempt on October 17, four days before public disclosure. Cloudflare saw early attacks the morning of the release. If you run anything on PHP and haven’t patched, you’re already behind.
But here’s the part that caught my attention.
AI helped find it
Researchers at Calif found the vulnerabilities in early August using AI models as part of OpenAI’s Patch the Planet initiative, and reported them to PHP on August 11. Wiz Research independently found and reported them two weeks later, also with AI-assisted tooling. These were bugs buried deep in software that has been scrutinized by security researchers for decades.
Then AI helped on the defensive side too. But there’s an important distinction I don’t want to lose.
OpenAI’s program pairs its models with security engineers who validate every finding, help develop and test patches, and coordinate disclosure. A human reviews everything before it reaches a maintainer. And for PHP2Shell specifically, the PHP maintainers wrote and released the fixes themselves. AI accelerated the work. It didn’t replace the people doing it.
Both sides of the clock are compressing
We’ve been talking for a while about AI making attackers faster. I wrote about it last week. What we’re watching now is AI compressing the entire cybersecurity lifecycle at once: discovering vulnerabilities, proving they’re exploitable, assisting defenders with remediation, and shortening the time between discovery and action.
That’s exciting. It’s also a little sobering.
In this case the discovery-to-patch window was about ten weeks, which is normal for coordinated disclosure. The window between leak and exploitation was about a day. That second number is the one that should shape how you think about your own environment, because the next one of these won’t be found by the good guys first every time.
How PHP2Shell affects your environment
This one is broader than most organizations assume, for three reasons.
First, it’s the engine, not the app. If PHP is processing the request, the flaw is reachable before any application code runs. Login pages, web application firewalls at the application layer, and clean custom code don’t help. Both Apache mod_php and PHP-FPM are affected.
Second, PHP is everywhere you stopped looking. The corporate WordPress site is the obvious one. Less obvious: the intranet wiki, the ticketing tool someone installed in 2019, the vendor appliance with a PHP admin panel, the Laravel app a contractor built, and the Magento store that sits with a different team. Any of them is an entry point to whatever network they live on.
Third, the fix isn’t uniform. PHP 8.2 through 8.5 have patched releases. PHP 7.4, 8.0 and 8.1 are end of life and have no official fix, which means a vendor backport or an upgrade. If you host with a managed provider, confirm they’ve applied it rather than assuming.
And one more thing. CVE-2026-109618 can leak server memory on its own, so even a server that wasn’t fully exploited may have exposed session data or credentials.
What to do next
- Inventory every PHP instance. Internal and external, owned and inherited. If you can’t produce this list today, start with an external attack surface scan, which will find the internet-facing ones in days.
- Patch to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. For anything on 7.4, 8.0 or 8.1, get a distribution backport now and schedule the upgrade.
- Apply interim mitigations where you can’t patch today. Setting memory_limit to -1 at the admin level and disabling session.upload_progress blocks the demonstrated attack paths. These are stopgaps, not fixes.
- Check for compromise, not just exposure. Exploitation attempts were observed from October 17. Review web server logs for anomalous requests, unexpected processes and new files in web roots from that date forward.
- Rotate what might have leaked. Session secrets and any credentials that lived in PHP worker memory on exposed servers.
- Confirm someone is watching going forward. Patching closes the door. It doesn’t tell you whether someone came through it, and the next one of these won’t give you a week’s notice.
That last item is where most mid-market organizations are thin, and it’s the gap Mantis Protect was built to close: AI-driven threat detection with human analysts behind it, which is the same AI-informed, human-led model that got PHP2Shell patched in the first place.
The question isn’t whether AI will become part of cybersecurity. It already has. The advantage goes to whoever combines AI, good governance and experienced security professionals the fastest. And, in this particular case, I’m glad the defenders got there first.
If you’re not certain every PHP instance in your environment is patched and clean, talk to our team. An external attack surface scan takes days, and it’s the fastest way to find the PHP you forgot you had.
