The PHP2Shell disclosure was a carefully and quietly coordinated effort that took great pains to leave time for patching before public disclosure, given the absolutely massive “blast radius” the included PHP vulnerabilities could have. A botched leak of materials a day early caused a general panic, but Amazon’s Threat Intelligence group is now revealing that they detected threat actors probing the vulnerabilities as early as October 17; three days before the leak and four days before public disclosure.
Someone had critical PHP vulnerabilities early
The Amazon Threat Intelligence report is separate from the October 20 leak, which set off a firestorm of hasty defensive maneuvering. The PHP Foundation, which was centrally coordinating the disclosure and rollout, was forced to release patches for CVE-2026-109618 and CVE-2026-109619 a day early after someone leaked the pre-release disclosure notices and videos to the Hacker News comments section. The leak also prompted a public warning from numerous world government intelligence agencies, and an assortment of governments also took certain public-facing government portals offline for some time as they were patched as a precaution.
Amazon now says there are likely at least several threat actors that seemed to be aware of the PHP vulnerabilities several days before the leak, as it caught multiple attempts at one of its “MadPot” honeypots coming from known anonymization services. Amazon believes that multiple actors were trying to exploit the vulnerabilities based on a variety of payload types originating from different sources of anonymization infrastructure.
It remains unclear exactly how this happened. The two leading possibilities are that there was a more quiet insider leak to threat actors well ahead of the public Hacker News leak, or that some advanced threat actors independently happened to hit upon the PHP vulnerabilities a little in advance of the patch release. The Hacker News leak is thought to be a case of an employee from a security company that had insider access making an honest mistake with the embargo timeline rather than a malicious effort.
Legacy web servers remain vulnerable despite massive patch effort
These particular PHP vulnerabilities inspired such heroic patching efforts (and panic) because of the widespread damage they could potentially cause. The PHP2Shell flaws threaten the core PHP runtime engine and thus about 70% of the internet. It was thus crucial to have an extended embargo period and a well-coordinated patching effort prior to disclosure with full buy-in from all participants.
Every PHP installation dating back to 2012’s PHP 5.4 is potentially vulnerable to what is essentially just a malicious HTTP request that takes relatively little skill or knowledge to pull off. The patches also do not universally negate the PHP vulnerabilities. The currently available patches are for the currently active PHP versions 8.2 through 8.5, but there are millions of legacy servers out there running older and no longer supported versions that remain without an official patch option.
As the Amazon Threat Intelligence group notes, in the age of frontier AI it is no longer safe to assume that attacks will not roll in until a public disclosure of a proof of concept is released. Nor will the early days only be the domain of a small group of the most capable threat actors, with wider adoption coming in the following months. The researchers note that millions of attacks were observed almost immediately after the PHP2Shell proof of concept became available. This is almost certainly due to AI assistance, making it possible for all levels of attacker to ready themselves to exploit a vulnerability within a matter of hours (and the most capable likely within minutes).
The researchers also caution that this means detection methods that rely on a signature for a specific CVE are effectively outmoded. As this specific incident indicates, the vulnerability could be in circulation for days (or longer) prior to an official coordinated disclosure being ready to launch. Even if there is not a leak, it has to be assumed that AI tools will create a fair chance of some threat actor independently hitting upon the vulnerability prior to disclosure.
With regards to these specific PHP vulnerabilities, the researchers advise that updating to at least PHP 8.2 is the only complete remediation method available. There is no configuration-only workaround that will completely protect older versions against both of the exploits. Legacy servers that cannot do this may consider blocking multi-part file uploads in their PHP deployments as a form of partial protection, though this method may cause other problems. Monitoring and log review should also focus on POST requests with the “PHP_SESSION_UPLOAD_PROGRESS” string in form uploads as well as unexpected process execution or file modification on web application servers.
Justin Beals, CEO & Founder of Strike Graph, adds: “The end-of-life count should stop people. VulnCheck sees at least 1 million internet-facing hosts running PHP versions that no longer get updates, so a lot of these servers will never receive an upstream fix. Somebody decided to keep each of those systems running, and most compliance programs never forced that decision into the open. A typical control says the asset inventory gets updated at least annually and vulnerability scans run quarterly. That cadence passes an audit and tells you nothing during a week like this one.”
“Security teams need to know today where PHP runs, which versions, and who owns each system,” Beals added. “Anything end-of-life belongs on a risk register with a named owner and a retirement date. I expect the long tail of PHP2Shell to come from forgotten servers sitting on vendor and partner infrastructure, which is exactly where third-party programs built on annual questionnaires will miss it.”
