Fortinet hardening release: patching without an advisory

Fortinet is shipping security updates for FortiOS, FortiManager and FortiAnalyzer on 22 October 2026, a day after FortiMail and FortiAuthenticator. Rated critical and high severity — but with no CVE id, no CVSS score and no description of the attack. The advisories only follow on 10 November. Anyone patching this week is closing holes they cannot name.

What Fortinet shipped on 22 October

The security hardening release is a bundled set of security updates for five product lines, announced on 21 October 2026 by Fortinet CISO Carl Windsor on Fortinet's CISO blog. On the contents, one sentence: "These releases include critical and high-severity fixes."

Everything below each fixed version is affected. FortiMail is fixed in 8.0.2, 7.6.7 and 7.4.9, FortiAuthenticator in 8.0.4 and 6.6.11; FortiMail 7.2 gets no fix and has to move to the 7.4 branch. Fortinet updates FortiSASE itself, while FortiManager Cloud may need a manual step.

Why there are no CVE ids

The advisories only appear at the next Patch Tuesday, 10 November, on the advisory page of Fortinet's Product Security Incident Response Team — part of an "ongoing commitment to responsible transparency while balancing customer security".

The origin of the flaws explains the bundling: not outside researchers, but Fortinet's own AI-assisted testing programme, with thanks to Anthropic, OpenAI, Google and SpaceX for the collaboration. Windsor described the process in June 2026: frontier models review the source code against a threat model of the firmware built beforehand; what survives is validated in penetration testing. Of the source-code findings from more than 100 tests across 30 product families, 40 per cent were true positives and 30 per cent false positives. What Claude Mythos sketched out in April now arrives as a firmware update.

A patch without a CVE id is invisible to scanners and policies

Vulnerability scanners, patch policies and ticket systems all work from CVE ids. Without the id, everything attached to it is missing too: no NVD entry, no EPSS score, no entry in the CISA KEV catalogue, no CVSS score for a patch policy to trigger on. A change request that normally draws its justification from a CVE id and a severity rating has nothing but the vendor announcement for 19 days.

The question shifts: no longer which CVE affects us, but which version runs on which reachable device, and whether it is older than the fixed one. The risk assessment loses its basis too: nothing can be said about attack prerequisites or exploitability before 10 November. What remains is reachability from outside: a FortiManager sitting on the internet is the problem, with or without a CVE id.

Patch diffing: the clock starts at release

The head start withholding the advisories is meant to create applies only to readers, not to attackers who compare. Fortinet names the risk itself: once the update is public, the fix shows where the code changed. Per the June post, this is exactly what the models excel at — "analyzing firmware, assessing changes between versions, and developing proof-of-concept exploits". Fortinet expects exploits in hours or days rather than weeks; the FortiGuard 2026 report puts time to exploit for critical outbreaks at 24 to 48 hours, down from 4.76 days on average in 2024.

That Fortinet devices are a preferred target is on record: the CISA KEV catalogue held 32 entries for Fortinet products as of 21 October 2026, two of them added this month. FortiBleed showed how methodically attackers work through exposed management interfaces. No exploitation is known for the flaws in this release; Fortinet calls the fixes pre-emptive.

What to do now

Fortinet recommends treating the release as a priority change rather than routine maintenance, and names four steps:

• Inventory: identify every FortiManager installation and FortiOS instance, internet-facing ones first.
• Maintenance windows: schedule 22 and 23 October for exposed systems.
• Back up configurations: before the upgrade, not after.
• Check logs: for unusual administrative access and unapproved configuration changes, before and after patching.

Where an immediate upgrade is not possible: restrict management access over HTTPS and SSH to trusted addresses, keep FortiManager off the internet entirely, and enforce MFA on every administrator account. Fortinet on that: "These steps reduce risk but do not replace the need for a timely upgrade."

Not to be confused: PHP2Shell runs in parallel

The two PHP flaws from 21 October are not part of this release. Fortinet tracks them separately in advisory FG-IR-26-186 and rates CVE-2026-109618 critical at CVSS 9.8 there. According to an overview by Help Net Security on 22 October, Fortinet lists twelve products as not affected, among them FortiOS, FortiManager, FortiAnalyzer, FortiMail and FortiWeb, and twelve more as under review. Palo Alto Networks reports PAN-OS and Panorama as affected in all versions, still without a fix. Mechanism and immediate measures are in our PHP2Shell post. Fortinet operators are running two separate patch tracks.

What helps – and why visibility decides

As long as the CVE ids are missing, the version inventory is the only solid basis. Through Attack Surface Management, blacklens.io records from the outside which services are reachable and which technologies run on them in which version; the inventory filters by vendor and product, and the Sentry Agent covers internal installations. That answers the question that matters this week: where is a version older than 7.6.8 running, and is it reachable from the internet?

The Threat Center matches new CVEs against that inventory in real time and shows whether a hit rests on the exact version or only on the product — for this release that starts on 10 November, because before then there are no ids to match. This week the release is an inventory question. The vulnerability question arrives in November.