No fluff. Just the config that works.

Fortinet’s November 10, 2026 PSIRT release dropped 88 advisories in one day. Most of the FortiAnalyzer and FortiManager bugs need an authenticated admin, and the standard advice covers them: lock the GUI down with trusted hosts, keep management off the internet, patch. This post is about the ones that advice does not touch. These are the Fortinet PSIRT countermeasures for pre-auth bugs on FortiGate, FortiManager and FortiAnalyzer that live on services that have to stay reachable for the product to work: FGFM, OFTP, OSPF, HA sync, the WAD proxy, SSL-VPN web mode and RADIUS.  NOTE: THE RECOMMENDATION IS TO APPLY THE PATCHES

Executive Summary

Why Trusted Hosts Don’t Help Here

Trusted hosts and admin profile restrictions control who can log in to the HTTPS GUI and SSH. They do nothing for the service planes a Fortinet deployment depends on. A FortiManager has to accept FGFM on TCP 541 from every FortiGate it manages. A FortiAnalyzer has to accept OFTP on TCP 514 from every log source. OSPF has to talk to neighbors, FGSP peers have to sync, and an access proxy has to answer clients. When the bug sits in one of those daemons, the fix is network scoping, feature reduction, virtual patching and then the upgrade.

Which Advisories Need Fortinet PSIRT Countermeasures

These are the pre-auth (or near pre-auth) advisories from the November 10 release that hit a service you can’t simply hide behind the management plane. Fixed versions are taken from each advisory.

Out of scope: lock the console down and patch

These are pre-auth or low privilege, but they live on the admin GUI, the JSON-RPC API or SSH. Restricting the management plane is the right control, so they are not covered step by step here.

Prerequisites and Architecture

Assumed knowledge: FortiOS CLI, FortiManager and FortiAnalyzer CLI, local-in policies, VIPs, IPsec, OSPF and FGSP basics.

Lab addressing used in every example below: 198.18.0.0/15 for public and transit, 10.0.0.0/16 for internal LANs. Swap in your own values.

Part A: FortiManager and FortiAnalyzer

Step 1: Find out what is actually exposed

Goal: Confirm whether FGFM (541) and OFTP (514) answer from the internet or from networks that have no business reaching them.

Action: Scan from an outside host, then check which FMG and FAZ interfaces offer FGFM.

# From a host outside your network
nmap -Pn -sT -p 541,514 198.18.0.10 198.18.0.11

# On the FortiManager / FortiAnalyzer CLI
get system status
show system interface

GUI Verification: On FMG, go to System Settings > Network and check the Administrative Access column for each port. Any port listing FGFM that does not face FortiGates is attack surface for FG-IR-26-275.

Step 2: Move FGFM and OFTP into IPsec (best fix)

Goal: Take 541 and 514 off the internet entirely, so FG-IR-26-275, 276 and 274 can only be reached from inside a tunnel.

Action: Point each branch FortiGate at the private FMG and FAZ addresses through its existing hub tunnel, then delete the public VIPs.

config system central-management
    set type fortimanager
    set fmg "10.0.10.10"
    set fmg-source-ip "10.0.200.1"
end
config log fortianalyzer setting
    set status enable
    set server "10.0.10.20"
    set source-ip "10.0.200.1"
end

Make sure the hub has routes and firewall policies for 10.0.10.10 and 10.0.10.20 from the tunnel. This also fixes the dynamic-IP problem: branches on DHCP or LTE WANs can’t be allowlisted by source IP, but they can always come in over the tunnel.

GUI Verification: In FMG Device Manager, every device should stay online with its connecting IP now showing the tunnel source address. In FAZ Device Manager, logs keep arriving from the same devices.

Step 3: If 541 and 514 must stay public, allowlist them at the edge

Goal: Only known FortiGate WAN addresses can reach FGFM and OFTP.

Action: Add a source filter to each VIP and a matching policy on the DC edge FortiGate.

config firewall address
    edit "BR-ATL-WAN"
        set subnet 198.18.10.1 255.255.255.255
    next
    edit "BR-MIA-WAN"
        set subnet 198.18.20.1 255.255.255.255
    next
