All three FortiOS criticals come in where your firewall already trusted

On 10 November Fortinet published 46 security advisories. Eight are marked critical and eight touch FortiOS; three sit in that intersection. All three need the same thing to work: that whoever attacks is already where the box trusted. On the segment where OSPF is spoken, in the iBGP neighbour's chair, or on the channel two cluster members use to synchronise. None of the three goes through the VPN portal or the admin interface, which is where almost everybody looks.

A firewall does more than its name holds. It filters, yes, and that part is in the risk register, gets audited and shows up in the compliance report. But it also decides which way traffic leaves, talks to its peers and synchronises with its partner. All of that machinery runs on trust granted in advance, usually by somebody who no longer works here, and that is where the three patches worth talking about land.

The one that goes first: high availability

FG-IR-26-273 / CVE-2026-126259, CVSS 9.0. Straight from the advisory: "A missing authentication for critical function vulnerability [cwe-306] in FortiOS may allow an unauthenticated attacker with HA FGSP + standalone-config-sync, or autoscale to execute command as super admin via crafted HA packets". No credentials, super-admin rights, by sending packets to the synchronisation channel. The vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and that C:H is what puts it ahead of the other two: here everything is readable. It affects 8.0.0, 7.6.0–7.6.7, 7.4.0–7.4.12, 7.2.0–7.2.13 and the whole 7.0 branch; fixed in 8.0.1, 7.6.8, 7.4.13 and 7.2.14; for 7.0, as with the OSPF one, the advisory publishes no fixed build and tells you to migrate. Watch the 8.0 detail, because it is easy to trip over: here 8.0.1 is enough, while the two routing ones want 8.0.2.

There is a tension in this advisory worth pointing at rather than papering over. The title Fortinet gives it is "Unauthenticated adjacent command execution via HA" —adjacent— while the published vector says AV:N, network. One means you have to be on the same segment, the other that anywhere a packet can come from will do. Fortinet does not resolve the contradiction and we are not going to choose for them; what we do meanwhile is plan for the bad reading, which is the vector's. The condition that is clear is the other one: it needs FGSP with configuration synchronisation enabled, or an autoscale deployment. That is an explicit configuration condition, and it marks the difference with the other two advisories, which publish none.

The other two read nothing: they change the map

FG-IR-26-267 / CVE-2026-126253, CVSS 9.3, in the OSPF daemon of FortiOS and FortiSASE: "may allow an unauthenticated attacker to broadcast LSA via specially crafted request". An LSA is the announcement a router uses to tell the others which networks it reaches, so broadcasting fake LSAs is rewriting the map the neighbours work from. Vector AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H, classified CWE-305. It affects 8.0.0–8.0.1, 7.6.0–7.6.7, 7.4.0–7.4.12, 7.2.0–7.2.13 and 7.0.1–7.0.19, fixed in 8.0.2, 7.6.8, 7.4.13 and 7.2.14; for the 7.0 branch the advisory publishes no fixed build, it says "Migrate to a fixed release".

FG-IR-26-268 / CVE-2026-126254, CVSS 9.6, a numeric truncation error (CWE-197) in the BGP daemon: "may allow a configured ibgp neighbor to send malicious/malformed attributes to all connected routers via a specially crafted request". Vector AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H, same affected branches except 7.0 and the same fixed versions. And here is what those two share and the HA one does not: they carry C:N. Confidentiality, none. They read nothing. What they compromise is integrity and availability; in plain terms, the map.

It is worth saying what that C:N scores and what it does not. It scores the flaw, not what comes afterwards. Steering traffic towards a machine that reads it is the classic follow-up, and chaining the two is perfectly possible; the point is that the stealing is then done by something else, with its own score. For what concerns us today —deciding what gets touched and when— it still helps: on their own these two take nothing, and that is precisely why they will leave no trace anywhere you would look for one.

Here "PR:L" describes a neighbour, not a credential

On the sheet where patches get prioritised, PR:L always reads the same way: "needs an account, lowers the risk". In the BGP one the requirement is not an account, it is being on the list of configured neighbours. A caveat before anyone corrects us: an iBGP session in FortiOS supports a TCP-MD5 password, so credentials may well exist; what the metric describes is not that, it is position. CVSS has no box for "trusted peer of a routing protocol", encodes it as low privilege, and on the spreadsheet it ends up looking like an obstacle for the attacker when it is an architecture decision you made.

