Fortinet says critical and high severity fixes are out for five product lines, with advisories held to 10 November

Nineteen days between the fix and the advisory, and a release note that lists one issue

Fortinet's own change logs date FortiOS 7.6.8, 7.4.13, 7.2.14 and 8.0.2 to 22 October 2026, and its chief information security officer says the advisories that describe the fixes will appear on Patch Tuesday, 10 November. That is a 19 day gap (derived: 22 October to 10 November), and 4 of those days had passed when this page was written at 12:03 GMT on Monday 26 October 2026. Fortinet says the releases it lists, across five product lines, carry critical and high severity fixes. The public release notes for the same builds say very little: the FortiOS 8.0.2 notes list one resolved issue, the FortiManager 8.0.2 notes list one, and the FortiAnalyzer 8.0.2 notes list none (counts are this site's own tally of the pages, derived).

What that does not establish is most of what a defender would like to know. No CVE identifier, vulnerability count, component, severity score or exploit condition for these fixes is public. The claim that AI models helped find the flaws is Fortinet's statement, and this site has not tested it. Nothing read for this briefing says any of the flaws has been exploited, and none can appear in CISA's Known Exploited Vulnerabilities catalogue yet, because that catalogue is keyed by CVE identifier and no identifier has been published (derived; the catalogue version read was dated 23 October 2026).

Sources: Fortinet's announcement of 21 October, its 30 June post on frontier AI testing, its Security Vulnerability Policy, the release notes and the advisory feed, all read directly. Help Net Security reported the story on 26 October and is a secondary source; where it and Fortinet differ, this page follows Fortinet and says so. Everything was read between 12:03 and 12:21 GMT on Monday 26 October 2026, and the advisory feed, the catalogue and the release notes can change within hours.

What Fortinet's announcement says

The announcement is a blog post in Fortinet's CISO Collective category, dated 21 October 2026, under the title "Fortinet Releases Security Hardening Release for Multiple Products". It says Fortinet will release a coordinated set of updates for FortiOS, FortiManager and FortiAnalyzer on 22 October, after recent releases from FortiMail and FortiAuthenticator, and urges customers to upgrade promptly, internet facing devices first. It says the releases include fixes for vulnerabilities identified through Fortinet's frontier AI assisted testing programme, and thanks Anthropic, OpenAI, Google and SpaceX for their collaboration. It gives four reasons for urgency: critical and high severity fixes, faster weaponisation with AI, patch diffing, and chaining of lower severity flaws.

On timing it says: "public advisories will be made available at the next Patch Tuesday on November 10", on the Fortinet PSIRT page. It also says FortiSASE would be updated automatically before 22 October, FortiManager Cloud updates would be available by 22 October but might need a manual update, and updates for public cloud instances were being pushed out through the cloud partners.

Counted from that table (derived): 5 product lines, 18 branch rows, 17 of them with a fixed version and one (FortiMail 7.2) told to move to a later branch. Every row lists every version below the fixed one in its branch as affected, so the table says nothing about which models, features or configurations matter. The 17 fixed versions are the ones the next table follows.

What the public release notes say about the same builds

Each of the 17 fixed versions has a public release notes page on docs.fortinet.com that opened without a login. The change log and resolved issues page of every one was read. None of the 34 pages uses the word hardening or the word frontier (derived from a text search of the saved pages). The counts below are bug identifier rows on each resolved issues page, tallied by this site (derived); they can include a CVE reference row. The release notes do not say which entries, if any, are the fixes the announcement describes.

Four readings follow, each labelled for what it is.

The notes are not the advisory. The FortiOS 8.0.2 page lists one issue, a local in virtual patch that fails to inspect traffic on the HA management interface (bug 1328306). Fortinet's announcement says the same release carries critical and high severity fixes. Whatever those are, they are not described on that page in any way a reader could find.

Some pages carry security worded entries. FortiOS 7.6.8 and 7.4.13 list "Security vulnerability occurs when connecting to a malicious SSH server with crafted packets" (bug 1309910). The FortiMail 8.0.2 notes end with a table headed "no longer vulnerable" to CVE and CWE references: ten bug identifiers, five of them with a weakness class beside them (CWE-22 path traversal, CWE-89 SQL injection, CWE-321 hard coded key, CWE-522 insufficiently protected credentials, CWE-1050 resource consumption in a loop), and no CVE identifier anywhere on the page. Fortinet does not say whether any of these belong to the hardening release, so this page does not say so either.

