When AI Finds a Flaw, Who’s Responsible for Fixing It Before Someone Exploits It?

AI finding a software vulnerability sounds like good news. Until the details escape, attackers start testing the flaw, and the people running the vulnerable systems discover they have to patch them, fast.

AI is finding flaws in the code that runs the web. Who installs the fix is the harder question. Photograph via Unsplash.

That’s the uncomfortable lesson of October’s disclosures. AI-assisted researchers helped uncover serious weaknesses in PHP, a programming language used across a huge share of the web. Researchers also reported exploit chains in major browsers and operating systems, while an autonomous security agent found severe flaws in software used in industrial control systems.

The technology may accelerate discovery. It does not, by itself, fix a line of code, notify every exposed organization or install an update on a neglected server. So who owns the job?

The short answer: responsibility is shared, but it isn’t interchangeable. AI labs and security researchers must handle findings carefully. Software maintainers and vendors must develop and ship fixes. Organizations must know what they run and deploy those fixes. Coordination bodies such as CISA can warn and guide, but they cannot patch every system on the internet.

That is a lot of handoffs. And handoffs are where urgency can turn into exposure.

PHP2SHELL: a defender’s head start, or a map for attackers?

On October 21, PHP maintainers released fixes for critical vulnerabilities in the language’s core engine. The flaws could expose process memory or enable remote code execution on affected systems. PHP underpins platforms such as WordPress, Drupal and Joomla, and NPR reported that it runs on roughly 70% of websites.

The discovery was a collaborative effort, not a case of one AI company single-handedly finding and fixing the web’s problem. Wiz Research’s technical account describes using AI tools to identify and validate PHP vulnerabilities, while OpenAI’s Patch the Planet announcement describes its role in coordinated vulnerability research and response. PHP maintainers produced the fixes; hosting and security providers helped prepare protections and guidance.

That collaboration matters. A foundational vulnerability may touch millions of independently managed sites, and the maintainers of widely used open-source software do not necessarily have the staffing or budgets of a major technology vendor. In this case, industry partners helped prepare mitigations for organizations that could not update immediately. Still, that support doesn’t remove the work of identifying every affected installation and applying the right fix.

The more troubling part is the race that followed. NPR’s October 24 report described how details about PHP2SHELL leaked while the patching effort was underway, and attackers moved to exploit the flaw. Cloudflare also reported exploitation attempts. This doesn’t mean that responsible disclosure caused the attacks. It does show that a disclosure process can be overtaken by events.

Researchers face a real dilemma. Share too little, and defenders may not understand the risk or know how to prioritize it. Share exploit details too early, and attackers may get a practical guide before organizations have time to update. Coordinated disclosure is intended to give maintainers a private window to prepare a fix, then give users useful information. But no schedule can guarantee that details stay private, or that everyone applies the patch on time.

A fix being available is not the same as a fix being deployed.

Server infrastructure is only protected when its operators know what is running and act on the available fixes.

The flaw is only the start of the response

The October cases point to different versions of the same operational problem.

On October 27, Anthropic described an internal model finding multi-step attack chains in widely used software, including Chrome and other major products. The company said it reported findings to vendors under coordinated disclosure timelines. It also reported that Google had assigned and patched 62 CVEs by Chrome 156. That is an example of a vendor with substantial engineering resources responding to a stream of findings. It still leaves users and IT teams with the job of installing updates across fleets of browsers and operating systems.

The same day, CISA published an advisory for four severe vulnerabilities in EPICS Base, software used in industrial control environments. The agency said versions 7.0.10 and earlier were affected and advised users to update to version 7.0.11. CISA’s advisory warns of possible denial of service, memory corruption, information disclosure or potentially arbitrary code execution. Its recommendations include reducing network exposure and isolating control-system networks.

These systems are not all alike. Updating a browser is a routine task for many organizations. Updating software in an industrial environment may require testing, vendor coordination and careful planning to avoid disrupting operations. But “we need time to test” is not a remediation plan on its own. It has to come with a clear view of exposure, interim protections and an owner responsible for the next decision.

The people who find the flaw don’t necessarily have the resources or authority to fix every affected deployment. Open-source maintainers may have to build a release and communicate with downstream vendors. Commercial vendors may need to update supported products. Cloud providers can sometimes add protective measures at their edge. CISA can publish guidance. The operator still has to know whether the system exists, whether it is vulnerable and whether the fix actually reached it.

For more on why AI-assisted discovery deserves scrutiny beyond the headline, see our coverage of AI agents and cybersecurity and AI’s expanding footprint on the web.

Who is accountable?

It’s tempting to ask whether an AI lab is responsible because its model helped find a flaw. But that skips the harder questions: Who confirmed the finding? Who controlled its release? Who had the ability to fix the vulnerable software? Who operated the exposed system? And who had a duty to tell customers what to do?

A better way to assign responsibility is to follow control:

• AI labs and researchers control how they test, verify, report and disclose findings. They should coordinate with maintainers, avoid releasing operational details before defenders have a fair chance to respond, and be candid about what their models did, and did not, demonstrate.
• Software maintainers and vendors control the code and release process. They need a way to receive reports, prioritize serious issues, produce fixes and communicate clearly with downstream users. This can be a heavy burden for underfunded open-source teams, which is one reason the software ecosystem needs more support for maintenance and security.
• Organizations and service providers control their own environments. They need an accurate inventory, a process to evaluate advisories and the ability to apply patches or put documented mitigations in place.
• CISA and other coordinators can raise the alarm and provide guidance. They cannot make an organization’s asset inventory accurate or install an update on its behalf.

Accountability does not mean blaming whoever touched the issue last. It means each party owning the work it can actually control, and being transparent when the next handoff is delayed.

What IT and security teams should do now

AI-assisted findings should be treated as a faster, less predictable vulnerability-reporting pipeline, not as a reason to assume every new alert is an emergency, and not as a reason to dismiss the next one as hype.

Start with the basics:

1. Inventory exposure. Know which public-facing systems, runtimes, libraries and operational technology assets you use, including older versions and third-party-managed services.
2. Prioritize by exposure and impact. A critical flaw in an internet-facing service needs a different response from a similar flaw in an isolated, carefully monitored environment. Consider the vendor’s advisory, available evidence of exploitation and the consequences of compromise.
3. Track the patch to completion. A ticket marked “patch available” is not closed. Verify installed versions, record exceptions and set a deadline for any system that cannot yet be updated.
4. Use interim protections carefully. Provider-level mitigations, network restrictions and monitoring can buy time. They are not substitutes for the vendor’s fix unless the advisory says otherwise.
5. Plan for a firehose. Define who validates urgent reports, who approves emergency changes and how you will communicate with system owners when several advisories land at once.

AI can shorten the time between an overlooked weakness and a reproducible exploit. That raises the value of good patch operations, but it doesn’t make patching automatic. The organization that has a complete inventory, a clear escalation path and a practiced update process is better positioned to use the defenders’ head start.

The skeptical question is not whether AI can find flaws. October has offered compelling examples that it can help. The question is whether the entire chain, from discovery to safe disclosure to installed patch, can move faster than exploitation.

For more practical, skeptical technology coverage, visit the TechTime Radio blog or explore our latest episodes.