FortiManager's FortiJump patch is the start of the job, not the end

If you ran a FortiManager any time between June and October 2024, the patch is the easy part. The hard part is figuring out what left the building before you applied it.

CVE-2024-47575, branded “FortiJump,” is a missing-authentication flaw in FortiManager’s fgfmd daemon that rates CVSS 9.8. The short version: the daemon that managed FortiGate firewalls use to phone home, listening on TCP/541, didn’t properly authenticate device registration. Any device with a valid Fortinet certificate, including one an attacker bought, could register itself as managed and start running commands on the FortiManager. Mandiant’s investigation tracked exploitation back to June 27, 2024, roughly 119 days before Fortinet’s public advisory landed on October 23.

That gap is the whole problem. Your patch window closes a door that was open for four months.

What this means for your environment

FortiManager is the management plane for your FortiGate estate. It holds the authoritative config for every device it manages, pushes policy, and stores credentials. When an attacker owns FortiManager, here is what they walk away with, per Mandiant’s write-up:

• Full firewall configs for every managed FortiGate: rules, VPN settings, NAT, IPS sensors. A complete map of your perimeter.
• FortiOS256-hashed passwords for the admin accounts on those devices.
• Serial numbers, IP addresses, and version info for the whole managed fleet.

The exfiltration was real, not theoretical. Mandiant observed a rogue device registered as “Purity Supreme” collect configuration files and ship them out as a compressed archive over HTTPS. The first run, on June 27, moved about 1.8 MB to an external IP. A second pull followed on September 23. By disclosure, roughly 50 or more FortiManager appliances across multiple industries had been potentially compromised.

Here is the operational catch, and it’s the reason this post exists. Patching stops new exploitation. It does not undo a compromise that already happened. If an attacker reached your FortiManager before you applied the fix, they have your configs and your password hashes right now, and those hashes give them a path straight to individual FortiGates that does not run through FortiManager at all. You can patch the management plane and still have an attacker holding keys to the devices underneath it.

Mandiant did not observe lateral movement or pushed config changes in the incidents it investigated, and it found no malware left behind. That is genuinely reassuring, but read it for what it is: the limit of what was visible in those specific cases, not a clean bill of health for everyone. The same report flagged that the exfiltrated data could be used to move laterally and target the broader environment.

What you need to do

Patch first, because the workarounds are stopgaps, not fixes. Get to a fixed build:

Branch	Patch to
7.6.x	7.6.1 or later
7.4.x	7.4.5 or later
7.2.x	7.2.8 or later
7.0.x	7.0.13 or later
6.4.x	6.4.15 or later
6.2.x	6.2.13 or later

If you cannot patch in the next maintenance window, Fortinet’s advisory gives two workarounds. On 7.0.12+, 7.2.5+, or 7.4.3+ you can block unknown device registration with config system global / set fgfm-deny-unknown enable. One trap worth calling out: that command does not exist on 7.6.0. If you are on 7.6.0 and stuck, your only option until you reach 7.6.1 is the local-in-policy allowlist that restricts TCP/541 to your known FortiGate IPs.

The part most teams skip is the assessment, and it’s the part that matters most here. Patching is a one-evening change. Deciding whether you were breached, and acting on it, is the real work:

• Pull your FortiManager logs back to at least June 27, 2024. That’s Mandiant’s first-observed exploitation date. Cross-reference against the indicators of compromise CISA published following the advisory. Look for device registrations you don’t recognize and outbound transfers to unfamiliar IPs on 443.
• Rotate admin credentials on every managed FortiGate. If the hashes left your network, the only safe assumption is they’re being cracked offline. Rotating on FortiManager alone is not enough; the credentials live on the individual devices, and that’s where an attacker would use them.
• Audit configs and VPN accounts on the managed fleet for changes you didn’t make and accounts you didn’t create.

If you came through the incident clean, that’s a few hours of log review and a credential rotation you were probably overdue for anyway. If you didn’t, you want to know now, not after someone logs into a FortiGate with a cracked admin hash.

The window

The deadline math is unusual here. With a normal critical, the urgency is “patch before someone exploits it.” With FortiJump, the exploitation predates your patch by four months, so the window you’re racing isn’t “before the attack.” It already happened. The window now is the lag between an attacker cracking your exfiltrated hashes and you rotating the credentials they’re attacking.

That reframes the priority. The patch can ride your normal change process since the fix is stable and the build path is clean. The credential rotation should not wait for it. If the configs and hashes left your network in 2024, every day those credentials stay valid is a day an attacker has to put them to use. Rotate first, patch on schedule, and treat the log review as a finding that either closes the book or opens a real incident.

This is the kind of advisory where the CVSS score undersells the work. A 9.8 tells you to patch. It doesn’t tell you that the patch is step one of three, and that the other two land on the FortiGates, not the FortiManager. We track the daily CVE flow at PatchDayAlert so the ones that carry this kind of downstream tail don’t get filed under “patched, done” when they aren’t.

Sources

• Missing authentication in fgfmd — Fortinet PSIRT FG-IR-24-423 — 2024-10-23
• Investigating FortiManager Zero-Day Exploitation (CVE-2024-47575) — Google Cloud Blog / Mandiant — 2024-10-23
• Mandiant says new Fortinet flaw has been exploited since June — BleepingComputer — 2024-10-23
• Fortinet Updates Guidance and Indicators of Compromise following FortiManager Vulnerability Exploitation — CISA — 2024-10-30