I think security teams are counting patch time from the wrong day. Most programs start the clock at an advisory, a CVE entry or a government exploited-vulnerabilities listing. Two disclosures published this week suggest the clock starts earlier, on the day a fix ships.
What the two disclosures show
The first is Microsoft’s account of CVE-2026-73570 in Zimbra Collaboration Suite. Microsoft Security Research writes that version 10.1.20, which contains the fix, was released on July 20, 2026, and that the flaw was publicly disclosed on August 13. Between those dates, Microsoft telemetry identified activity targeting the same injection path. Specifically, two scanning tools probed the vulnerable code path from July 28 to August 7.
The second is Cisco’s advisory for CVE-2026-76504, an authentication bypass in Catalyst SD-WAN Manager rated critical at CVSS 9.8. Cisco’s advisory says its product security team became aware of active exploitation in September 2026, and the advisory itself went live on September 30. Cisco lists no workarounds beyond restricting network access to the system.
Media Partner
These are two cases, not a law. They sit next to a third that CyberTech covered earlier, where exploitation of a Citrix flaw preceded the fix by weeks. The common point is that the public paperwork trails the real exposure window on both ends.
The argument
A patch release is the earliest public signal that a flaw exists. Anyone can compare builds, read release notes and look at what changed. I cannot tell from Microsoft’s report how the Zimbra operators found the path, and I will not pretend to. What I can say is that probing began after the fix was available and before any advisory told defenders to hurry. A program that waits for the advisory was waiting through the part of the timeline when the opening was already known to someone.
My recommendation is narrow. For internet-facing systems and management planes, set the service-level clock from the vendor’s release date, and treat the CVE publication date and the KEV listing date as later milestones, not the starting gun.
There is a practical reason this matters beyond any single vendor. Release notes, change logs and new package versions are public the moment they ship, and they go to everyone at once. Microsoft observed scanning that targeted a specific injection path in a window when a fix was available and no advisory existed. That is consistent with attackers watching the same release stream defenders ignore, though the report does not say so and I am drawing that inference myself.
The strongest objection
The best counter-argument comes from operations. Vendors often hold details back on purpose so customers get time to patch before attackers get a roadmap. Rushing every vendor release into production also breaks things, and teams that move fast on every patch will cause outages of their own. That is a fair point, and I accept most of it.
It does not change the recommendation, because the recommendation is about scope. Nobody can patch everything on release day. A mail server reachable from the internet, a firewall, an SD-WAN controller and similar management planes are a short list, and they are the systems where Microsoft and Cisco both describe unauthenticated, remote access. Putting those on a fast lane from release day costs a few change windows. Leaving them on the advisory clock costs weeks of exposure that nobody is watching.
There is also a measurement benefit. Teams that count from release day get a number they can improve: days from fix available to fix deployed. Teams that count from the advisory get a number that looks better than reality, because the vendor and the public decide when it starts. Programs run on the number they measure, and I would rather measure the harder one.
What I would change on Monday
Pull the list of internet-facing and management-plane systems. Subscribe the owners to the vendor’s release feed, not only to advisories. Agree in advance that a security fix on those systems enters the change process the day it ships, with the emergency path available when a vendor reports exploitation. Then record the build running on each system and the date it changed, because Zimbra shows why: an organization that cannot say what it ran between a fix date and a disclosure date cannot rule out the window.
The advisory date will keep mattering for compliance and for reporting. For risk, I would stop using it as the start of the clock. The edge systems in our earlier argument about replacing exploited appliances are the first place to apply that.
Source: Microsoft Security Research, tracking CVE-2026-73570
