AI Made Finding Vulnerabilities Cheaper. It Did Not Make Patching Automatic

AI vulnerability discovery helped put a critical PHP fix on everyone's desk this week, and in most companies the first hard question was not technical. It was "which of our sites actually run the affected version, and who is allowed to change them tonight?" For many teams, answering it can take days. That delay is the exposure: data, uptime and, a few weeks later, the board or the insurer asking "were we patched, and when?"

AI vulnerability discovery has made finding serious flaws faster and cheaper, for defenders and attackers alike. It has not made patch management automatic. The time a company needs to find where the software runs, update it, restart it and prove the fix is live is now the part that decides the risk. That is where leaders should spend their attention.

This is our point of view, from a team that patches its own production servers and helps clients modernize theirs. This article looks at what PHP2Shell showed about AI vulnerability discovery, why the slow part of patch management is still human, a patch cadence that holds up when the window is short, and what to do about legacy systems that cannot be patched at all.

What PHP2Shell Showed About AI Vulnerability Discovery

The vulnerable code had been in PHP for more than a decade, according to Wiz's PHP2Shell research. What changed was not the bug. It was the cost of understanding it. Wiz says that with frontier AI models and the right tools, a single researcher completed in a week what previously would have taken a world-class team months of work. The underlying out-of-memory flaw had been found in 2020 and again in a 2024 audit, but it was not patched because nobody had proven it exploitable. With AI help, Calif and OpenAI independently reported the remote code execution path to PHP on August 11. Wiz's own timeline shows it found its first issue on August 19 and reported to the PHP security team on August 24, and it thanks the PHP team, Calif and OpenAI for discovery, coordination and patch verification. These were human researchers using frontier AI models as tools, through a coordinated disclosure with the PHP team. AI vulnerability discovery did not find PHP2Shell on its own, and no single company found it.

The PHP Foundation sees the same rise in AI-found vulnerabilities. SecurityWeek's report on the PHP2Shell patches reports the PHP Foundation as saying AI has helped surface more PHP vulnerabilities than before, with 15 new CVEs published since July 1. The same report shows how short the defenders' window was. Details leaked online on October 20, so the patches shipped a day earlier than planned; Amazon saw exploitation attempts four days before the patches were released, and several other firms reported attempts in the hours before and as the patches landed.

PHP2Shell is not the first sign. In 2024, Google's Big Sleep agent found an exploitable bug in SQLite, which the team described as the first public example of an AI agent finding a previously unknown exploitable memory-safety issue in widely used real-world software. DARPA's AI Cyber Challenge, launched in 2023, asked teams to design AI systems that secure critical code. The direction is clear: AI vulnerability discovery keeps getting cheaper, AI-found vulnerabilities keep arriving, and the same tools are open to attackers. For vulnerability management, that means more fixes to ship, more often.

The Part AI Did Not Speed Up

NIST SP 800-40 defines patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades across an organization. AI vulnerability discovery speeds up the work before that list starts. It does not do the patch management list for you. CISA's PHP alert began its actions with "identify and inventory systems running any version of PHP across your organization", and SimSpace CTO Lee Rossey, quoted by SecurityWeek, said teams should already know where PHP runs, who can authorize urgent changes and how they will confirm the update worked, and should check whether attackers got in before the fix. In our experience, most delays live in those questions, not in the update itself.

Our own server is a good example of why AI vulnerability discovery alone does not close the gap. When we patched it for PHP2Shell the day after the fix shipped, installing the update was the easy part. The command line reported one PHP version while the main website ran on another, and some sites still ran older PHP branches. The real work was finding what actually served each site. The older branches got distribution backports that fix both PHP2Shell flaws, every PHP service was restarted the same day, and upgrades off those branches are now planned. We also took sites nobody used offline instead of patching them, which removed risk faster than any update.

The lesson for leaders: "the patch is installed" and "the fix is live and proven" are two different statements. Teams often report the first one when the board is asking for the second. A good patch cadence closes that gap on purpose, and it is the part of vulnerability management that AI vulnerability discovery cannot do for you.

A Patch Cadence for a Shorter Window

Public guidance now says the window is shrinking. The Five Eyes cyber agency leaders, in a statement published by the NCSC, say AI is shortening the time between vulnerability discovery and exploitation, and they ask leaders to accelerate patching processes. CISA's BOD 26-04, issued in June, notes that attackers' use of AI may further narrow the time defenders have between patch release and exploitation. A patch cadence that holds up under that pressure is less about tools and more about five habits. None of them needs new software; all of them need an owner.

