Vulnerabilities

On October 21, Fortinet's chief information security officer (CISO), Carl Windsor, told customers to upgrade FortiOS, FortiManager and FortiAnalyzer as "a priority change rather than a routine maintenance cycle". The fixed builds came out on October 21 and 22. They close critical and high-severity vulnerabilities, but Fortinet has not said how many, which components they sit in, or how they are triggered. CVE IDs, CVSS scores and individual advisories will be published on the FortiGuard PSIRT page on November 10, Fortinet's next monthly Patch Tuesday.

If you run a FortiGate on FortiOS 7.2, 7.4, 7.6 or 8.0, or manage FortiGates from FortiManager or FortiAnalyzer, you are in scope. Fortinet says the flaws came out of product security testing assisted by frontier AI models, and it thanked Anthropic, OpenAI, Google and SpaceX for working with it. As of the latest reporting, neither Fortinet nor CISA's Known Exploited Vulnerabilities (KEV) catalog lists any of these issues as exploited. The risk in the next two weeks comes from the patches themselves.

Why the fix ships before the details

A fixed firmware build is a map to the bug. Compare the new FortiOS image with the previous one, a technique called patch diffing, and the changed functions show where the input check or bounds check was added. Windsor's warning is that AI tools shorten that work: an attacker can diff the builds, have a model explain each change, and get to a working exploit in hours or days. He also flagged chaining, where several lower-severity bugs found in the same diff are combined into one serious attack.

Fortinet has seen this from the other side. In a June 30 update on its use of frontier AI, Windsor wrote that the models, run through Anthropic's Glasswing (Mythos) and OpenAI's Daybreak programmes, were effective at reverse-engineering fixed vulnerabilities. In more than 100 source code tests across 30 product families, about 40% of findings were true positives at roughly $540 in tokens each. The same tooling is available to anyone holding the October builds.

So the 19 days between October 22 and November 10 cut both ways. Defenders without a CVE cannot score the risk or see whether their configuration is affected. A well-resourced attacker does not need the CVE text, only the two firmware images. Devices upgraded before November 10 are out of scope for whatever exploit work started on October 22.

What attackers are doing

Nothing confirmed for these fixes yet. Fortinet's post does not report exploitation, Rescana found no exploitation reports from national CERTs as of October 23, and there is no KEV entry. FortiGate management interfaces are attacked constantly, and IT-Connect notes that the danger with Fortinet flaws tends to peak in the days after details are published. Two recent examples are covered in our posts on PEERSTITCH and FortiBleed.

What to do

1. Find every affected device

On each FortiGate, run get system status in the CLI and read the Version line, or check the System Information widget on the dashboard. The same command works on FortiManager and FortiAnalyzer. In FortiManager, Device Manager shows firmware for every managed FortiGate in one list, which is quicker than logging into each unit.

Note the offset between products: FortiOS 7.4 is fixed in 7.4.13 and 7.2 in 7.2.14, while FortiManager and FortiAnalyzer are fixed one build lower, in 7.4.12 and 7.2.13. One early report gave 7.4.12 for FortiOS too; Fortinet's own table says 7.4.13. FortiOS 7.0 and older lines are not in Fortinet's fixed list, so plan to move those devices to a supported branch.

2. Upgrade in the right order

Start with FortiGates whose administrative interface or SSL VPN faces the internet, then FortiManager and FortiAnalyzer, then internal units. Fortinet suggested booking maintenance windows for internet-facing systems on October 22 and 23, so anything still waiting is already behind its plan. The Upgrade Path Tool gives the tested hops from your current build to the target, which matters if a unit is several builds behind.

Back up the configuration first. If you use private data encryption on an HA pair, check the release notes before upgrading, and keep that backup with its key. Before pushing policy from an upgraded FortiManager to FortiGates still on an older build, run an install preview: one administrator who tested the 7.6.8 release saw an install fail because FortiManager generated a setting the older FortiOS did not accept. After the reboot, get system status should show the new build, and diagnose sys flash list shows the previous image on the other partition if you need to roll back.

FortiSASE is updated by Fortinet. FortiManager Cloud has the fix available but may need you to start the update. Public cloud FortiGate images arrive through the cloud providers' normal release processes, so check your marketplace version.

3. Close the management plane until you have upgraded

These steps lower the risk while you wait for a maintenance window. They do not replace the upgrade.

Remove HTTPS, HTTP and SSH administration from WAN interfaces. In the CLI, config system interface, edit wan1, then set allowaccess ping replaces the access list with ping only (add fgfm back if FortiManager reaches the device on that interface). Check the result with show full-configuration system interface wan1 | grep allowaccess.

If remote administration has to stay, pin each admin account to trusted sources: config system admin, edit <name>, set trusthost1 203.0.113.10 255.255.255.255, using your management network or jump host address. A local-in policy that allows the admin port only from those addresses adds a second layer. Keep FortiManager's own GUI and FortiGate-to-FortiManager (FGFM) service off the internet, and make sure every admin account has a unique password and multi-factor authentication.

4. Check the logs, before and after

Fortinet asks customers to look for unusual administrative access and unapproved configuration changes on both sides of the upgrade. On FortiOS, open Log & Report, System Events, or filter in the CLI with execute log filter category 1 and execute log filter field logid 0100032001 before execute log display.

The log IDs to review:

• 0100032001, admin login successful. Check the srcip and user fields for addresses outside your management ranges and logins at odd hours.
• 0100032002, admin login failed. A burst from one address before a success is worth a closer look.
• 0100044547, object attribute configured. This records created, changed and deleted objects with the config path, which is where a new admin account, VPN user or firewall policy shows up.

Export these to FortiAnalyzer or your SIEM, since a device that has been compromised can have its local logs changed. Keep a copy from before the upgrade so you can compare once the November 10 advisories describe what to look for.

Patching without a CVE

Many patch processes start with a CVE: it is what the scanner matches, what the risk score is built from, and what the change board asks for. A release like this one has none of that for two weeks. Teams that wait for a CVSS score before scheduling a firewall upgrade will be starting on November 10, the same day everyone else learns where the bugs are. For edge devices, a vendor statement of "critical, upgrade now" from the vendor's own CISO is enough to move the change forward.

Getting through this quickly depends on knowing which devices you have and which of them can be reached from the internet, which is the first thing we map in attack surface management. If you want a second pair of eyes on how your FortiGates are exposed and configured, our safeguarding and hardening work covers it. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Fortinet: security hardening release for multiple products, Fortinet: update on use of frontier AI, FortiGuard PSIRT, IT-Connect, IT Brief UK, Cyber Security News, Cyber Kendra, Rescana, Fortinet Upgrade Path Tool, FortiOS log reference 32001, FortiOS log reference 44547.