The FortiMail and FortiAuthenticator dates do not match the announcement. The announcement's table marks FortiMail and FortiAuthenticator "Today", which is 21 October. The FortiMail change logs date their first releases to 2 and 3 October and FortiAuthenticator 6.6.11 to 7 October, while FortiAuthenticator 8.0.4 is dated 22 October. The record does not reconcile the two. If the October builds do carry hardening fixes, the gap to 10 November for those products is 34 to 39 days, not 19 (derived).

The notes were still being edited after release. The change logs show FortiManager 8.0.2 updated on 23 October, FortiManager 7.6.8 on 23 and 24 October, FortiManager 7.4.12 on 23 and 24 October, and FortiAuthenticator 8.0.4 gained a resolved issue entry on 23 October. A reader who saved the notes on 22 October holds an older version.

Three labels to read twice

"Security hardening release." Hardening sounds like optional tightening. The same announcement says the releases "include critical and high" severity fixes and tells customers to treat them as a priority change rather than routine maintenance. The label does no work as a control: it neither describes the flaws nor says that a device which has not upgraded is exposed. Fortinet's own affected version ranges, which cover every earlier version in each branch, say it is.

"Critical FortiOS flaws." That is the headline on Help Net Security's report. Fortinet's announcement says the set of releases includes critical and high severity fixes, and does not say which product holds a critical one. FortiOS may well hold one. The record read does not say so, and the same is true of FortiManager, FortiAnalyzer, FortiMail and FortiAuthenticator. Help Net Security also writes that at least some of the flaws may be remotely exploitable without prior authentication. That is the outlet's inference from the severity rating, not a Fortinet statement.

"Found with AI help and validated by humans." The 21 October announcement says the fixes address vulnerabilities identified through Fortinet's frontier AI assisted testing programme. It does not contain the word human. The human review comes from the earlier 30 June post, which says Fortinet analysts manually review every finding as the human in the loop before accepting a false positive classification. That post also gives the programme's results to the date of writing: over 100 tests across 30 product families, with 40 per cent of findings true positives, 30 per cent false positives and 30 per cent security best practice rather than vulnerabilities. It gives no count of findings, so how many vulnerabilities sit behind the 40 per cent cannot be derived. It puts the average token cost at around 540 dollars per true positive. All of this is the vendor's account. The announcement thanks four AI companies but does not say which model found which flaw, or whether any flaw came from an outside researcher.

Why the date matters, and what the post leaves open

Fortinet's policy page says: "A vulnerability advisory is published on the second Tuesday of the month and a Monthly Advisory notice sent." The second Tuesday of November 2026 is the 10th (derived from the calendar), so the date matches the ordinary monthly cycle. The policy also says critical vulnerabilities may be published out of cycle, and that if Fortinet sees active exploitation it may accelerate publication. What is unusual is not the date but the order of events: the installable fixes arrived 19 days before the monthly advisory, and Fortinet announced the delay in advance.

Fortinet's own words give the tension. The announcement says that once updates are public the fixes themselves reveal where changes were made, that AI tools can help adversaries reverse engineer patches and build working exploits in hours or days, and that "The window between disclosure and exploitation continues to shrink, and we expect it to keep shrinking." The 30 June post says the frontier models are adept at assessing changes between firmware versions and building proof of concept exploits for known, remediated vulnerabilities, and cites a time to exploit of 24 to 48 hours for critical outbreaks in the FortiGuard 2026 threat landscape report, against a 4.76 day average in 2024.

Put those together, as inference rather than as anything Fortinet says. The announcement does not state that withholding the advisory is meant to slow patch diffing. Anyone who can download a build can compare it with the previous one whether or not an advisory exists, and Fortinet's own argument is that this is quick. Withholding the advisory withholds the map: the CVE identifiers, the component names and the scores that tell a defender what to prioritise. 19 days is 456 hours (derived), about 9.5 times the upper end of the 24 to 48 hour range Fortinet cites. That range describes outbreaks after disclosure, not a forecast for these builds, so it is a comparison and not a prediction. It does show that customers who read the advisories first and then patch would, on Fortinet's own logic, be late.