Before closing the tab with "I do not run BGP", look at how you built your SD-WAN. In the fabric overlay deployment the vendor itself documents, the hub and the branches sit in the same autonomous system number: the published example shows a local AS number 65400 with all four neighbours also in 65400. Same AS is iBGP. Every branch of an SD-WAN built by the manual is, literally, "a configured ibgp neighbor". The router in the Girona shop stops being a detail of the network and becomes a trusted peer of the central firewall, with everything that implies the day somebody gets inside it. And if your backup link was a modem from the previous generation, you already know what happens when traffic leaves the wrong way.

S:C: the damage does not show on the box you patch

Both routing vectors carry S:C, scope changed: in CVSS that means the impact reaches beyond the security scope governed by the vulnerable component. The BGP advisory says it with no metrics at all, in one line: "to all connected routers". The operational consequence is uncomfortable. The FortiGate stays up, CPU normal, tunnels established, dashboard green, while what moves is in the neighbours' routing tables: a prefix appearing where it was not, a metric changing, traffic leaving through the backup link, a destination unreachable for forty seconds with nobody able to say why.

The question that leaves on the table is not which version you run, which takes a minute to answer. It is whether you have an alert that fires when a route changes. Everybody watches interfaces going down; CPU too. A change in the routing table triggers nothing in almost any monitoring setup we have come across, and it is the only signal either of them would produce. We wrote it eight days ago about a different piece of network kit: applying the patch and ceasing to be exposed are not the same date. Here it is worse, because between those two dates there is not even a log to look at.

What you have until you upgrade

All three advisories carry a field that gets read rarely and that here tells the three apart. The BGP and the HA ones have a virtual patch: FG-VD-62507.0day, available in FMWP database update 26.118, for the former, and FG-VD-61445.0day for the latter. The OSPF one says Virtual Patch: No, and carries no workaround section either. Worth understanding what that is before breathing easy: a virtual patch is a signature that recognises the attack and drops it in transit, not a fix for the flaw. It works if the traffic crosses a point where that inspection is active and the subscription current. The box stays vulnerable; what it gains is time until the upgrade window, which is usually just what is needed.

For the OSPF one there is not even that, and the reason is probably in its classification: CWE-305 is an authentication bypass, so the textbook countermeasure —setting an area or interface key— is the very layer the flaw calls into question. That is as far as we go; Fortinet does not spell out which part of the control is skipped and we will not deduce it for them. Authenticating adjacencies is still the right thing to do, not least because of the laptop somebody plugs into the wrong VLAN, but we are not selling it as armour against this CVE because nobody has published that it is. When there is no clear countermeasure, the lever left is reach: AV:A, you have to be on the segment where OSPF is spoken.

And who is on that segment? The honest list for a network that grew in layers almost always includes one of these: the transit VLAN shared with the carrier's box, the segment where a third-party appliance installed in a hurry lives, the link to a partner built for a project that ended, a hypervisor with a virtual machine that has a leg in there, or the interconnection point of a shared data centre. OSPF is not configured by who you are, but by which interfaces I listen on. One interface too many is one neighbour too many.

When this is NOT urgent for you

If your FortiGate has four static routes and a default towards the carrier, and the high-availability pair —if there is one— is the classic kind, all three FortiOS criticals can wait for the normal maintenance window. Saying so costs us billable work and it is the truth: most of the SMEs we see speak no dynamic routing protocol and never will. The check is five minutes and five commands that modify nothing: show router ospf and show router bgp say whether there is configuration; get router info ospf neighbor and get router info bgp summary, whether somebody is talking on the other side as well; and show system standalone-cluster, together with standalone-config-sync from show system ha, covers the third one's condition.

Two cautions so that "not my problem" is honest. First: the two routing advisories publish no explicit configuration condition —they talk about the daemon— so configuration gets checked, not assumed. The assumption we have seen fail most often is "nobody here has touched routing". Second: if the box has several VDOMs, routing configuration belongs to each VDOM and all of them have to be checked, including the one a previous provider built and nobody opens; and on a cluster, both members.

The rest of the batch and the order we follow