• Keep a live inventory. Know every runtime, which version serves each site and who owns it. BOD 26-04 requires federal agencies to continuously identify and tag every asset reachable from the internet; a smaller company can keep the same record in a simple register updated by the release process.
• Prioritize known exploited vulnerabilities and exposed systems. BOD 26-04 sets federal deadlines by whether the asset is publicly exposed, whether the flaw is in the Known Exploited Vulnerabilities catalog, whether exploitation can be automated and how much control an attacker gains. For the most urgent cases it requires action within three days plus a forensic check for compromise. CISA's KEV guidance strongly encourages all organizations to apply updates for catalogued flaws. For this week's queue, see what to patch first this week.
• Name who approves an emergency change, and a backup. A simple update can sit overnight because the only approver is on a plane.
• Make restart, redeploy and proof part of "done". An updated package on disk does not protect a process that has not restarted. Keep the evidence: the version the live site reports, with a timestamp.
• Shrink the attack surface. BOD 26-04 counts decommissioning a system as remediation, and taking a system off the internet as a valid mitigation. The Five Eyes leaders make the same point: reduce your attack surface and challenge whether systems need to be exposed at all.

The Systems You Cannot Patch

The hardest cases have no patch to schedule. End-of-life software, such as an old PHP branch, an old framework or an old CMS version, gets no normal security fix, however fast AI vulnerability discovery finds the flaw. For PHP2Shell, CISA said organizations that cannot update immediately, or that still use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated. The Five Eyes leaders put it bluntly: unsupported systems are easy targets, and they are not just technical debt but strategic liabilities. Legacy systems are where a fast patch cadence helps least, because there is often nothing supported to apply. For PHP2Shell, PHP also published minimal source backports for PHP 7.4, 8.0 and 8.1.

That does not mean a rebuild is the first step. For an actively exploited flaw such as PHP2Shell, restricting access is not enough: follow CISA and take the system offline until it is patched or upgraded, because the PHP Foundation says interim measures reduce exposure but do not make an installation safe. Outside an emergency, improve what you have first: apply any distribution or vendor backport that exists, restrict who and what can reach the system, and write down the risk you are accepting. Then plan a way off the old version and modernize one release at a time. Upgrade the runtime, prove it in production, then move to the framework or CMS, instead of a big-bang rewrite that takes a year to ship. This is the work our AI-assisted development and modernization service is built around.

AI belongs in that work where it pays. The Five Eyes statement says defenders who build AI tools into security operations can detect vulnerabilities earlier, improve software quality and respond faster. In practice that means reading long changelogs, finding deprecated code, writing upgrade and regression tests, and reviewing changes. People stay in control where judgment matters: an engineer approves every change that ships. Used this way, AI vulnerability discovery and AI-assisted engineering help defenders keep pace. If PHP is on your list this week, start with how to check your site is really patched for PHP2Shell.

Five Questions to Ask Your Team This Week

AI vulnerability discovery will keep getting faster. Whether that helps you or an attacker depends on how fast your patch management can act on what is found. Ask your team five questions this week:

1. Where does it run? Every runtime, every version, every owner.
2. Who approves an urgent change tonight, and who is the backup?
3. How do we prove the fix is live, and where is that evidence kept?
4. What can we switch off instead of patching?
5. What can we not patch at all, and what is the plan for it?

If any answer is "we are not sure", that is the next thing to fix, and it is usually a process change, not a purchase. If you would like a second opinion, Book a free Next-Step Review. Bring one system you are not sure you can patch. It is a 30-minute conversation, followed by a one-page brief within two working days. If improving what you have is enough, the brief will say so.

Frequently Asked Questions

Did AI vulnerability discovery find PHP2Shell by itself?

No. Researchers at Wiz, Calif and OpenAI used frontier AI models as tools and worked with the PHP team on discovery, coordination and patch verification. AI made the work much faster; people still led it.

Why is patch management still slow when AI vulnerability discovery is fast?

Patch management covers identifying, prioritizing, acquiring, installing and verifying updates. AI speeds up the analysis, but finding where the software runs, approving the change, restarting services and proving the fix is live still need people and clear ownership.

What should we patch first?

Start with internet-facing systems and flaws known to be exploited. CISA's BOD 26-04 sets deadlines by public exposure, exploitation status, whether exploitation can be automated and the attacker's level of control, and CISA urged organizations to prioritize internet-facing systems for PHP2Shell.

What should we do with end-of-life software that gets no patch?

For PHP2Shell, CISA said organizations that cannot update immediately, or that still run PHP 8.1 or earlier, should take PHP-based systems offline until they can be patched or updated. Outside an emergency, apply any vendor or distribution backport, restrict access and record the risk you are accepting. Then modernize one release at a time instead of a big-bang rewrite.

Where does AI genuinely help defenders?

In reading advisories and changelogs, finding deprecated code, writing upgrade tests and reviewing changes. The Five Eyes agency leaders say AI in security operations can help detect vulnerabilities earlier and respond faster. An engineer should still approve every change that ships.