Wearing Someone Else's Certificate: CVE-2026-70468 and FortiManager's FGFM Trust Model

The bug in one sentence

If a FortiManager has the CLI option fgfm-peercert-withoutsn enabled, an attacker who holds any valid FGFM certificate, not necessarily one issued for the device they’re pretending to be, can send a crafted FGFM request and have FortiManager treat them as any FortiGate it manages. Fortinet published the advisory (FG-IR-26-160) on August 12, tracked as CVE-2026-70468, alongside a separate FortiWeb authentication bypass published the same day.

What FGFM actually is

FortiGate to FortiManager Protocol, FGFM, is the channel a FortiGate uses to register with its FortiManager, receive configuration pushes, and report status back. Trust on that channel is certificate-based: each managed FortiGate presents a certificate during the FGFM handshake, and FortiManager is supposed to verify that the certificate belongs to the specific device claiming to use it, tying the certificate to that device’s serial number. That serial-number binding is the part this bug breaks.

fgfm-peercert-withoutsn is a CLI-only setting, not something surfaced in the GUI, which already tells you something about how it gets left on: it’s the kind of option that gets set once for a specific reason (some certificate provisioning workflows don’t cleanly carry the serial number, and this option exists to work around that) and then forgotten. With it enabled, FortiManager’s certificate check stops confirming that the presented certificate’s serial number matches the device presenting it. Any certificate that’s otherwise valid is accepted, without confirming which device it was actually issued for.

Severity, affected versions, fix

Fortinet rates this CVE-2026-70468, CWE-288 (Authentication Bypass Using an Alternate Path or Channel), CVSS 3.1 base score 7.3. The vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) is worth reading directly: network-exploitable, no privileges or user interaction required, but high attack complexity, since the attacker still needs a valid certificate to begin with. Fortinet’s own severity language calls the attack type “unauthenticated” and lists it as internally discovered, not currently known to be exploited.

Product	Affected	Fixed
FortiManager 7.6	7.6.1	7.6.2 or later
FortiManager 7.4	7.4.3 – 7.4.5	7.4.6 or later
FortiManager 7.2	7.2.5 – 7.2.9	7.2.10 or later
FortiManager Cloud	same ranges as above	same fixed versions as above
FortiManager 8.0	not affected	—

Unlike this week’s Cisco ASA/FTD DoS, this one does have a real workaround, and it’s a single command:

config system global
    set fgfm-peercert-withoutsn disable
end

If you’re not sure why that option would be enabled on your FortiManager in the first place, that’s worth an audit on its own. It’s not a default-on setting, someone turned it on, and the advisory itself is effectively telling you the reason it existed no longer holds up against how it can be abused.

Why impersonating a managed device matters here

It’s easy to read “impersonate a FortiGate” and picture the wrong direction of attack. FGFM impersonation doesn’t hand an attacker control of the real FortiGate that owns that identity, the physical or virtual device keeps running its own configuration regardless. What it does is let the attacker’s own endpoint present itself to FortiManager as that device: register, report fabricated status, and potentially receive whatever configuration data FortiManager pushes to devices in that role. In an environment using Administrative Domains to segment tenants or sites, or centralized policy push across a fleet the way the FortiManager lab series walks through building, that’s a meaningful blast radius: an attacker who can pass as a trusted managed device sits inside the management plane’s trust boundary, not outside it.

That’s the same shape of concern this site keeps coming back to with VDOMs and MSSP-style multi-tenant designs: a management platform that’s trusted by many downstream devices is only as strong as its weakest trust check, and a serial-number binding that silently stops being enforced is exactly the kind of check that looks fine in a config review and fails only when someone deliberately goes looking for the gap. The fix here is cheap. Finding out you needed it is the harder part, which is the actual argument for treating a CLI-only, GUI-invisible auth-relevant setting like this one as something worth grepping for across a fleet rather than assuming nobody touched it.