FGFM elevation before registration password is verified

🚨SEVERITY: CRITICAL — CVSS 9.0Security Advisory

TL;DR 📌

  • CVSSv3 Score: 9.0 An improper authorization vulnerability in FortiManager FGFM may allow an unauthenticated attacker that can reach the FGFM port to execute code or commands via crafted FGFM packets. Revised on 2026-11-10 00:00:00
  • Highest CVSS: 9.0 (Critical).
  • Check the advisory for fixed releases — remediation detail is in the vendor link below.
  • CVEs: CVE-2026-126261.

What it is

CVE-2026-126261 is an improper authorization vulnerability in the FGFM protocol implementation on FortiManager. FGFM is the channel FortiGate devices use to register with and communicate with FortiManager; the flaw sits in the registration handshake, specifically in how FortiManager checks the registration password.

The advisory describes the issue as elevation occurring before the registration password is verified. In practice, an attacker who can reach the FGFM port does not need valid credentials: by sending crafted FGFM packets, they can execute code or commands on the FortiManager instance without first proving they hold the correct registration password.

The access path is network-based and unauthenticated. The only precondition is network reachability to the FGFM listener — no FortiManager account, no FortiGate enrolment, no prior session. Given that FGFM is the management-plane protocol tying FortiGate fleets to FortiManager, a successful attack here reaches the central point that manages those devices, not just a single firewall.

The vendor has scored this 9.0 (Critical) under CVSSv3. The advisory does not list a CVSS vector string or affected/fixed version numbers in the published detail; consult the Fortinet PSIRT advisory (FG-IR-26-275) directly for the exact builds affected and the fixed release once published.

What to do

  • Do not expose the FGFM port on FortiManager to the internet or to any untrusted network segment. Restrict it to the specific FortiGate management IP ranges that need to register.
  • Check current firewall/ACL rules in front of FortiManager for FGFM access and tighten them to a known allow-list if they are currently broad.
  • Watch the Fortinet PSIRT advisory page (FG-IR-26-275) for the fixed version and affected release list — it was not finalised at the time this item was published — and schedule an update as soon as a fixed build is confirmed.
  • Review FortiManager logs for unexpected FGFM registration attempts or connections from unfamiliar source addresses, since this is a registration-handshake flaw and anomalies would most likely appear there.
  • Treat FortiManager as a high-value target in your network segmentation: if it sits in a flat management VLAN reachable from general user networks, use this advisory as a reason to isolate it now rather than waiting for the patch.

For leadership 🧭

Executive summary. A critical flaw in FortiManager’s FGFM registration handshake lets anyone who can reach that port run commands without any valid credentials, and FortiManager is the control point for your entire FortiGate estate. Given the 9.0 severity and no authentication barrier, exposure should be checked and closed off today while a fixed build is awaited.

Why it matters:

  • The flaw sits in the FGFM registration handshake used by FortiGate devices to enrol with FortiManager, and the password check happens too late to stop an attacker
  • No FortiManager account, FortiGate enrolment or prior session is needed — only network reachability to the FGFM listener is required to execute code or commands
  • A compromise here reaches the central management plane for an entire FortiGate fleet, not just one firewall, because FGFM is the protocol tying those devices to FortiManager
  • No CVSS vector, affected versions or fixed release are yet published, so the only mitigation available right now is restricting network access to the FGFM port

Now / Next / Later:

  • Now: Check firewall and ACL rules in front of FortiManager and confirm the FGFM port is not reachable from the internet or any untrusted segment, restricting it to known FortiGate management IP ranges.
  • Next: Review FortiManager logs for FGFM registration attempts from unfamiliar source addresses, and tighten any broad allow-lists currently permitting FGFM access during the next change window.
  • Later: Move FortiManager out of any flat management VLAN into an isolated segment reachable only by authorised FortiGate management IPs, and schedule the fixed build for installation once Fortinet publishes it against FG-IR-26-275.

Source