Skip to main content

Fortinet November 2026 PSIRT Advisories: Critical FortiOS OSPF and FortiManager FGFM Flaws Need Attention Now

A rack of firewall appliances beneath a glowing holographic network map in which a central management node links to many branch nodes, with a few routing paths highlighted in red.

Fortinet published a large batch of PSIRT advisories on November 10, 2026. The fixes cover FortiOS, FortiManager, FortiAnalyzer, FortiMail, and related products. Reports on the total count differ, so check the FortiGuard PSIRT portal for the authoritative list. Most of the batch is routine patch work. Two advisories are not, and anyone running FortiGate firewalls or FortiManager in a health care environment should act on them this week.

The first is CVE-2026-126253, an authentication bypass in the FortiOS OSPF routing daemon. It lets an unauthenticated attacker inject false routing updates. The second is CVE-2026-126261, an improper authorization flaw in the FGFM management protocol on FortiManager. When the FGFM port is reachable, it allows unauthenticated remote code or command execution. Neither flaw requires credentials, and both target infrastructure that the rest of the network trusts.

At a glance

Affected: FortiOS (FortiGate), FortiSASE, FortiManager, and FortiAnalyzer. Other flaws in the same batch touch FortiMail and additional FortiOS components.

  1. Inventory every Fortinet device and record its exact version and branch.
  2. Confirm that FGFM (TCP 541) and other management ports are not reachable from the internet or from untrusted segments. Restrict access now, before you patch.
  3. Find out where OSPF is enabled on your FortiGates.
  4. Back up configurations, test, and upgrade to the fixed releases listed below. Start with internet-facing and management-plane systems.
  5. Keep watching FortiGuard PSIRT and NVD for revised advisories.

The OSPF flaw: CVE-2026-126253

Fortinet tracks this issue as FG-IR-26-267. It is classified as CWE-305 (authentication bypass by primary weakness) and rated CVSS 9.3, per the Red Tiger Security write-up and Invitty. According to Red Tiger, an unauthenticated attacker can send specially crafted requests to the OSPF daemon and broadcast link-state advertisements (LSAs). Those are the messages OSPF routers use to build their view of the network. If an attacker can feed false LSAs into your routing domain, they can redirect or black-hole traffic.

Invitty describes the attack vector as adjacent network, which means the attacker needs a foothold on a connected segment rather than access from the open internet. That narrows exposure, but it does not remove it. In a health care network, "internal" often includes a lot of devices you do not fully control. Ask yourself whether OSPF is running on any interface that faces a segment containing user workstations, biomedical devices, vendor-managed equipment, or guest access. If it is, a single compromised device on that segment could become a path to your routing table.

Invitty also notes that Fortinet has not stated whether OSPF must be enabled for a device to be exposed. Until the advisory says otherwise, do not treat a FortiGate without OSPF as safe to skip. Upgrade it anyway; the same batch includes other high-severity FortiOS fixes.

The FortiManager flaw: CVE-2026-126261

This one is tracked as FG-IR-26-275 and classified as CWE-285 (improper authorization) in the FGFM protocol, which FortiGates use to communicate with FortiManager. The CVE records report a score of 9.0 from Fortinet and 9.8 from NVD. An unauthenticated attacker who can reach FGFM on TCP 541 can execute code or commands by sending crafted packets, per the CVE record. Rescana and others report that FortiAnalyzer is affected in a similar way.

The reason this matters is what FortiManager does. It is the system that pushes policy and configuration to your whole FortiGate fleet. An attacker who controls it does not need to compromise each firewall separately. They can push malicious policy everywhere at once. For a health system that manages a main campus plus a ring of rural clinics from one FortiManager, that is the worst case: every site's perimeter and segmentation rules can be changed from one compromised box.

The practitioner consensus in analyst write-ups is blunt: FGFM should never be exposed to the internet. If your FortiGates at remote sites reach FortiManager over the internet, that traffic should be running over a VPN or restricted to known source addresses. It should not be sitting on an open port. Check this before you do anything else. In our view, restricting access is faster than an upgrade and closes the most likely attack path in the meantime.

