AI-assisted research helped establish the impact of these PHP vulnerabilities. OpenAI, one of the organisations involved, expects similar significant findings to increase sharply in the coming months. That is a forecast, but it is one engineering leaders should take seriously.
Finding weaknesses earlier is valuable. It gives defenders an opportunity to act. But the benefit depends on whether organisations can turn that knowledge into protection quickly enough.
An alert in your inbox does very little for the application nobody remembers owning.
Discovery is accelerating. Our processes need to follow.
In many organisations, responding to a critical vulnerability starts with an investigation into their own landscape.
Where do we use this component? Which versions are actually running? Is the affected system exposed to the internet? What depends on it? Who can approve and deploy the change?
Those are reasonable questions. They are also questions we should be able to answer before an emergency.
Instead, the answers are often spread across repositories, supplier contracts, old architecture diagrams, and someone who happens to be on holiday.
AI makes this gap harder to ignore. If vulnerability discovery becomes faster and more accessible, we should prepare for more findings to assess. The same capabilities can also help attackers investigate weaknesses and develop exploits, increasing the pressure on defenders.
Hiring people to manually reconstruct the same information after every alert is a difficult way to keep up.
Knowing your code is part of being able to respond
We often discuss code understanding as a developer productivity issue. Better documentation helps people onboard. Clear architecture makes changes easier.
It is also a security capability.
When you understand your code, dependencies, and running environments, you can assess an alert with greater confidence. You can identify the relevant applications, involve the right owners, and decide what to test.
Without that context, teams face an uncomfortable choice: make a change they do not fully understand, or spend valuable time investigating while exposure remains.
The PHP Foundation’s account of this incident illustrates how much engineering judgement matters. Fixing the underlying issue involved difficult compatibility and performance trade-offs. Discovering a vulnerability and safely resolving it are different kinds of work.
That distinction matters for businesses too. A patch being available does not mean it has reached every affected environment, been tested, and been verified in production.
Use AI to strengthen the response
This is part of what we are working on with Recon at SumZero.
Recon reconstructs architecture and dependencies from source code, helps teams prioritise findings, and generates pull requests for supported fixes.
The value is in reducing the work between receiving a finding and having an informed, reviewable change.
Source code provides an essential part of that picture. It needs to be connected to operational reality: what is deployed, where it runs, who owns it, and how changes reach production. A generated pull request still needs appropriate review and testing. A PHP runtime vulnerability still requires the relevant runtime update or mitigation.
Automation helps when it gives engineers better context and removes repeatable work. It needs to fit into a response process people understand and trust.
Prepare while you have time
For engineering leaders, the practical shift starts now.
Maintain an application and dependency inventory that reflects reality. Make ownership clear. Keep software supported. Build reliable testing and deployment processes. Automate repeatable remediation where you can, and verify that fixes reach the systems that need them.
This work also protects the time developers need to build new things. Every incident that begins with an archaeological expedition through your systems takes that time away.
We cannot predict every vulnerability. We can decide how much of our response depends on information we should already have.
AI will keep changing how quickly weaknesses are found. Our ability to understand and fix our systems needs to move with it.
Preferably before the next emergency meeting.