For scale, the advisory feed shows the two previous monthly batches: 11 advisories on 8 September and 10 on 13 October (derived from the feed item dates). The only item in the feed dated after 13 October, as read, was FG-IR-26-186, published 21 October, for two PHP core flaws, CVE-2026-109618 and CVE-2026-109619. Fortinet's advisory lists FortiOS, FortiManager, FortiAnalyzer, FortiMail and FortiAuthenticator among the products confirmed not impacted. That is a separate matter from the hardening release. Help Net Security links its report on those two identifiers under the name PHP2Shell and says the chaos that followed meant Fortinet's announcement got less attention.

Fortinet's 30 June post also promises that, when it shares these solutions publicly, it will reference the source of each vulnerability. That is the first place to look on 10 November for which fixes were found by AI testing and which were not.

Stated and not stated

Technical details

Fortinet has published no indicators of compromise, exploit specifics, detection rules or vulnerable component names for this release, and none exists to copy. Nothing here is an exploit or a method of attack. What the primary pages do print is what to run, what to set, what to check before upgrading and what to watch. Each block names the page it was copied from; the derived items say so.

First, the fixed versions in the form a script can check. This block is derived from the announcement's table, which prints the same information as rows with a dash between affected versions, and is shown here as "to".

FortiOS 8.0:           fixed 8.0.2   (affected 8.0.0 to 8.0.1)
FortiOS 7.6:           fixed 7.6.8   (affected 7.6.0 to 7.6.7)
FortiOS 7.4:           fixed 7.4.13  (affected 7.4.0 to 7.4.12)
FortiOS 7.2:           fixed 7.2.14  (affected 7.2.0 to 7.2.13)
FortiManager 8.0:      fixed 8.0.2   (affected 8.0.0 to 8.0.1)
FortiManager 7.6:      fixed 7.6.8   (affected 7.6.0 to 7.6.7)
FortiManager 7.4:      fixed 7.4.12  (affected 7.4.0 to 7.4.11)
FortiManager 7.2:      fixed 7.2.13  (affected 7.2.0 to 7.2.12)
FortiAnalyzer 8.0:     fixed 8.0.2   (affected 8.0.0 to 8.0.1)
FortiAnalyzer 7.6:     fixed 7.6.8   (affected 7.6.0 to 7.6.7)
FortiAnalyzer 7.4:     fixed 7.4.12  (affected 7.4.0 to 7.4.11)
FortiAnalyzer 7.2:     fixed 7.2.13  (affected 7.2.0 to 7.2.12)
FortiMail 8.0:         fixed 8.0.2   (affected 8.0.0 to 8.0.1)
FortiMail 7.6:         fixed 7.6.7   (affected 7.6.0 to 7.6.6)
FortiMail 7.4:         fixed 7.4.9   (affected 7.4.0 to 7.4.8)
FortiMail 7.2:         no fixed 7.2 build; upgrade to the 7.4 branch or later (affected 7.2.0 to 7.2.9)
FortiAuthenticator 8.0: fixed 8.0.4  (affected 8.0.0 to 8.0.3)
FortiAuthenticator 6.6: fixed 6.6.11 (affected 6.6.0 to 6.6.10)

Next, the interim steps Fortinet prints for customers who cannot upgrade at once, and the preparation steps. Fortinet's text says these reduce risk but do not replace a timely upgrade. The block is copied from the announcement.

Inventory: Identify every FortiManager device and FortiOS instance, prioritizing those that are exposed to the internet
Schedule maintenance windows: Prioritize change windows for October 22 to 23 for internet-facing systems
Back up configurations: Save current configurations before upgrading
Monitor: Watch logs for unusual administrative access or unapproved configuration changes before and after patching

