What happened?
On 23 October 2024, Fortinet confirmed a critical zero-day in FortiManager – CVE-2024-47575, CVSS 9.8 – weaponized in the wild. The management plane that was supposed to watch the fleet became the entry point: unauthenticated remote code execution via a missing authentication check on a FortiGate communication protocol, actively exploited since at least early autumn. When this post publishes on 26 October 2024, CISA has added the CVE to the KEV catalog with a aggressive patch deadline, Mandiant has attributed the exploitation to a China-nexus actor tracked as UNC5850, and ata ICS-style triage is underway across thousands of exposed FortiManager instances.
Quick Answer: CVE-2024-47575 is a critical unauthenticated RCE in FortiManager – the central management platform for Fortinet fleets – caused by a missing authentication check in the FortiGate-to-FortiManager (FGFM) protocol. An attacker who can reach the FortiManager executes arbitrary code and gets full control of the management plane, from which they push malicious configs to every managed device. Fortinet patched on 23 October 2024 (7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15); CISA added it to KEV the same week with removal-by deadlines. Mandiant attributed activity to UNC5850 (China-nexus), using a custom implant named DeepMove. The name FortiJump – the community label for the management-plane hop – stuck.
A compromise of FortiManager is a compromise of every depth behind it. FortiManager stores device credentials for the fleets it manages, executes config pushes, and hosts global policy objects. An attacker with FortiManager code execution harvests those credentials, exfiltrates configs – IPsec keys, SSL-VPN settings, internal topology – and can push changes to hundreds of FortiGates in one motion. That is why the response tempo was KEV-speed: this is not a perimeter zero-day, it is the CNS of many defense architectures, and its compromise converts each managed device into a staged asset.
The protocol bug, mechanically
FortiManager speaks FGFM to its FortiGates on TCP 541/tcp by design. The vulnerability is that under certain conditions the daemon serving that protocol failed to demand credentials before executing management operations – a missing-authentication flaw in a trusted-inner-protocol path. Any host that can reach the port and speak the protocol can register as a FortiGate or issue requests; pre-2021 instances and misconfigured ones that expose 541/tcp to untrusted networks were fully exposed. Exploitation leaves surgical forensics: short bursts of FGFM traffic, custom implants (DeepMove) placed for persistence, configs staged for exfiltration, and – in the most aggressive variant – malicious policy packages pushed outward to managed devices. The bug class is the oldest one in the book: trusted-channel-auth gap on a management plane.
The paper trail
| Date | Event |
|---|---|
| 2024-06→08 | Observed intrusion activity against FortiManager instances; attacker uses stolen or missing-auth paths to stage implants |
| 2024-09 | Mandiant engages incident response at multiple victims; tracks actor as UNC5850; custom implant DeepMove identified |
| 2024-10-23 | Fortinet releases out-of-cycle PSIRT advisory and patches for CVE-2024-47575; migration guidance published; CISA adds to KEV |
| 2024-10-24→25 | KEV deadlines set – patch within roughly two weeks for federal civilian agencies; industry-wide triage of exposed instances begins |
| 2024-10-26 | This post publishes amid the second wave of analysis; ransomware-adjacent scanners begin probing for unpatched 541/tcp |
Triage math for the defense
Three questions dominated the response. First, exposure: does anything route 541/tcp or the FortiManager web UI to untrusted networks? The answer across far too many orgs was yes – either deliberately for multi-site management or accidentally via lazy NAT rules; each yes is a now-expired concession. Second, evidence: because exploitation is quiet, absence of alerts proves nothing – FGFM logs, config-push history, and implant artifacts (DeepMove files, unexpected CLI audit entries) must be checked directly, and any suspicious period overlaps the June-October activity window. Third, blast radius: credentials and configs stored on FortiManager must be rotated as if exfiltrated – device admin accounts, IPsec PSKs, SSL-VPN user definitions – because the attacker’s dwell time is unknown. Orgs that answered the three questions with artifacts, not assumptions, finished their triage in days; the rest are still guessing.
Why management planes keep falling
The pattern by late 2024 was unmistakable: Citrix, Ivanti, PAN-OS, F5, Now FortiManager. Every major network-infrastructure vendor has now shipped a management-plane zero-day, and the attackers’ economics explain why – one management server concentrates credentials, topology, and config-push authority for an entire estate, giving the best ratio of effort to access in the target list. Vendors respond with hardening programs and the defenders’ countermeasure is architectural: management planes belong on isolated networks with layered access paths (jump hosts, no direct internet exposure, no shared credentials), because “patch the mgmt plane within 14 days” is a policy that fails every time the plane is already the beachhead. FortiJump will not be the last hop of its kind; it is simply the most recent reminder that the control plane is the crown-jewel target.
- Inventory your management planes: every FortiManager, vCenter, SCCM, and domain controller with direct exposure is a FortiJump waiting to happen.
- Patch SLAs for mgmt planes must be days: KEV deadlines anchor compliance, but exploit timelines run weeks earlier.
- Rotate what the plane stores: after any suspected compromise, device credentials and VPN PSKs are the exfil prize – rotate them all.
- Assume quiet: missing alerts is not evidence of absence; hunt artifacts explicitly (FGFM anomalies, unknown implants, config-push diffs).
FAQ
What is FortiJump exactly?
“FortiJump” is the community/Mandiant-ecosystem label for exploitation of CVE-2024-47575 – specifically the zero-click hop from an exposed FortiManager into full management-plane control, then optionally outward to managed FortiGates via pushed configs. The name captures the essential motion: attacker lands on the manager, jumps to the fleet.
My FortiManager is not internet-facing. Am I safe?
Likely, from this CVE – the observed exploitation required reachability of the FGFM protocol or the exploits path. But “not internet-facing” must be verified, not assumed: audit NAT rules, management VPNs that terminate on the firewall itself, third-party monitoring integrations, and any path from DMZ to mgmt VLAN. Several victims discovered their “isolated” manager was reachable through a forgotten site-to-site tunnel. Isolation is a property you continuously test, not a box checked at install.
What is DeepMove?
A custom backdoor associated with UNC5850 activity, named by Mandiant, used for persistence on compromised FortiManagers. Custom malware on an appliance OS is particularly nasty: few orgs have file-integrity baselines for FortiManager images, so the implant blended into an environment nobody images forensically.IOCs and YARA coverage were distributed through Mandiant and Fortinet advisories.
Legacy: the year the management plane got jumped
FortiManager 2024 closed the arc that PAN-OS, Ivanti, and Citrix had opened: perimeter management infrastructure is now attacker-primary target category, not an afterthought. The orgs that absorbed the episode well did three things: they mapped where authority concentrates (credentials, push capability) and treated those systems to crown-jewel controls; they rehearsed appliance forensics before needing them; and they logged config pushes as high-signal telemetry, so the next manager-side anomalous push will page a human at 2 a.m. instead of silently propagating. The lesson compresses to a sentence the industry keeps re-learning: whoever owns the management plane owns the fleet – and in 2024, someone finally jumped it at scale.
