The PHP2Shell vulnerability has set off a burst of attack traffic and a wave of precautionary shutdowns, but so far no government agency says it has seen a confirmed break-in. Cloudflare CEO Matthew Prince said on X that attackers have made millions of exploit attempts since Wednesday’s disclosure. Officials in Germany, the Netherlands and Japan say none of those attempts has succeeded, as first reported by The Next Web.
That gap between noise and damage is the real story for now. It’s also a narrow window, and anyone responsible for the PHP2Shell vulnerability in their own systems shouldn’t treat it as a reason to relax.
Key Takeaways
- Since the disclosure of the PHP2Shell vulnerability, attackers have made millions of exploit attempts, yet no confirmed breaches have occurred.
- Cloudflare noted a rapid escalation of attack attempts before most organizations had a chance to patch their systems.
- Officials from Germany, the Netherlands, and Japan reported no successful exploitation of the PHP2Shell vulnerability, though attempts have been high.
- Several large organizations, particularly in Japan, have taken precautionary measures offline to address the threat posed by the PHP2Shell vulnerability.
- Technology leaders should prioritize patch management for PHP, monitor for confirmed compromises, and watch for developments related to the coordinated disclosure process.
Table of contents
How fast PHP2Shell vulnerability attempts escalated
Prince shared Cloudflare’s numbers early Thursday. In the ten hours before the public announcement, its network recorded thousands of attempts to exploit the flaws. Within 45 minutes of the announcement that rose to tens of thousands, then to hundreds of thousands inside two hours, and then to millions.
The curve matters because it shows attackers were active before most defenders had any chance to patch. Scanning at that scale doesn’t prove anyone got in. It does show how quickly a named, publicized flaw like the PHP2Shell vulnerability becomes a target for automated probing.
Officials see no successful PHP2Shell vulnerability attacks
Germany’s cyber agency, the BSI, has observed attacks but no successful use of the PHP2Shell vulnerability, according to vice-president Thomas Caspers. He said exploitation looks harder than the agency expected. Before the patch was released, planners had anticipated attackers moving much faster.
The head of the Dutch cyber agency, Matthijs van Amelsfort, said his office had no sign of active misuse of the PHP2Shell vulnerability. In its Wednesday alert, the US agency CISA said it had not seen exploitation at that point. Ryan Austin, the Calif researcher who helped find the flaws, said exploitation didn’t appear to have taken off or spread widely.
Not everyone is as calm. Elizabeth Barron, executive director of the PHP Foundation, said on Wednesday that she had seen no working exploits. But Matt Suiche, a researcher at the security startup Tolmo, said his team built one in under a day. That suggests the barrier is real but low enough for skilled teams to clear quickly.
Banks, airlines and carriers pull services
The practical fallout has been uneven and, in Japan, fairly dramatic. Prime Minister Sanae Takaichi urged site owners on X to apply the fix the moment it was available, calling on everyone to act that night.
Several large Japanese organizations then took systems offline:
- Mizuho’s bank and securities arms halted services on Thursday.
- Shizuoka Bank suspended its website and app.
- Companies in the MUFG group stopped some online services.
- All Nippon Airways disabled boarding passes in Apple Wallet, saying it had found no evidence of a breach.
- Japan Airlines, East Japan Railway and Seven-Eleven Japan took some web services down.
Chief Cabinet Secretary Minoru Kihara said no attacks exploiting the flaws had been confirmed. Elsewhere, Orange in France suspended access to some websites and apps while it deployed patches. A British government spokesperson said officials were checking for exposure in the state’s own online services, and South Korea raised its cyber alert level for the private sector.
Taken together, these look like cautious, patch-first decisions rather than responses to confirmed intrusions. Pulling a service offline is expensive, so the choice shows how seriously large operators are taking the PHP2Shell vulnerability.
PHP2Shell vulnerability probing began before the patch
The timeline is the most uncomfortable part. Amazon said someone tried to exploit PHP2Shell on 17 October, four days before disclosure. The attempt hit its decoy servers from an anonymized address. Amazon’s chief information security officer, CJ Moses, said it was unclear how the attacker obtained exploit details while the flaws were still under embargo.
Amazon also logged more attempts from several actors in the hours before the 14:00 UTC release. Moses described the PHP2Shell vulnerability as being broadly exploited in the wild. He added that analysis was ongoing and that it wasn’t yet clear whether any attempt would have worked against real systems. Amazon provided no details about victims.
OpenAI, which led the coalition behind the emergency patches, had said that, to its knowledge, AI found the flaws before attackers did. How early exploit details reached someone else remains an open question.
A dispute over the embargo
The disclosure process itself is now contested. The PHP Foundation says Chainguard broke the embargo by publishing patched images more than six hours before the planned release. Chainguard CEO Dan Lorenc denies leaking anything. He told The Register that his company shipped the fixes because customers were already being hit, and that it wouldn’t act differently next time. In his view, coordinated disclosure no longer applies once there’s evidence of active exploitation.
Both positions have a logic. Embargoes exist so maintainers can prepare fixes before attackers get a roadmap. But if attacks are already underway, as Amazon’s decoy data suggests, waiting leaves customers exposed. The argument will likely shape how future coordinated disclosures handle early signs of exploitation.
Read next
A few related pieces worth your time:
- How Can Iris Recognition Development Be Enhanced?
- msvcp120.dll Missing? Don’t Download It from “DLL Sites” – Do This Instead
- Best 5 Distroless Image Alternatives for Near-Zero CVEs and Convenience
What technology leaders should watch
The immediate task is unglamorous. Treat the PHP2Shell vulnerability as a patch-management job: find where PHP runs in your environment, including third-party services and container images, and confirm the emergency patches are applied. Companies that pulled services offline will want a clear path to restore them once patching is verified.
Then watch three things. First, whether any agency or vendor confirms a successful compromise, which would change the tone fast. Second, whether Amazon’s analysis shows its observed attempts could have worked on live systems. Third, whether the embargo dispute leads to new rules for how patched software is released.
For now, the evidence points to heavy probing and heavy caution, not confirmed damage. Given that a researcher built a working exploit in under a day, that could change quickly, which is why the PHP2Shell vulnerability deserves attention from patch teams before it earns a verdict from the headlines.
Source: The Next Web