end
config firewall addrgrp
    edit "MANAGED-FGT-WAN"
        set member "BR-ATL-WAN" "BR-MIA-WAN"
    next
end
config firewall service custom
    edit "FGFM-541"
        set tcp-portrange 541
    next
    edit "OFTP-514"
        set tcp-portrange 514
    next
end
config firewall vip
    edit "VIP-FMG-FGFM"
        set extip 198.18.0.10
        set mappedip "10.0.10.10"
        set extintf "wan1"
        set portforward enable
        set extport 541
        set mappedport 541
        set src-filter "198.18.10.1/32" "198.18.20.1/32"
    next
    edit "VIP-FAZ-OFTP"
        set extip 198.18.0.11
        set mappedip "10.0.10.20"
        set extintf "wan1"
        set portforward enable
        set extport 514
        set mappedport 514
        set src-filter "198.18.10.1/32" "198.18.20.1/32"
    next
end
config firewall policy
    edit 0
        set name "FGT-to-FMG-FAZ"
        set srcintf "wan1"
        set dstintf "dc-mgmt"
        set srcaddr "MANAGED-FGT-WAN"
        set dstaddr "VIP-FMG-FGFM" "VIP-FAZ-OFTP"
        set action accept
        set schedule "always"
        set service "FGFM-541" "OFTP-514"
        set logtraffic all
    next
end

GUI Verification: Policy & Objects > Firewall Policy shows hits only from the allowlisted sources, and Log & Report > Forward Traffic shows denies from everyone else.

Step 4: Add a local-in policy on FMG and FAZ

Goal: A second layer on the appliance itself, in case the edge rule is ever loosened.

Action: Allow 541 and 514 only from the tunnel range and known WAN addresses, then reject the rest. Local-in policies are available on FMG and FAZ 7.2.2 and later. Check the field names on your build with set ? before pasting.

config system local-in-policy
    edit 1
        set action accept
        set intf "port1"
        set protocol tcp
        set dport 541
        set src 10.0.200.0 255.255.255.0
    next
    edit 2
        set action accept
        set intf "port1"
        set protocol tcp
        set dport 514
        set src 10.0.200.0 255.255.255.0
    next
    edit 3
        set action reject
        set intf "port1"
        set protocol tcp
        set dport 541
    next
    edit 4
        set action reject
        set intf "port1"
        set protocol tcp
        set dport 514
    next
end

GUI Verification: Re-run the scan from Step 1 from a host outside the allowed range. Both ports should show as filtered or closed.

Step 5: Shrink the FortiManager attack surface

Goal: Close daemons and ports you don’t use.

Action: Turn off the FAZ feature set on FMG if you don’t log to it, remove FGFM from ports that don’t face FortiGates, and add the FortiJump-era registration hardening.

# FMG only: disable FortiAnalyzer features if unused (the unit reboots)
config system global
    set faz-status disable
end

# Remove fgfm from interfaces that don't face managed FortiGates
config system interface
    edit "port2"
        set allowaccess ping https ssh
    next
end

# Defense in depth: refuse registration from unknown serial numbers
config system global
    set fgfm-deny-unknown enable
end

faz-status disable removes the “FMG with FortiAnalyzer features” condition from FG-IR-26-276 and FG-IR-26-274. Confirm 514 is closed with a scan afterwards.

Step 6: Protect the HA and RADIUS paths (FG-IR-26-229, FG-IR-26-247)

Goal: Keep spoofed fortilogd traffic and RADIUS man-in-the-middle attempts off the paths FMG and FAZ use.

Action: These two have no CLI workaround. They are path problems, so the countermeasure is where the traffic flows.

• Put FAZ and FMG HA heartbeat and sync on a dedicated, non-routed segment or a direct cable.
• Apply the Step 3 and Step 4 scoping to the log ports, so only known devices can send fortilogd traffic at all.
• Keep RADIUS between FMG or FAZ and the RADIUS server on a management VLAN or inside IPsec, never across an untrusted segment.
• Keep one local break-glass super admin with a strong password and trusted hosts, so you can still get in if RADIUS has to be disabled.

Part B: FortiGate (FortiOS)

Step 7: Enable virtual patching on local-in traffic

