When the firmware patch drops, the exploit race has already started

For internet-facing appliances, the vendor's release is the disclosure. The clock starts when the patch ships, not when CISA lists it. Here is why that changes how you rank the queue.

On February 11, 2025, Ivanti shipped a quiet fix for Ivanti Connect Secure. The company classified it as a low-risk denial-of-service bug, in its own words a buffer overflow “with characters limited to periods and numbers” that was “determined not to be exploitable as remote code execution.” A reasonable priority-setter, reading that, would have parked it behind the week’s actual critical items.

By mid-March, a China-nexus actor was exploiting it in the wild. Mandiant later assessed that the attacker “studied the patch” and worked out that the same flaw was, in fact, a remote code execution path. Ivanti reclassified CVE-2025-22457 as critical, CVSS 9.0, unauthenticated RCE, and disclosed it on April 3, 2025. CISA added it to the Known Exploited Vulnerabilities catalog the next day. An operator who waited for the KEV listing to act was roughly seven weeks behind the patch and three weeks behind active exploitation.

The obvious read

The conventional take is that Ivanti got the severity wrong, defenders trusted the label, and the system corrected once exploitation surfaced. Bad call, eventual fix, lesson learned about a single vendor’s scoring.

That read misses the structural part. The label was not the variable that decided the outcome. The patch was. The moment Ivanti shipped a code change to an internet-facing box, the bug it fixed became discoverable to anyone willing to compare the two versions, regardless of what the release notes called it. The “low-risk DoS” framing didn’t protect anyone. It only told defenders to relax while attackers read the diff.

The pattern underneath

A patch is a roadmap. The diffing toolchain that reads it is small, mature, and free: BinDiff, Diaphora, IDA, Ghidra. You export the patched and unpatched binaries, diff them to find which functions changed, and read the assembly on the partial matches to see exactly what the vendor altered. An added bounds check, a tweaked conditional, a removed format string. Researchers deliberately pick the two adjacent releases with the smallest delta so the security fix stands out against the noise.

Firmware is a comfortable target for this work, and it’s worth being precise about why, because the claim that firmware is “easier” to diff than ordinary software is analyst reasoning, not a measured fact. The reasoning rests on three documented properties. Vendor firmware blobs ship the whole device filesystem, so you get the complete before-and-after rather than a delta. You can hash every file in both images and drop the unchanged ones instantly, collapsing the search space before any disassembly. And appliance code is rarely obfuscated; Nozomi notes that “low variation in the code and missing obfuscation due to performance and space requirements makes porting firmware patches comparably easy.” Nobody has quantified the speedup. The conditions that would produce one are all present.

The asymmetry has been on the record for years. Project Zero’s Maddie Stone put it plainly: vulnerabilities “become public knowledge as soon as a software update is released, not when they are announced in release notes.” Rapid7’s Tod Beardsley said the quiet part: “who uses debuggers to inspect the effects of patches? Exploit developers, pretty much exclusively.” A silent patch, in his framing, communicates the vulnerability details “exclusively, to skilled, criminal attackers who are specifically targeting your product, while leaving your customers in the dark.” VulnCheck’s Caitlin Condon, on a Fortinet episode, said adversaries “are actively reverse engineering patches regardless of whether suppliers tell their customers about fixed vulnerabilities or not.”

The evidence, by the clock

The Ivanti case is the cleanest illustration, but it isn’t isolated. The same shape recurs across edge vendors, and the timestamps are the proof.

CitrixBleed (CVE-2023-4966) was the bug that mass-leaked NetScaler session tokens. Citrix’s bulletin described it in three words: “Sensitive information disclosure.” Mandiant’s account is the strongest race-after-patch evidence in the set: “Prior to Citrix’s publication and our development of a PoC, we believed the session takeovers were the result of zero-day exploitation of an unknown vulnerability. Using differential firmware analysis, we identified the vulnerable endpoint and developed a PoC.” Worth being exact here: Citrix doesn’t ship silent patches so much as near-silent advisories, the CVE and the fix arriving together with a description thin enough to make Horizon3 publicly hedge on a later bug that it was “kinda hard to know which is which given the sparse technical details.”

Fortinet supplies the timeline gaps in series. FortiWeb’s CVE-2025-64446 and CVE-2025-58034 shipped fixed in v8.0.2 on October 28, 2025 with no mention of a security flaw, and weren’t disclosed until November 14 and 18, by which point the flaw was already exploited. CVE-2024-21762 was patched on February 8, 2024; Assetnote and watchTowr published a working exploit on March 15, and Shadowserver saw exploitation callbacks two days later, with roughly 133,000 instances still vulnerable.

