• In two 2026 CISA-coordinated cases, maintainers triaged reports and began committing source fixes within a day. The advisories followed seven and 11 weeks later, and one project never produced a versioned release.
• Critical infrastructure often has a slower, more constrained chain between an upstream fix and operational deployment, so the vulnerable version stays in service longer.
• Product vendors are best placed to map upstream fixes to affected product versions, and procurement is where customers can require it.

Ask where remediation stalls, and most teams name two things: triaging the report, then writing the patch. Two CISA-coordinated disclosures in 2026 suggest otherwise. AI-assisted review found exploitable flaws in two unfamiliar C/C++ codebases, each within a week. The reports were precise enough that both maintainers confirmed the findings and began committing source fixes within a day. What took months was everything after that.

Two cases, same gap

The healthcare case, ICSMA-26-181-01, covered five vulnerabilities in OFFIS DCMTK, an open source DICOM toolkit embedded across imaging systems. One let an unauthenticated requester read patient scheduling records from outside the intended storage area. Those records show who is being imaged, and when. All five were fixed on the project’s public development branch beginning May 12, seven weeks before the advisory explained what those commits were. None reached a versioned release, so even once the warning arrived, operators were pointed at a source snapshot rather than a numbered build they could adopt.

The grid case, ICSA-26-204-06, covered four flaws in libIEC61850, an open source implementation of the protocol that carries control and protection of traffic inside electrical substations. The most severe was an unauthenticated heap overflow reached through the initial connection-setup message, with remote code execution demonstrated in an unhardened lab build. Fixes began landing publicly on May 8; the release carrying them and the advisory explaining them both arrived on July 23, 76 days later.

The bottleneck appeared differently in each: DCMTK never produced a versioned release; libIEC61850 produced one only after those 76 days. Neither advisory reports exploitation; the concern is the interval when a fix was public, but its security significance was not.

Why the chain runs longer here

In many software ecosystems, an upstream fix reaches users through an established package channel within days. Critical-infrastructure components face a longer route: a library release, a product vendor’s build, conformance or safety validation, a maintenance window, sometimes a site visit. Most hospitals and utilities cannot rebuild the products they bought. That falls to the vendor or integrator, whose release is gated by testing that exists for good reasons.

So, the 76 days is only the first leg. Formal patch testing can begin only once a supported release exists, and patching operational technology is a risk-management decision bound by uptime and safety.

What AI changes

AI did not make this chain slow. In these cases, what it compressed is everything up to the fix, and nothing after. Discovery went first: nine CVEs in unfamiliar code.

Triage came next, and that is the less obvious half. Both reports carried root-cause analysis, exact file and line references, and reproduction detail. A maintainer can reproduce and assess such a report directly, without first reconstructing what the reporter meant. That is the opposite of what the ecosystem has been bracing for. In January 2026, curl ended its bug bounty after an explosion of AI slop drove its confirmed-vulnerability rate from above 15% to below 5%. The difference is how the tool is used. These findings went through a refute-or-promote pipeline that uses cross-model and adversarial critics before human review.

What did not compress is everything after the fix, and that interval is not benign. When Ivanti shipped a routine-looking release in February 2025, Mandiant assessed that a China-nexus actor likely studied the patch and was exploiting appliances by mid-March, weeks before the advisory. Defenders saw a maintenance update; the attacker saw a blueprint.

Separately, Google’s Threat Intelligence Group reported in May 2026 that state-linked actors were prompting AI models to audit embedded firmware and protocol implementations for pre-authentication remote code execution, the same code class as the grid library.

Where the delay can be cut

Upstream: let the warning follow the code. When a security fix must land publicly before a release exists, the embargo should be reassessed rather than run to its original date: an interim advisory can identify the affected component, the versions at risk, and the remediation status while the release is still being built.

Downstream: push monitoring to whoever ships the product. Most operators cannot reliably track upstream commits across every component embedded in purchased systems. Procurement is where that becomes enforceable: require suppliers to disclose embedded components, monitor them upstream, and state per product whether an advisory applies. Software bills of materials list declared components, and runtime inventory shows what is actually deployed.

Then decide, with a deadline.An organization that builds its own software can backport, contain, replace, or accept. A hospital running a purchased imaging system usually cannot backport or replace, so its realistic options are containment and pressure on the supplier. Every case still needs a named owner and a decision date. “Waiting on vendor” is a status, not a decision.