Of the 46 advisories, 38 do not list FortiOS: nearly all are FortiManager and FortiAnalyzer, and that is where the other five criticals are, among them CVE-2026-126261 (CVSS 9.0, improper authorization in FGFM before password verification, "execute code or commands via crafted FGFM packets" for anyone who can reach that port), CVE-2026-126260 (pre-auth SSRF) and CVE-2026-126262 (SQL injection). That is the part that took the headlines, and rightly so: reaching a FortiManager's FGFM port is, on almost any network, easier than getting onto an OSPF segment.

With that in front of you, the order we follow when a batch like this lands has four steps, and the first is not patching. One: pull from FortiManager, which is what it is for, which version each box runs, which ones speak OSPF or BGP and which have FGSP or autoscale. Two: those meeting the condition in CVE-2026-126259, because it is the only FortiOS one that, without asking for credentials, ends in super admin. Three: the management plane, with the uncomfortable question of who can reach the FGFM port, which on too many networks is "anyone who is inside". Four: the FortiGates speaking routing protocols, starting with those whose neighbours you do not control, and the rest in the normal window.

One factual note to size the urgency, with its caveat. None of the eight criticals appears in CISA's KEV catalogue: we checked today against the catalogue file, 1,779 entries, zero matches for all eight CVEs. The caveat is that the version CISA serves today is 2026.11.10, from the same day as the batch, so what that zero really says is "not yet", not "never". Fortinet, for its part, marks the three FortiOS ones as not exploited. That does not buy six months; it buys the difference between tonight and the next window.

What a version number does not fix

A month from now there will be another batch and these three places will still be the same places. What changes from one network to the next is how much damage a neighbour that misbehaves one day can do, and that depends on four design decisions taken once: listening for OSPF only on the interfaces where it is needed; authenticating adjacencies, for everything else; filtering inbound prefixes from neighbours that are not yours, so that somebody else's routing table cannot rewrite yours wholesale; and taking the synchronisation channel and the management plane off the network that carries user traffic.

The case we meet most often is not a badly built network. It is a network that grew in layers —one site, then two, then the data centre, then the new carrier— and where today nobody can draw on a whiteboard who announces routes to whom. That drawing is half the work and it is the first thing we do when we take over an existing corporate network: the real adjacency map, which neighbour belongs to whom, what comes in unfiltered, which interface is listening for no reason and where the cluster heartbeat travels. Versions come afterwards, and they go much faster once that map exists. With an SD-WAN over tunnels the drawing matters even more, because every branch adds one more trusted peer.

Sources (verified 13 Nov 2026, 18:00 CET). Fortinet PSIRT listing, walked page by page: 46 advisories dated 10 Nov 2026, of which eight critical (FG-IR-26-267, -268, -273, -219, -244, -274, -275 and -276) and eight listing FortiOS (-267, -268, -269, -270, -272, -273, -193 and -195). FG-IR-26-273 (CVE-2026-126259): title, CVSS 9.0, vector, CWE-306, the verbatim quote, affected and fixed versions and virtual patch FG-VD-61445.0day. FG-IR-26-267 (CVE-2026-126253): CVSS 9.3, vector, CWE-305, the quote, the versions, the "Migrate to a fixed release" for 7.0, "Virtual Patch: No" and "Known Exploited: No". FG-IR-26-268 (CVE-2026-126254): CVSS 9.6, vector, CWE-197, the full verbatim quote and virtual patch FG-VD-62507.0day in FMWP 26.118. FG-IR-26-275 (CVE-2026-126261, 9.0): FGFM and its quote. The iBGP in the reference design comes from Fortinet documentation, "Verifying BGP routing on the hub" (local AS 65400 and all four neighbours in the same AS). get router info ospf neighbor and get router info bgp summary are in the CLI troubleshooting cheat sheet; show router ospf, show router bgp, show system standalone-cluster and show system ha are simply the display of the corresponding configuration sections (config system standalone-cluster, where FGSP is configured; standalone-config-sync sits under config system ha). KEV checked against the JSON file of CISA's catalogue, version 2026.11.10, 1,779 entries. Ours is the framing —all three FortiOS criticals require being where the box already trusted—, the reading of C:N and of what it does not score, the evidence that the SD-WAN reference design turns every branch into an iBGP neighbour, the monitoring gap around route changes, and the four-step order. The reading of S:C and of PR:L as position rather than credential has also been published in other analyses of the same batch. Honest note: the HA advisory is titled "adjacent" while its vector says AV:N; we plan for the vector.