Goal: Get the IPS virtual patch signatures Fortinet published for FG-IR-26-273 (FG-VD-61445.0day, virtual patch DB 26.082) and FG-IR-26-270 (FG-VD-62355.0day, DB 26.100) inspecting traffic aimed at the FortiGate itself.

Action: Confirm the virtual patch database is current, then add a local-in policy with virtual patching on the WAN and sync interfaces. This is a FortiOS 7.4 and later feature. If set virtual-patch is not offered, your build does not support it.

diagnose autoupdate versions | grep -A5 -i virtual

config firewall local-in-policy
    edit 0
        set intf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set service "ALL"
        set schedule "always"
        set virtual-patch enable
    next
end

This matters most for FG-IR-26-270 on 7.4 and 7.2, which have no fixed release. The virtual patch is the only compensating control Fortinet lists until you move to 7.6.8 or 8.0.2.

GUI Verification: System > FortiGuard shows the virtual patch signature package with a recent version, and Log & Report > Security Events will show virtual patch hits if anything is caught.

Step 8: Lock down FGSP config sync and autoscale (FG-IR-26-273)

Goal: Make sure nobody but the real peer can send HA packets to the FortiGate.

Action: Check whether the vulnerable features are on, turn them off if they’re not needed, otherwise pin the sync interface to the peer.

show system ha | grep standalone-config-sync
show system standalone-cluster

# Not using FGSP config sync? Turn it off
config system ha
    set standalone-config-sync disable
end

If you need it, isolate the sync interface. Use a direct cable or a VLAN that is never routed, then allow only the peer on that interface:

config firewall address
    edit "FGSP-PEER"
        set subnet 10.0.250.2 255.255.255.255
    next
end
config firewall local-in-policy
    edit 0
        set intf "port10"
        set srcaddr "FGSP-PEER"
        set dstaddr "all"
        set action accept
        set service "ALL"
        set schedule "always"
    next
    edit 0
        set intf "port10"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "ALL"
        set schedule "always"
    next
end

• If your build offers set encryption enable and set psksecret under config system standalone-cluster, turn encryption on. Fortinet doesn’t list it as a workaround, but it makes forged sync traffic harder.
• Autoscale in AWS, Azure or GCP: lock the security group or NSG on the sync NIC to the autoscale peer subnet only.
• Add port10 to the virtual patch local-in policy from Step 7.

GUI Verification: System > HA still shows the peer in sync, and the deny rule’s hit counter only climbs when something other than the peer talks to that port.

Step 9: Contain OSPF route injection (FG-IR-26-267)

Goal: Limit where a forged LSA can come from and what it can do once it lands.

Action: Make every interface passive unless it has a real neighbor, allow OSPF (IP protocol 89) only from known neighbors, and filter what OSPF can install.

config router ospf
    set passive-interface "port4" "port5" "guest-vlan" "dmz"
end

config firewall service custom
    edit "OSPF-89"
        set protocol IP
        set protocol-number 89
    next
end
config firewall address
    edit "OSPF-NBR-CORE"
        set subnet 10.0.1.2 255.255.255.255
    next
end
config firewall local-in-policy
    edit 0
        set intf "port3"
        set srcaddr "OSPF-NBR-CORE"
        set dstaddr "all"
        set action accept
        set service "OSPF-89"
        set schedule "always"
    next
    edit 0
        set intf "port3"
        set srcaddr "all"
        set dstaddr "all"
        set action deny
        set service "OSPF-89"
        set schedule "always"
    next
end

config router access-list
    edit "OSPF-IN-FILTER"
        config rule
            edit 1
                set action deny
                set prefix 0.0.0.0 0.0.0.0
                set exact-match enable
            next
            edit 2
                set action permit
                set prefix 10.0.0.0 255.255.0.0
            next
        end
    next
end
config router ospf
    set distribute-list-in "OSPF-IN-FILTER"
end

Highest risk: OSPF running over IPsec to partners or untrusted sites, and guest, DMZ or lab VLANs that ended up in a network statement. Fix those first. The access list above is an example. Build yours from the prefixes each area should legitimately send.

GUI Verification: Dashboard > Network > Routing (or get router info ospf neighbor) still shows FULL adjacencies, and get router info ospf database brief lists only advertising routers you recognize.

Step 10: Scope the WAD proxy (FG-IR-26-272)

