After AI accelerates vulnerability discovery, the test is getting fixes into running systems

VulnCheck reports 100% year-over-year CVE growth, suggesting both AI tools and expanded numbering-authority capacity contributed; its prose leaves the comparison window unclear.¹ The figure deserves attention, but does not establish that all software flaws doubled, or that AI was the sole cause.

AI-generated editorial illustration: a server, disconnected network cable and repair tools represent cyber-incident investigation and remediation, not an actual company incident.

Disclosure volume, exploitability and actual intrusion are different questions. More discoveries can reveal previously unrecorded risks or reflect greater reporting and registration capacity. For software users, the urgent question is not who found the most vulnerabilities, but which defects affect their systems and when remediation actually takes effect.

PHP shows why severity and attack probability differ

PHP’s October 21 releases fix two critical remote-code-execution flaws: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. An October 23 advisory concerns an unusual session-upload configuration.² Problems with different prerequisites should not be merged into one undifferentiated risk, nor should the later notice be read as negating the earlier security updates.

On October 23, NCSC-NL assessed exploitation as complex and widespread exploitation as less likely, while still urging patching. Its website shutdown was precautionary.³ An outage therefore does not establish a successful intrusion; a reduced risk assessment does not justify shelving remediation.

This distinction matters operationally. Severity describes possible consequences if exploitation succeeds. Actual risk also depends on exposure, affected conditions, exploitability and the business supported. Treating every server as already compromised creates unnecessary disruption. Treating present difficulty of exploitation as permanent protection extends exposure.

The PHP Foundation traces early clues to the out-of-memory issue to follow-up on a 2024 audit; not every discovery stage should be credited to AI.⁴

More reports do not immediately mean safer software

For software users, an update request must connect to specific assets, business owners and an executable deployment plan. Without those details, receiving an advisory sooner may not shorten exposure. NIST emphasizes coordination between technical teams and business owners on patching strategy, treating maintenance as part of normal operations.⁵ The discovery-response gap should be examined in those terms, rather than inferring a project’s backlog from report volume alone.

NIST distinguishes routine patching, emergency patching, emergency mitigation and unpatchable assets in its planning scenarios.⁵ Organizations should therefore not wait for each urgent advisory to debate who may approve downtime. Business ownership, maintenance windows and escalation paths should be established beforehand, with the applicable plan selected according to actual impact. The aim is to reduce coordination delays, not assume every patch can be deployed immediately without testing.

Similarly, an AI tool identifying something suspicious should not automatically gain authority to validate it against production systems. Controlled testing, minimum necessary access and human review remain valuable. Defenders need reliably resolved risks, not more automated activity standing in for confirmation of results.

Patching is a chain that must reach production

NIST’s SP 800-40 Rev. 4 treats patch management as preventive technology maintenance, encompassing identification, prioritization, acquisition, installation and verification. It also emphasizes continuously maintained software and asset inventories.⁵ This explains why a published advisory cannot be equated with completed remediation inside an organization.

First, establish where the software runs. Self-managed servers, hosted services, container images and components embedded in third-party products may have different owners. An inventory containing only product names, without versions, accountable teams and deployment locations, leaves security staff unable to route even an accurate advisory effectively.

Second, connect priority to specific exposure. Internet-accessible, highly privileged or business-critical systems need prompt assessment; testing and rollback arrangements should reflect operational tolerance for failure. Temporary access restrictions may reduce some exposure, but should not permanently erase unresolved remediation from the work queue.

Third, verify the systems serving users, not simply download records. An updated package or successful build does not prove every running instance uses the new version. NIST distinguishes deployment from verification and calls for subsequent monitoring.⁵ Organizations should retain deployment outcomes, exception lists and review ownership so that old images or overlooked nodes do not reintroduce risk into production.

For outsourced operations and hosted services, responsibility cannot end with “the supplier is handling it.” Customers need to know who establishes the affected scope, implements changes and provides completion evidence, and how missed deadlines are escalated. Those questions move remediation forward more effectively than forwarding a list of vulnerability identifiers.

Fixing a defect does not complete incident response

Where credible intrusion indicators already exist, a patch addresses the underlying defect but cannot establish that unauthorized access never occurred. Existing incident-response procedures must then establish impact, preserve evidence and determine recovery measures. Conversely, without evidence of intrusion, a risk advisory should not be described as a confirmed data breach.

More useful measures of defensive performance include coverage of affected-asset identification, time to remediate critical systems, deployment-verification success and accountable ownership of unresolved exceptions. These track the closing of risk, rather than treating received reports or closed tickets as security in themselves.

AI can change the pace of discovery, but improved organizational security still depends on the rest of the chain keeping up. The PHP updates and reassessment show that sound caution is not the same as maximum alarm. Judgments should change with the evidence, while responsibility for remediation must outlast the news cycle.

Source notes

1. Patrick Garrity / VulnCheck, published 2026-10-22. Exploring the Risks and Impacts of AI on Vulnerability Discovery and Exploitation. ↩

2. PHP, published 2026-10-21 and 2026-10-23. Security advisory: Critical remote code execution vulnerabilities, update now; Informational advisory: Session upload progress, in the 2026 news archive. ↩

3. NCSC-NL, published 2026-10-21; updated 2026-10-23 at 15:45, timezone not stated. Update: PHP vulnerabilities remain a reason for immediate patching. ↩

4. The PHP Foundation, published 2026-10-21. Today's PHP Security Release, and How We're Strengthening PHP Security. ↩

5. Murugiah Souppaya / Karen Scarfone / NIST, published 2022-04-06. Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, SP 800-40 Rev. 4. Republished courtesy of the National Institute of Standards and Technology. Licensing statement. ↩ ↩² ↩³ ↩⁴