Affected versions and fixed releases

The FortiOS ranges below match the Red Tiger and Invitty summaries, and the FortiOS 7.0 range comes from Invitty. The primary Fortinet advisories could not be retrieved while this article was prepared, so confirm every row against FG-IR-26-267 and FG-IR-26-275 before you schedule an upgrade. The FortiManager 7.4 and 7.2 rows are in dispute between sources, as noted in the table.

Product / CVEAffectedFixed in
FortiOS 8.0 (CVE-2026-126253)8.0.0 through 8.0.18.0.2
FortiOS 7.67.6.0 through 7.6.77.6.8
FortiOS 7.47.4.0 through 7.4.127.4.13
FortiOS 7.27.2.0 through 7.2.137.2.14
FortiOS 7.07.0.1 through 7.0.19No fix; migrate to a fixed branch
FortiSASEReported affectedCheck FG-IR-26-267
FortiManager 8.0 (CVE-2026-126261)8.0.08.0.1
FortiManager 7.67.6.0 through 7.6.77.6.8
FortiManager 7.47.4.0 through 7.4.5Sources disagree: Invitty lists 7.4.6; Red Tiger says no fix and migrate. Verify in FG-IR-26-275.
FortiManager 7.27.2.0 through 7.2.8Sources disagree: Invitty lists 7.2.9; Red Tiger says no fix and migrate. Verify in FG-IR-26-275.
FortiAnalyzerReported affected in a similar wayCheck FG-IR-26-275

Some of these fixes shipped before the advisories. Help Net Security reported on October 26, 2026 that Fortinet released security hardening updates for FortiOS, FortiManager, FortiAnalyzer, FortiMail, and FortiAuthenticator in the preceding week, and held the vulnerability details until November 10. Invitty says the November advisories correspond to those hardening builds. Fortinet's own announcement is on the Fortinet blog. An October build protects you only if it is at or above the fixed version in the table for your branch, so compare your exact build.

Fortinet's CISO noted that the fixes themselves reveal where changes were made, which makes unpatched devices easier targets as time passes. That is a good reason not to sit on a list of pending upgrades.

If you are on FortiOS 7.0, the affected range is 7.0.1 through 7.0.19 and there is no fix on that branch. Move those devices to a supported branch, and plan the maintenance window accordingly.

The rest of the batch

The OSPF and FGFM issues are the headline items, but they are not the only critical or high-severity fixes. Rescana and InfosecMonkey report additional flaws affecting BGP (including CVE-2026-126254), OFTP, SSH, and other components across FortiOS, FortiManager, FortiAnalyzer, and FortiMail. Red Tiger also lists FortiManager and FortiAnalyzer advisories such as CVE-2026-126229, rated 9.1, which lets an authenticated administrator reach other VDOMs. If you run BGP to an ISP or between sites, read that advisory alongside the OSPF one. If you run FortiMail as your mail gateway, it belongs on the same patch list; per Help Net Security, FortiMail 7.2 customers should move to the 7.4 branch or later.

Red Tiger and Invitty both say none of these flaws was known to be exploited as of November 10, and coverage through November 13, 2026 reports no confirmed exploitation in the wild. That is good news, but it is not a reason to wait. Unauthenticated, network-reachable flaws in management and routing components are exactly what attackers look for once details are public, so treat the current quiet as your patch window rather than a sign that the risk is low.

A practical order of operations

Your environment shapes the plan. A single-site clinic with one FortiGate and no FortiManager has a short list. A health system with dozens of branch firewalls, OSPF between sites, and central management has a longer one. The order below works for both.

Start with inventory. List every FortiGate, FortiManager, FortiAnalyzer, and FortiMail device, including the forgotten ones: the spare firewall at the outpatient clinic, the virtual FortiAnalyzer someone stood up for a project, and the unit your EHR hosting vendor installed in your rack. Record the exact version and branch of each.

