On 20 October a user posted an ominous warning on Hacker News: two vulnerabilities scoring a perfect 10 on CVSS would be coming out on 22 October. Y Combinator flagged the post at once (it was unflagged later). The post was gone, but the people who had seen it reposted it, and social media filled with rumor and speculation. A few hours later came an official statement from php.net, and a demo circulated of the vulnerabilities being exploited across a series of technologies running the affected PHP versions. What followed was a flurry: businesses (and threat actors) taking sites offline, social media hot takes, vendor advisories and leaks, proof-of-concept spam set to overdrive by LLM assistance, and more dancing anime girls.
PHP2Shell is the name given to the pair from the first PoC video demos, posted by Calif.io in the early hours of disclosure. The vulnerabilities are CVE-2026-109618 (out-of-memory corruption, uninitialized pointer) and CVE-2026-109619 (stale global state reuse). Both are critical memory bugs and a threat to anyone who has not patched. They are not especially new, either. Very similar findings came out of a code audit in 2024, and further back there is a bug report from 2019.
Patch first. Then read on
On their own, their criticality warrants immediate patching of anything running PHP above 5.4.0 and below the fixed versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Whatever else this article says, update those PHP versions and whatever sits on them, whether that is WordPress, Joomla, Magento or anything else running a version before the fix. Our plain-language guide covers which versions are affected and what to ask your team. Now, with that out of the way.
How bad is it, really?
Aside from the tiresome *2Shell naming convention that every major critical bug with a PoC gets these days, how bad is it? In a vacuum, pretty bad. That is a given. But from a series of lab tests, corroborated by other reputable researchers posting their results, PHP2Shell is difficult to exploit outright. Even the more technical threat actors on dark web forums agree with that assessment, going by a Flare report shared on its Discord server.
The main problem with the currently available PoCs that do somewhat work (the 9bie one, if you know you know) is that they need certain configuration details of the running PHP deployment, such as the memory offset, to trigger the bug properly. Without them, the service crashes and the RCE never fires. That is largely what we saw in our own testing against stock WordPress and Apache containers, using the labs shipped inside the PoC as a control. Add ASLR (address space layout randomization) to the process and exploitation gets harder still. The result was multiple requests against each vulnerable lab target, brute-forcing additional offsets to trigger the RCE, which makes PHP2Shell far from stealthy, at least with today’s PoCs. A universal one-size-fits-all PoC is unlikely. Several configuration conditions also need to be in place, such as memory limits set in the PHP configuration files and, potentially, host OS memory offsets that line up for ideal RCE conditions. Even the video demo making the rounds, dancing anime girls and all, shows several operating systems and specific profile options, which suggests the same limits apply there and that offsets were set for each lab instance.
What exploitation looks like so far
We saw attempts in our own honeypots during disclosure. Social media users reported exploitation attempts as early as the night of Tuesday 20 October, when the first PoCs appeared, and there have been countless attempts since using the known PoCs that several vendors have now written up. To our knowledge, exploitation detail is limited. Dream has stated the vulnerability chain was used to compromise about 25 servers, but none of that information can be attributed or verified.
For all we know, exploitation may change drastically and become far easier, and if this grows into something worse we can admit we were wrong. But right now this is not Log4j and it is not EternalBlue. We wonder whether this pair would have had the same attention if disclosure had not leaked early and patching had gone to plan. Combine that with “found by AI” and “seen in the wild”, a phrase that may by now have become meaningless.
The cottage industry
Searching GitHub for php2shell turns up over 800 repositories posted in the week of disclosure. Companies with AI products have benefited enormously from the PR cycle around it, while the open-source maintainers of PHP and the defenders in the trenches were left holding the bag. None of this is an argument against patching (apply the patches immediately), nor does it question whether these vulnerabilities are legitimate. They are real and organizations need to take them seriously. But they should be seen in the context of how they are actually exploited, with the information available.
There is unlikely to be a universal exploit in the short term. If you run stock container images or anything without ASLR, you are more at risk (looking at you, Palo Alto). Apply patches and mitigations as they become available, and treat this as a rehearsal for when the next EternalBlue does drop.
One last concern. Many sites were taken down out of panic. How much revenue did that cost, and what did the downtime add up to? If the security industry behaves this way every time, it risks losing credibility with the people who sign off on it, and we all know what happened to the boy who cried wolf.
Know where you’re exposed before the next one drops
Patching where you know you run PHP is the easy part. Knowing what you have, what is exposed, and whether a flaw is actually exploitable against your systems is the hard part. Incenter tests your attack surface continuously, the way an attacker would. Talk to a senior about your exposure.