When European cybersecurity agencies tell organizations to consider taking exposed applications off public networks, the software underneath those applications suddenly becomes everyone's concern. That was the warning surrounding PHP2Shell on October 21. The agencies urged organizations to patch and consider isolation when immediate remediation was impossible. ENISA
My reaction is that we need to connect two conversations we often have separately: what AI is doing to cybersecurity, and how we pay for the open-source software our businesses depend on.
Better tools can help us discover dangerous weaknesses. Whether that translates into a safer internet depends on our ability to act on what they find.
PHP2Shell involved two critical flaws in PHP itself, the runtime beneath many web applications. Under the right conditions, an attacker could execute code without logging in. PHP shipped emergency fixes on October 21. This was serious enough to demand action even from organizations whose own application code was carefully written. PHP security announcement
There is a real AI story here. The research team describes using models in vulnerability discovery, exploit development and patch validation. That last part matters: the same capabilities that help researchers understand how to break software can help them check whether a repair works. Researchers' account
But I would be careful about turning this into a story of machines doing everything. Calif's account describes researchers drawing on earlier work, asking targeted questions and investigating different ways the failures could become exploitable. Human judgment helped direct the tools. Calif's research
The part that concerns me is the capacity on the other side of discovery.
The PHP Foundation says signs of the underlying memory problem emerged in 2024. Fixes involved hard compatibility and engineering choices, and work stalled amid decision-making problems and resource constraints. It acknowledges a “structural failure.” That is an unusually direct admission, and it deserves to be taken seriously. PHP Foundation
Finding a problem does not automatically produce a repair that millions of deployments can safely adopt. Someone has to understand the code, choose between imperfect options, review the changes and help get them into users' hands. AI can assist with that work. Organizations still need people responsible for completing it.
Consider the scale of the funding. The Foundation reported $730,534 in contributions in 2025 and 11 contracted developers working part- and full-time. Those developers supported the language broadly, beyond security. Spending exceeded donations by approximately $139,000, a deliberate decision to maintain technical staffing; the Foundation also reported healthy reserves. These are the Foundation's figures, not the entire ecosystem's budget. 2025 transparency report
My view is that companies should treat funding critical dependencies as an ordinary cost of doing business. If a business depends on software staying secure, reliable and compatible, it has a practical reason to support the people doing that work before an emergency.
An annual sponsorship will not eliminate vulnerabilities. Neither will buying another security product. But sustained funding can give maintainers time to address difficult problems, train more contributors and keep expertise from concentrating in too few people. Those are sensible investments even when there is no dramatic headline to justify them.
We should also resist using dramatic headlines as evidence. AWS reported an attempted exploit from October 17, while explicitly saying it was unclear whether the attempts it studied would succeed on real systems. By October 26, CISA had added both vulnerabilities to its known-exploited catalog. Those are different findings at different points in time. Neither tells us how many websites were compromised. AWS, CISA
The case for investing in maintenance does not need an internet-collapse narrative.
I am optimistic about AI helping defenders find weaknesses earlier. I am less comfortable with the assumption that faster discovery automatically means better security. If discoveries increase while the capacity to review, repair and deploy stays constrained, the work still accumulates somewhere.
Companies should treat funding critical dependencies as an ordinary cost of doing business.
For companies benefiting from open source, I would start with recurring funding for critical dependencies, paid engineering time for upstream work, and clear ownership of updates inside the business. For companies building security tools, I would want success measured partly by verified fixes reaching users, alongside the number of vulnerabilities found.
PHP2Shell makes the connection hard to ignore. We are investing in tools that can expose weaknesses in the software we rely on.
We should invest with the same seriousness in the people who make that software safer...
Top comments (0)