Zyxel’s CVE-2024-11667 is the long version: firmware 5.39 shipped September 3, 2024, the CVE wasn’t published until November 27, and CISA listed it December 3, by which point it was running in Helldown ransomware attacks. We covered that one when it happened (Zyxel patched it in September and named it in November); the SmarterMail pre-auth RCE followed the same script, fixed in October and disclosed in late December. What the cluster shows, read together, is not a string of one-off vendor mistakes. It’s a consistent ordering: the patch ships first, the working exploit becomes feasible next, and the official urgency signal arrives last.

On raw speed, the honest answer is a range. watchTowr diffed Check Point’s CVE-2024-24919 and the changed code “stood out right away.” The current floor comes from Anthropic, which reported that its own model, using patch diffing alone against early-2026 Windows Patch Tuesday privilege-escalation patches, produced a first working PoC in 31 minutes. Treat that as Anthropic measuring its own system, not a neutral benchmark. For a more durable frontline number, Mandiant’s M-Trends 2024 put average time-to-exploit at five days in 2023, down from 63 in 2018-19.

Why the official signal can’t keep up

The lag isn’t incidental; it’s built into the machinery defenders lean on. The NVD enrichment backlog began in February 2024, and by that May, 93.4% of new CVEs were unanalyzed, including 82% of those with a public proof-of-concept. NIST has since moved to a risk-based model, enriching KEV and critical-software CVEs and tagging the rest “not scheduled.” The vector, the affected-product list, the CWE, the exact fields a priority-setter uses to rank, are the fields NVD stopped reliably providing.

KEV sits even further downstream. As runZero puts it, “KEVs nearly always lag against the original CVE publish dates,” which themselves lag the patch. There’s no clean population statistic for how many days separate a patch from its KEV listing, so don’t trust a median that claims one. The Zyxel and Ivanti timelines are the honest illustration: weeks where a fix existed and no official urgency did.

What this means for the queue

Edge devices are where this hurts most, and the data is unambiguous about it. Mandiant’s M-Trends 2025 found the four most-exploited vulnerabilities of 2024 were all edge devices, together accounting for nearly half of all observed exploitation. Verizon’s 2025 DBIR saw edge and VPN devices jump from 3% to 22% of exploitation actions in a single year. VulnCheck found that only 23.7% of the edge vulnerabilities it tracked appear in KEV, meaning the catalog undercounts edge exploitation by roughly four times. These boxes are internet-facing by design, hold privileged credentials, and usually run no endpoint detection.

So the ranking rule follows from the evidence rather than from any vendor’s score. For an internet-facing appliance, a security-relevant firmware update is itself the urgency signal. Not the CVSS number, which the Ivanti reclassification shows can be wrong by a full risk category. Not the KEV listing, which arrives after the exploit is already feasible. The fact that a vendor touched code on a box exposed to the internet is the input you can actually trust, because it’s the same input the attacker is working from. That argues for subscribing to vendor PSIRT feeds directly rather than waiting on NVD or KEV for the edge, and for treating an emergency change window on appliances as standing capability instead of a ticket opened after the headline. The federal benchmark is instructive: CISA’s BOD 26-04 gives agencies three days for actively-exploited, internet-facing flaws. If the floor is three days from KEV, and KEV trails the patch by weeks on the edge, the window has to open at patch ship.

What to watch

The cleanest test of whether this pattern is tightening is the gap itself: how long between a quiet appliance firmware release and the first observed exploitation. The Ivanti gap was about a month. SmarterMail’s silently patched auth bypass closed to two days in January 2026. If automated diffing keeps maturing, expect that interval to compress further, and expect the share of KEV entries that were n-days reverse-engineered from a patch, rather than true zero-days, to keep climbing. Watch, too, whether NIST’s risk-based NVD model widens or narrows the enrichment blind spot for edge CVEs that never reach KEV.

PatchDayAlert tracks these silent-patch and edge-device timelines as they break, so the firmware drop reaches your queue before the KEV listing does. The open question is whether vendors close the labeling gap on their own, or whether the diffing speed forces the issue first. The evidence so far points to the second.

When the firmware patch drops, the exploit race has already started

The obvious read

The pattern underneath

The evidence, by the clock

Why the official signal can’t keep up

What this means for the queue

What to watch

Sources

Edge devices need a tighter patch SLA than your servers

The Security Update Broke Production: A Rollback Runbook

The FortiGate firmware was current. The admin password hashes were not.

Five edge and gateway bugs went under active attack in one week. Here is the patch order.