Patch Now, Explain Later: What Fortinet's Silent Patching Window Means for Vulnerability Disclosure Timing

Nov 12, 2026 · 7 min read vulnerabilitymanagementfortinetpatchmanagementthreatintelligencecybersecurity

On 21 and 22 October 2026, Fortinet shipped a set of fixes for FortiOS, FortiManager, FortiAnalyzer, FortiMail and FortiAuthenticator and asked customers to upgrade. It did not say what the fixes were for. The advisories, with CVE IDs and severity ratings, came out on 10 November, Fortinet’s next monthly disclosure day. For about nineteen days, the people who knew what those patches fixed were Fortinet and anyone who compared the old builds with the new ones.

That gap is the subject of this piece. Vulnerability disclosure timing used to be a courtesy that vendors and researchers worked out between them. It now works as a security control. And like any control, it protects some people and leaves others exposed.

What actually happened

Here is the sequence, drawn from Fortinet’s PSIRT portal and the coverage around it:

  • 21–22 October: Fortinet released what blacklens called a “hardening release”. FortiMail and FortiAuthenticator fixes came out on 21 October, and FortiOS, FortiManager and FortiAnalyzer on 22 October. According to blacklens, the fixed FortiOS builds were 8.0.2, 7.6.8, 7.4.13 and 7.2.14.
  • 23 October: Australia’s ASD issued a critical alert telling organisations to apply the updates. It added that it had “no further details beyond Fortinet’s current public advice.”
  • 10 November: Fortinet’s PSIRT portal published the advisories. The ones listed as critical on that date include CVE-2026-126253 (an authentication bypass in FortiOS OSPF handling), CVE-2026-126261 (FortiManager FGFM elevation before the registration password is checked) and CVE-2026-126229 (an authorization bypass in the FortiManager/FortiAnalyzer dmserver component). Core Sentinel counted 89 advisories that day, 19 of them critical, and all of them marked as not known to be exploited.
  • The origin: Coverage reports that the highlighted issues were found by Fortinet’s own product security team working with frontier AI models. Fortinet described the release as pre-emptive.

Two details matter more than the CVE count. First, no exploitation has been reported. Second, at least one issue was not fully closed by the October builds. Secondary coverage says the FortiManager/FortiAnalyzer flaw CVE-2026-126170 still affects 8.0.2, with a fix due in 8.0.3 and a configuration workaround until then. We could not confirm that against the advisory page itself, so treat it as reported, not verified. The broader point stands either way: the batch included at least one flaw whose fix was not finished when the details were published.

The case for patching first

The argument in favour is a good one, and defenders should take it seriously.

When a CVE comes out at the same moment as a patch, attackers and defenders start together. Attackers usually win that race: a well-resourced team can diff a firmware update and build a working exploit faster than most organisations can schedule a maintenance window for an edge device. Google’s threat intelligence team has measured average time-to-exploit falling below zero in 2024: on average, exploitation now starts before a patch is available.

Shipping the fix first, without details, flips that for one group: customers who patch on the vendor’s word. They get a head start. When the advisory lands, they are already done. The ASD alert shows the model working as intended. A national agency told its constituency to patch on trust alone, and organisations that did so were protected nearly three weeks before the CVE details went public.

There’s also a scale argument. If AI-assisted internal testing turns up dozens of critical bugs in one sweep, publishing all of them the day the fix ships would hand attackers a ready-made target list. Delaying the details is a reasonable answer to a new problem.

The case against: a race you can’t see

The trouble is that silent patching only protects the customers who act without information. Everyone else is worse off, and they have no way of knowing it.

Attackers don’t need the advisory. They need the binary. A patch is the most precise disclosure there is: it shows exactly which code changed. Patch-diffing edge appliances is routine work for capable threat actors. The silent window gives defenders a head start only if attackers aren’t diffing, and nobody can check that.

