No patch yet: what to do in each of the four states

Vulnerability management is usually described as a queue: scores come in, the worst ones go first, the fix is installed. The cases that actually consume a security team's attention do not fit that description, because the thing being asked for does not exist yet. Over four weeks our desks covered four such cases, and the useful distinction between them was not severity. It was what had been published, and in what order.

Four states, four different responses

Only the second row is the case the standard process was designed for. The other three are where the work goes.

The window between the fix and the CVE

Zimbra 10.1.20, containing the remediation, was released on 20 July 2026. The CVE was published on 13 August. Between 28 July and 7 August — inside that gap — Microsoft Threat Intelligence observed two distinct out-of-band scanning tools probing the vulnerable injection point, using the same execution path later seen in exploitation.

Those probes were built to confirm execution rather than to deliver anything: callbacks to unique subdomains over HTTP, DNS and ICMP, or a small fingerprinting script dropped in the web root. Somebody read the fix, worked out what it fixed, and went looking for unpatched instances three weeks before the rest of the world was told there was anything to look for.

A patch is a disclosure. It names the file, the function and the condition, to anyone willing to read a diff. Treating the CVE as the start of the clock gets the sequence backwards: for an attacker the clock starts when the fix ships, and for a defender it starts when they install it.

The practical consequence is about upgrade cadence rather than about any particular bug. An organisation that applies vendor updates monthly spent that Zimbra window exposed to people who already knew. One that applies them weekly did not. No amount of CVE monitoring changes that, because during the window there was no CVE to monitor.

What a vendor gives you instead of a patch

When Fortinet disclosed CVE-2026-104286 — a path traversal combined with improper NULL handling, letting an unauthenticated attacker write arbitrary files, rated 9.8 and already exploited — fixed builds for most affected versions did not exist. What the advisory did contain was usable immediately:

• A workaround that removes the condition: disable the affected feature, or take the management interface off the internet and restrict it to trusted networks.
• An upgrade path for the oldest branch, where the fix was to move to a newer branch rather than wait.
• Indicators of compromise with file hashes, so an administrator who cannot patch can establish whether the box has already been touched.

The third item is the one that changes what a team can do. Without it, an unpatchable critical flaw leaves only anxiety; with it, the question becomes answerable today and the answer determines whether this is a patching exercise or an incident.

What exposure counts actually tell you

Published exposure figures are widely quoted and widely misread. In the F5 case, Shadowserver tracked more than 14,700 internet-facing addresses carrying BIG-IP APM fingerprints. That number bounds the problem rather than describing it: there is no breakdown of how many are already patched, how many are honeypots, and — in that case particularly — how many run the specific configuration the flaw requires, since instances acting only as an OAuth client or resource server were not affected at all.

Reading the affected-configuration line before concluding the issue does not apply is worth more than the headline count. Access management proxies sit in front of everything else, which is why a flaw in one is worth more to an attacker than a flaw in whatever it protects.

When there is no CVE at all

Kiteworks emailed customers recommending they shut their systems down for a six-hour window, citing credible threat intelligence from federal authorities that an actor may attempt to target some systems. The company said it was not aware of any compromise and called the advisory preventative. It did not answer whether the issue had a CVE or which groups were involved; the FBI declined to comment and CISA did not respond.

There is nothing to verify in that situation and no technical control to apply. What remains is judgement about the vendor, and the observation one researcher made at the time: nobody asks their entire customer base to unplug production systems over a weekend on a hunch.

A sequence that works in all four states

• Establish whether you run the affected configuration, not merely the affected product. That single line removes most advisories from your queue honestly.
• Apply the vendor workaround before deciding whether the patch timeline is acceptable — reducing exposure is usually faster than scheduling an upgrade.
• Run the published indicators against your estate whether or not you can patch. Compromise before disclosure is the normal case, not the exotic one.
• Shorten the interval between a vendor releasing an update and you installing it. That interval, not CVE monitoring, is what the pre-disclosure window attacks.
• Record what the vendor did not say. An advisory with no CVE, no patch note and no attribution is a statement about the vendor's own uncertainty, and it should be re-read when details appear.