Goal: Keep crash packets away from the explicit proxy and ZTNA access proxy.

Action: Only 7.6.7 and 8.0.0 are affected and the impact is a crash, so this is lower priority. Make sure the explicit proxy only listens on internal interfaces, and restrict who can reach an access proxy VIP.

config system interface
    edit "wan1"
        set explicit-web-proxy disable
    next
end

For ZTNA access proxies that have to face the internet, set the proxy policy source to geography or Internet Service Database objects that match where your users really are, rather than all.

Step 11: Close the SSL-VPN web mode gap (FG-IR-26-193)

Goal: Stop the web portal from silently proxying to backend sites with bad certificates.

Action: Before the upgrade, turn off web mode on portals that don’t need it. After upgrading to 7.6.5, 7.4.10 or 7.2.14, change certificate checking from warn to reject.

# Before the upgrade, on portals that don't need web mode
config vpn ssl web portal
    edit "full-access"
        set web-mode disable
    next
end

# After the upgrade
config vpn ssl settings
    set remote-https-cert-check reject-on-error
end

The fixed builds default to warn-on-error, so patching alone does not close the issue. The setting change is part of the fix.

Verification and Validation

Troubleshooting and Gotchas

1. Branch FortiGates drop off FortiManager after the allowlist

Cause: The branch WAN address changed (DHCP, LTE, a new ISP) and is no longer in src-filter or the address group.

Diagnose: Run the FGFM debug on the branch and watch for connection failures.

diagnose debug application fgfmd -1
diagnose debug enable
# reproduce, then stop
diagnose debug disable
diagnose debug reset

Fix: Move that site to the IPsec design in Step 2 instead of chasing its public IP.

2. OSPF adjacencies drop after the local-in deny

Cause: Hellos arrive from an interface address you didn’t allow, often after a neighbor change or on a multi-access segment with several routers.

Diagnose:

diagnose sniffer packet port3 'proto 89' 4 10

Fix: Add every legitimate neighbor interface address to the allow rule. Apply the deny in a maintenance window the first time.

3. Virtual patching shows no updates or no hits

Cause: No entitlement for the virtual patch service, FortiGuard can’t be reached, or the build doesn’t support local-in virtual patching.

execute update-now
diagnose autoupdate versions | grep -A5 -i virtual
diagnose debug rating

Fix: Check the license under System > FortiGuard. If the build doesn’t offer set virtual-patch, the scoping in Steps 8 and 9 and the upgrade are your controls.

The Real Fix: Upgrade Targets

Use the Fortinet upgrade path tool before jumping trains, and upgrade FortiManager and FortiAnalyzer before the FortiGates they manage.

Sources

• FortiGuard PSIRT advisories index
• FG-IR-26-275: FGFM elevation before registration password is verified (CVE-2026-126261)
• FG-IR-26-276: SQL injection over OFTP in FortiAnalyzer and FortiManager (CVE-2026-126262)
• FG-IR-26-274: Pre-auth SSRF over OFTP (CVE-2026-126260)
• FG-IR-26-229: Authentication bypass by spoofing in fortilogd (CVE-2026-126184)
• FG-IR-26-247: Improper certificate validation in RADIUS protocol (CVE-2026-126232)
• FG-IR-26-273: Unauthenticated adjacent command execution via HA (CVE-2026-126259)
• FG-IR-26-267: Authentication bypass by primary weakness in ospfd (CVE-2026-126253)
• FG-IR-26-270: Out-of-bounds read in kernel (CVE-2026-126256)
• FG-IR-26-272: Stack buffer overflow in WAD (CVE-2026-126258)
• FG-IR-26-193: SSLVPN improper certificate validation (CVE-2026-121528)
• FG-IR-26-219: JSON injection in JRPC API (CVE-2026-126170)
• FG-IR-26-222: XML injection in SAML (CVE-2026-126176, CVE-2026-126177)
• FG-IR-26-269: SSH daemon path traversal authentication bypass (CVE-2026-126255)
• FG-IR-26-226: Use of hard-coded credentials in FortiManager cloud orchestration (CVE-2026-126181)
• FG-IR-26-268: Numeric truncation error in bgpd (CVE-2026-126254)