Vulnerabilities

On November 10, Fortinet published the advisories behind the October hardening release it had told customers to install without saying why. The batch is large, and reporting across SecurityWeek, SecurityOnline and Cyber Security News counts eight vulnerabilities rated critical across FortiOS, FortiManager and FortiAnalyzer, with one write-up also naming FortiSASE. We could confirm four of those critical advisories directly against the FortiGuard PSIRT, Fortinet's product security team, and two of them sit in FortiManager and FortiAnalyzer, the appliances that manage and log for the rest of a firewall estate.

That placement is what makes this batch worth attention over a normal patch cycle. If you run FortiManager or FortiAnalyzer on the 7.2, 7.4, 7.6 or 8.0 branches, two of the confirmed flaws let an attacker who can reach the right port run code with no login at all. A FortiManager that can push policy to a hundred FortiGates is a single box that, once taken, reaches every firewall it controls. Fortinet has not reported any of these as exploited, and none were in the US Cybersecurity and Infrastructure Security Agency Known Exploited Vulnerabilities (KEV) catalog when the advisories went out.

How it works

The headline flaw, CVE-2026-126261 (FG-IR-26-275, CVSS 9.0), is in the FGFM service on FortiManager. FGFM, the FortiGate-to-FortiManager protocol, is how managed firewalls check in and receive configuration. The advisory describes an improper authorization problem: an unauthenticated attacker who can reach the FGFM port can be granted elevated access before the device registration password is checked, and from there execute code or commands through crafted FGFM packets. The check that is supposed to gate the channel runs too late, so the packets that follow are trusted.

CVE-2026-126260 (FG-IR-26-274, CVSS 9.0) is a second no-login path, this time through server-side request forgery (SSRF). SSRF is a bug where an attacker makes the server itself send a request of the attacker's choosing. Here it sits behind the OFTP port used for FortiAnalyzer log and report traffic, and Fortinet rates the impact as executing unauthorized code or commands. It affects FortiAnalyzer and any FortiManager that runs FortiAnalyzer features, on 7.4, 7.6 and 8.0; the 7.2 branch is not listed as affected for this one.

The third management-plane flaw needs a login but still crosses a trust boundary. CVE-2026-126229 (FG-IR-26-244, CVSS 9.1) is an authorization bypass through a user-controlled key in the dmserver component. An administrator who is only meant to see their own virtual domain, or VDOM, the partition that separates one tenant or business unit from another, can craft HTTP requests that reach other VDOMs. On a shared FortiManager or FortiAnalyzer that is the wall between customers or departments. The fourth confirmed critical, CVE-2026-126253 (FG-IR-26-267, CVSS 9.3), is in FortiOS and FortiSASE rather than the management plane: an authentication bypass in the Open Shortest Path First (OSPF) routing daemon that lets an unauthenticated attacker inject link-state advertisements, the messages routers trust to build their map of the network.

What attackers are doing

Nothing confirmed against these specific flaws. Fortinet's advisories mark each one as not known to be exploited, there is no KEV entry, and no national computer emergency response team has reported attacks tied to the November 10 identifiers.

The timing is the risk. Fortinet shipped the fixes on October 22 as a hardening release and withheld the CVE identifiers and scores until November 10, asking customers to upgrade ahead of disclosure. We covered that nineteen-day gap and why a fixed firmware build is itself a map to the bug in our post on Fortinet patching before the CVE details. That window has now closed in the attacker's favour: the advisories name the exact components, so anyone who held off upgrading is working from the same starting line as whoever is building an exploit. FortiManager and FortiAnalyzer management interfaces are probed constantly, and past Fortinet issues have seen exploitation climb in the days after details are public.

What to do

1. Upgrade the management appliances first

For FortiManager and FortiAnalyzer, Fortinet's consolidated guidance for the whole release is to move to 7.2.13, 7.4.12, 7.6.8 or 8.0.2 depending on your branch, and the HKCERT bulletin lists the same targets. Sources disagree on the 8.0 branch: the individual advisories list 8.0.1 as the minimum that closes a given flaw, Fortinet's hardening list and HKCERT point to 8.0.2 to clear the full batch, and at least one roundup cited 8.0.3. Install the latest 8.0 build you can rather than stopping at a per-advisory minimum. FortiOS is fixed one build higher on the older lines, in 7.2.14 and 7.4.13, and in 7.6.8 and 8.0.2 on the newer ones, so do not assume the FortiOS and FortiManager numbers match.

Check what you are running with get system status on each FortiManager and FortiAnalyzer, read the Version line, and use the Fortinet Upgrade Path Tool to find the tested hops if a unit is several builds behind. FortiManager Cloud and FortiAnalyzer Cloud have fixes available but may need you to start the update. FortiSASE is updated by Fortinet.

2. Lock down the ports until the upgrade lands

These steps lower exposure while a maintenance window is booked. They do not replace the upgrade.

Both no-login flaws need the attacker to reach a service port. Turn off any JSON remote procedure call (RPC) interface you are not using: on FortiManager, config system admin setting then set rpc-permit none blocks the JSON API, or use read to allow queries without changes. Restrict FGFM so managed devices reach it only from known addresses, keep the FortiManager and FortiAnalyzer graphical interfaces off the public internet, and remove HTTPS, HTTP and SSH administration from any external interface with set allowaccess. Pin each admin account to its management network with set trusthost, and require multi-factor authentication on every account.

3. Check the logs on both sides of the upgrade

Review administrative access and configuration changes before and after you patch, since a compromised appliance can alter its own local logs. On FortiOS, the log IDs worth filtering are 0100032001 for successful admin logins, 0100032002 for failed ones, and 0100044547 for created, changed or deleted objects such as a new admin account or policy. Watch the source address and user fields for logins from outside your management ranges. Export these to FortiAnalyzer or your security information and event management (SIEM) platform, and keep a copy from before the upgrade so you can compare once you know what to look for.

Why the management plane goes first

A single FortiGate at the edge is one device. FortiManager and FortiAnalyzer are not: they hold credentials for, push policy to, and collect logs from the whole fleet. An unauthenticated code-execution flaw there is not a single-firewall problem, it is an estate-wide one, which is why Fortinet's own chief information security officer framed the October release as a priority change rather than routine maintenance. The same logic applies to any management console, virtual private network concentrator or other appliance that sits in front of or above many systems. When you sort a patch backlog, those boxes earn a tier of their own, ahead of the endpoints they govern.

Getting through this quickly starts with knowing which management appliances you run and which 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 Fortinet devices are exposed and configured, or help clearing the upgrade backlog, our on-demand risk reduction team covers it. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: FortiGuard PSIRT FG-IR-26-275, FG-IR-26-274, FG-IR-26-244, FG-IR-26-267, FortiGuard PSIRT advisories, HKCERT bulletin, SecurityWeek, Rescana, Fortinet Upgrade Path Tool.