If you cannot upgrade immediately, reduce exposure in the interim by:
Restricting administrative interfaces (HTTPS, SSH) to trusted IP addresses or disable them on external interfaces
Ensuring FortiManager administration is not reachable from the internet
Following best practices, which include: Using strong unique credentials
Enforcing MFA for all administrator accounts
These steps reduce risk but do not replace the need for a timely upgrade.

To confirm what a device runs, Fortinet's FortiOS 7.4.13 release notes print one command, in a passage about special branch models: they say to run the CLI command get system status and check that the Branch point field shows 2933. The 7.2.14 notes print the same instruction with 1778. That is the only version check the pages read print, and it is for the special branch models; for other builds, compare the version string it returns with the build strings below.

get system status

FortiOS 8.0.2 build 0251
FortiOS 7.6.8 build 3744
FortiOS 7.4.13 build 2933
FortiOS 7.2.14 build 1778
FortiManager 8.0.2 build 0198
FortiManager 7.6.8 build 3788
FortiManager 7.4.12 build 2836
FortiManager 7.2.13 build 1750
FortiAnalyzer 8.0.2 build 0198
FortiAnalyzer 7.6.8 build 3788
FortiAnalyzer 7.4.12 build 2836
FortiAnalyzer 7.2.13 build 1750
FortiMail 8.0.2 feature release, build 263
FortiMail 7.6.7 mature release, build 858
FortiMail 7.4.9 mature release, build 630
FortiAuthenticator 8.0.4, build 0191
FortiAuthenticator 6.6.11, build 1958

One upgrade note can lock administrators out. The FortiManager 8.0.2 release notes (updated 23 October) say that from FortiManager 7.4.12, 7.6.8 and 8.0.2 a CA certificate is required when an LDAP server uses LDAPS, to enforce certificate validation. Any LDAPS entry without one is lost during the upgrade, and LDAP administrators cannot log in until it is restored, so a local administrator account is needed. The notes print the setting to apply before upgrading. This is a documented behaviour change; the page does not say it belongs to the hardening fixes.

config system admin ldap
edit <server_name>
set secure ldaps
set ca-cert <certificate_name>
next
end

The same release notes carry a known issue worth reading before upgrading a FortiManager that manages FortiOS 7.4.13: FortiManager may unexpectedly push the unset strict-web-check command under the web proxy global settings when installing policies (bug 1352425 in Known Issues). Check that page before scheduling the FortiOS upgrade.

Finally, a check this site derived. Fortinet's catalogue entries cannot exist for these fixes until CVE identifiers are published, so on and after 10 November the useful query is the whole Fortinet block in CISA's catalogue. This command is this site's own, not from Fortinet or CISA; it prints Fortinet entries, newest first, with the date CISA added each.

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | jq -r '.vulnerabilities[] | select(.vendorProject=="Fortinet") | .dateAdded + " " + .cveID + " " + .product' | sort -r | head -20

What to do, in the order worth doing

Every step below comes from Fortinet's own announcement or release notes, or from the dates above. Nothing needs the advisories to justify it, which is the point of the 19 days.

What could not be verified

• Everything about the flaws themselves. No identifier, count, component or score is published, so none could be checked on CVE.org or NVD. The only CVE identifiers in this briefing, CVE-2026-109618 and CVE-2026-109619, belong to PHP and were confirmed on the CVE record service; they are context, not part of the hardening release.
• Fortinet's claim that AI testing found the flaws. The 21 October announcement and the 30 June post are the vendor's account. No independent confirmation was found.
• Whether the October FortiMail and FortiAuthenticator builds belong to the hardening release. The change logs and the announcement disagree on dates.
• The release notes counts. They are this site's tally of bug identifier rows and can include a CVE reference row.
• The FortiGuard advisory list page. Its first page, as fetched, showed nothing dated after 13 October and omitted the 21 October advisory, so it may be cached; the advisory feed was used as the authority instead.
• Time stamped. Read between 12:03 and 12:21 GMT on Monday 26 October 2026. The advisories, the catalogue and the release notes could change within hours.

The question that exposes the gap

Fortinet says attackers can turn a patch into a working exploit in hours or days. If that is true, and the advisories arrive 19 days after the fixes, who is the silence protecting: the customer who has upgraded, or the one who has not?

Key facts