There’s precedent for the window being used. In November 2025, VulnCheck reported that the FortiWeb path traversal later tracked as CVE-2025-64446 had been “exploited in the wild for at least a month prior to public disclosure”. The FortiWeb 8.0.2 release notes, which contained the fix, made no mention of it. Fortinet published the advisory on 14 November 2025, after exploitation was already public. The October 2026 release appears to be a different case, with no exploitation reported. Still, the 2025 episode shows that “fixed but undisclosed” and “being exploited” can be true at the same time.

Risk-based prioritisation stops working. Most vulnerability management programmes rank work using CVE IDs, CVSS scores, EPSS and the CISA KEV catalogue. A release with no CVE has none of those signals. For nineteen days, scanners couldn’t flag the October builds as security-critical, ticketing workflows had nothing to attach a due date to, and change boards asked to approve an emergency firewall upgrade “because the vendor said so” had no severity to weigh. Teams that ask for evidence before touching a production edge device were, by design, the last to be protected.

Partial fixes look like full ones. If a flaw survives the hardening build, as reported for CVE-2026-126170 on 8.0.2, customers who upgraded on trust think they’re covered when they aren’t. Without an advisory, there’s nothing to tell them the workaround still matters.

Impact: who is actually exposed

The people most at risk under patch-now-explain-later are not the careless ones. They are:

  • Organisations with change control on edge and management planes. FortiManager and FortiAnalyzer are management planes. Compromising one can mean configuration control over every FortiGate it manages. The same “control plane equals the whole fleet” pattern showed up in this week’s Puppet Server/OpenVox RCE.
  • MSPs and multi-tenant operators. They have to coordinate upgrades across many customers and often need a CVE before a customer will approve downtime.
  • Anyone running versions with no fix. Per blacklens, FortiMail 7.2 got no fix in the October release.

Risk rating: Medium-High as a structural issue. No exploitation has been reported for this batch, but the affected products are internet-facing or management-tier, and the exposure window can’t be seen from outside.

The CloudShieldSecure perspective

At CloudKonsult, we think the useful question isn’t whether vendors should patch silently. Some will, and AI-assisted bug discovery will probably make it more common. The useful question is what your programme does when the signal arrives with no CVE attached.

That’s a visibility problem before it’s a patching problem. You can’t act quickly on a vague “upgrade now” if you don’t know which appliances run which build, which management consoles can reach the internet, and which of them sit on the path to your cloud workloads. CloudShieldSecure is built to keep that inventory current, so that “is anything we run in this release?” takes minutes to answer, not a meeting. It also flags management planes, including firewall managers, hypervisor consoles, RMM and config-management servers, as Tier-0 exposure in their own right. We covered the same principle in our RMM agent inventory guide.

  1. Create a “vendor-urgent, no CVE” lane in change management. Decide in advance who can approve an edge or management-plane upgrade on a vendor or national CERT’s say-so, and how fast. Don’t make that call for the first time during the window.
  2. Check the October builds now. Confirm FortiOS, FortiManager, FortiAnalyzer, FortiMail and FortiAuthenticator are on the fixed trains for your branch. Then read each 10 November advisory for your products. Some fixes may be incomplete and come with workarounds that still apply.
  3. Watch sources ahead of the CVE. Subscribe to vendor CISO blogs, PSIRT feeds and national CERT alerts (ASD, NCSC, CISA). In this case they were days or weeks ahead of the CVE record.
  4. Take management interfaces off the internet. FortiManager FGFM, admin GUIs and JSON-RPC APIs should only be reachable from management networks. Isolation helps whether or not a fix is out.
  5. Treat release notes as threat intelligence. If a security vendor ships an unscheduled build with vague notes, assume a vulnerability until you’re told otherwise.
  6. Track “fixed in” and “fully fixed” separately. Record the workaround status of each advisory, not only the build number.

Silent patching isn’t going away. The organisations that do well under it will be the ones that can act on a vendor’s word quickly and safely, because they already know exactly what they run.

Sources & references

Assess your security posture today

CloudShield Secure scans, validates, and prioritises threats across your entire attack surface.

Explore CloudShield Secure →
← How to Audit AWS Cross-Account Trust Policies: …