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.
Management-plane compromise at fleet-manager scale
The FortiManager zero-day (CVE-2024-47575, FortiJump — exploited by state-linked actors to compromise the central management platform for fleets of Fortinet devices) delivered the edge canon its control-plane chapter: not the appliances this time but the thing that manages them, the concentration point whose compromise yields configuration access to every device it administers. The RMM cascade doctrine at network-infrastructure scale — the management of management as the highest-value target in the estate.
The doctrine items consolidated: fleet managers are tier-0 singularities (their compromise converts to fleet-wide configuration access — exposure restriction, emergency patch clocks, and session monitoring at the same standard as identity providers, the edge doctrine pointed upward), CISA escalation followed the criticality logic (the added-to-KEV-and-directives treatment marking the class as federal-emergency tier), and the post-compromise scope question is the fleet (any device managed during the exposure window inherits the audit — configuration review, credential rotation, persistence hunting, at fleet scale, the rotation-map doctrine at its most extensive).
The consolidation: the entry completes the edge canon vertical stack — appliance, session plane, and now the manager — and the doctrine holds symmetric at every level: whatever concentrates administration of many things deserves the strongest protection in the estate, because its compromise is arithmetic multiplication. The attackers priced the manager before the defenders did, which is the genre oldest pattern; the record exists so the next tier (identity managers, orchestration planes, agent fleets) gets priced by its readers first.
The fleet-scoping worksheet that the response created deserves standard-form status: for any manager-plane compromise, the exposure window times managed devices times configuration-change surface equals the audit population, and the worksheet (exported management logs, per-device change review, credential rotation for anything the manager stored) converts the overwhelming into the schedulable. The organizations that built the worksheet during this incident completed fleet audits in weeks; the ones that modeled the scope as per-device incidents are still counting. The manager genre will recur at the next tier up; the worksheet transfers; the arithmetic holds at every altitude.
The closing altitude lesson, stated once and applied everywhere: in any stack, the layer that administers many things outranks the things it administers as a target, by exactly the multiplication factor of the fleet. Attackers price the multiplication before defenders do because multiplication is their business model; the record teaches defenders to price it first, protect the manager as the crown jewel it functionally is, and read every acquisition and architecture decision through the question: what does this component administer, and what would its compromise multiply into? The genre record is the multiplication table, written in incidents; the worksheet is the homework; the exam is scheduled by adversaries.
Related Reading
- What Studying 33 Historic Cyberattacks Taught Me About Defending Systems Today
- Passwordless in 2026: Why Passkeys Are Finally Killing the Password (and How Attackers Are Adapting)
- 2022–2024: Lapsus$, Change Healthcare & the XZ Backdoor
- Authoritative reference: CISA Known Exploited Vulnerabilities
- PAN-OS GlobalProtect Zero-Day: CVE-2024-3400 Explained
- Internet Explorer CVE-2020-0674: The Zero-Day Advisory That Opened 202
- Pulse Secure VPN Zero-Days: When Remote Access Became the Front Door