Close exposure before you patch. Verify that FGFM and OFTP are not reachable from the internet or from untrusted internal segments, and restrict them with firewall rules or ACLs if they are. Fortinet's temporary mitigations, as reported by Help Net Security, are to limit admin access to trusted IP addresses, keep FortiManager off the internet, use strong unique credentials, and enforce MFA for admin accounts. Fortinet states these are not a substitute for upgrading. Confirm that management interfaces sit on a dedicated management segment. This step costs minutes, needs no downtime, and lowers your risk while the upgrades work through change control.

Map your OSPF footprint. Identify which FortiGates run OSPF and which interfaces participate. OSPF should be limited to links between routing devices you trust. If it is enabled on an interface facing a user, device, or guest segment, that is worth fixing regardless of this CVE.

Upgrade in priority order. Fortinet advises updating internet-facing systems first. Beyond that, do FortiManager and FortiAnalyzer early, because a compromise there reaches everything else, then FortiGates running OSPF. Back up configurations before each upgrade. If you have a lab or a low-risk branch site, use it as your first test. Coordinate maintenance windows with clinical leadership, because a firewall reboot at a site with no redundancy is a clinical systems outage, however brief. If you run FortiManager 7.4 or 7.2, check FG-IR-26-275 first to see whether a point release exists or whether you must change branches.

Keep watching. Check the FortiGuard PSIRT portal and NVD for revisions, since early advisories often get updated version ranges. Do not count on IPS signatures to cover you: Invitty reports that no virtual patch exists for the OSPF and FGFM flaws, so access restriction and upgrading are your real options.

Where HIPAA fits

No HIPAA enforcement action is tied to these advisories. The Security Rule still applies. Under 45 CFR 164.306(a)(2), covered entities and business associates must protect against reasonably anticipated threats or hazards to the security or integrity of ePHI. In our view, a published, critical, unauthenticated flaw in the firewalls that segment your clinical systems fits that description.

Two Required implementation specifications apply directly. Risk analysis under 45 CFR 164.308(a)(1)(ii)(A) calls for an accurate and thorough assessment of the potential risks and vulnerabilities to ePHI. Risk management under 45 CFR 164.308(a)(1)(ii)(B) requires security measures sufficient to reduce those risks and vulnerabilities to a reasonable and appropriate level. The access control standard at 45 CFR 164.312(a)(1) and the integrity standard at 45 CFR 164.312(c)(1) are relevant to what these devices protect as well. Under 45 CFR 164.306(e), security measures must also be reviewed and modified as needed, which is what responding to a new advisory amounts to.

In practice, document what you found in your inventory, what you restricted, when you upgraded, and why any device is still pending. If a device has to wait, record the compensating control you put in place. That record is what demonstrates a working risk management process if anyone asks later.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.

Sources

About the Author

Health Tech Authority Editorial Team

Health Tech Authority is a publication covering the technology side of health care organizations. We exist for the people in the mix - the systems administrators keeping servers online at 2 AM, the network engineers segmenting clinical VLANs on a shoestring budget, the security officers trying to hold the HIPAA line with half the resources a comparably sized non-health care organization would have, and the IT managers and administrators making technology decisions that directly affect patient care.

Content published under this account represents collaborative editorial work produced by the Health Tech Authority team. That includes original reporting, technical analysis, regulatory coverage, and practitioner-focused guidance across our core coverage areas: infrastructure and systems administration, networking, security and compliance, cloud and Microsoft 365 administration, clinical systems and health data, and the broader technology landscape serving health care organizations.

We cover what health care IT professionals actually need to know, written in a way that respects both their time and their intelligence. No fluff, no vendor press release rewrites, no thought leadership buzzword soup - just straightforward coverage of the systems, tools, and decisions that keep health care organizations running.

If you have a topic suggestion, a correction, or want to contribute, reach out through the Contact page.