CVE-2024-47575 · FortiManager fgfmd Missing Authentication Remote Code Execution…

01 · The Real Story

Leaving the master keyring on the front porch with a neon sign saying 'HELP YOURSELF'

CVE-2024-47575, dubbed FortiJump, is a missing-authentication vulnerability in the fgfmd daemon — the service that handles the FortiGate-to-FortiManager (FGFM) protocol on TCP port 541. An unauthenticated remote attacker can send specially crafted requests to this service and achieve arbitrary code execution as root. Affected versions span nearly the entire supported lineup: FortiManager 6.2.0–6.2.12, 6.4.0–6.4.14, 7.0.0–7.0.12, 7.2.0–7.2.7, 7.4.0–7.4.4, and 7.6.0, plus FortiManager Cloud 7.0.1–7.0.12, 7.2.1–7.2.7, and 7.4.1–7.4.4. Exploitation was observed in the wild as early as June 27, 2024 — nearly four months before public disclosure on October 23, 2024.

Fortinet's vendor severity of CRITICAL / 9.8 is fully warranted and, if anything, understates the operational blast radius. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) accurately reflects the zero-click, unauth, network-reachable, root-level impact. FortiManager is not a workstation or a commodity server — it is the central nervous system of a Fortinet deployment. Compromise yields the IP addresses, configuration files, firewall policies, VPN secrets, and FortiOS256-hashed credentials of every managed FortiGate. In the UNC5820 campaign tracked by Mandiant, attackers automated mass exfiltration of exactly this data from 50+ FortiManager instances across multiple industries. The vendor score matches reality.

"FortiJump gives unauthenticated root on the appliance that holds the keys to your entire firewall fleet."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach the FGFM listener

The attacker identifies a FortiManager instance with TCP port 541 (FGFM) reachable. Shodan shows ~60,000 internet-facing FortiManager devices; Censys identified 4,081 exposed admin portals, ~86% on the default FGFM port. Even internally, any host with route to the management VLAN can reach port 541.

Conditions required:

Network path to FortiManager on TCP/541

Where this breaks in practice:

Well-segmented environments restrict 541 to known FortiGate IPs only
Some deployments use custom certificates that raise the bar for spoofing the FGFM handshake

Detection/coverage: Shodan/Censys/FOFA scans detect exposed instances. GreyNoise tags available for FortiManager scanning activity.

STEP 02

Exploit missing authentication in fgfmd

The attacker sends a specially crafted FGFM request. Because the fgfmd daemon lacks authentication for the critical management function, no credentials, tokens, or certificates are required. The public watchTowr PoC (CVE-2024-47575.py by Sina Kheirkhah) provides both check and exploit modes. A nuclei template is also available in projectdiscovery/nuclei-templates.

Conditions required:

Vulnerable FortiManager version (virtually all pre-patch versions)

Where this breaks in practice:

The fgfm-deny-unknown enable workaround blocks connections from unregistered serial numbers — but only available on 7.0.12+, 7.2.5+, 7.4.3+
Custom certificate enforcement (7.2.2+) prevents unauthenticated FGFM sessions

Detection/coverage: FortiManager logs show Unregistered device localhost add succeeded entries. Check for rogue serial numbers (e.g., FMG-VMTM23017412) in /fds/data/unreg_devices.txt.

STEP 03

Achieve root-level code execution

The crafted request triggers command injection in fgfmd, executing attacker-supplied commands as root on the FortiManager appliance. This gives full control of the management plane — file system access, database queries, and the ability to modify managed device configurations.

Conditions required:

Successful exploitation from Step 2

Where this breaks in practice:

None — exploitation is reliable and version-independent once the request reaches fgfmd

Detection/coverage: Monitor for unexpected child processes spawned by fgfmd. File integrity monitoring on /tmp/.tm and /var/tmp/.tm — known UNC5820 staging paths.

STEP 04

Exfiltrate managed device configurations

With root on FortiManager, the attacker extracts the FortiManager database containing every managed FortiGate's configuration: IP addresses, firewall rules, VPN PSKs, admin credentials (FortiOS256-hashed), routing tables, and certificate material. UNC5820 automated this into an archive staged at /tmp/.tm. This data enables lateral movement to every managed FortiGate.

Conditions required:

Root shell on FortiManager

Where this breaks in practice:

None — the data is stored locally on the FortiManager by design

Detection/coverage: Monitor for unexpected archive creation in /tmp/ or /var/tmp/. SIEM alerts on large outbound transfers from FortiManager management interfaces.

STEP 05

Pivot to managed FortiGate fleet

Using exfiltrated credentials and configuration data, the attacker can authenticate to managed FortiGate appliances, modify firewall policies to open additional attack surface, establish persistent VPN tunnels, or disable security controls across the entire managed perimeter. This converts a single FortiManager compromise into fleet-wide perimeter control.

Conditions required:

Exfiltrated credentials from Step 4
Network access to managed FortiGates (typically guaranteed from FortiManager's network position)

Where this breaks in practice:

If FortiGate admin passwords differ from managed configs (rare in centralized management)
If FortiGate management interfaces are further segmented from FortiManager

Detection/coverage: FortiGate login anomalies — new source IPs, unusual configuration changes. FortiAnalyzer/SIEM correlation of bulk config pushes.

03 · Compensating Control

CRITICAL 9.8→HIGH 7.5

SEVERITY REDUCED

Enable fgfm-deny-unknown immediately — On FortiManager 7.0.12+, 7.2.5+, 7.4.3+ (not 7.6.0), run config system global → set fgfm-deny-unknown enable → end. This prevents unregistered devices from connecting via FGFM, blocking the primary exploitation vector. Deploy within the noisgate mitigation SLA of 3 days (CRITICAL). Note: this breaks auto-registration of new FortiGates — pre-add serial numbers to the device list before enabling.

CRITICAL 9.8→MEDIUM 6.5

SEVERITY REDUCED

Restrict TCP/541 to known FortiGate source IPs — Deploy local-in policies (FortiManager 7.2.0+) or upstream firewall ACLs to allow only known, managed FortiGate IP addresses to reach TCP/541. Block all other sources, especially internet-originating traffic. This eliminates the unauthenticated remote attack vector from arbitrary sources. Deploy within 3 days per noisgate mitigation SLA.

CRITICAL 9.8→MEDIUM 5.5

SEVERITY REDUCED

Deploy custom certificate validation for FGFM — On FortiManager 7.2.2+, 7.4.0+, 7.6.0+, configure custom CA-signed certificates for the FGFM channel. This requires attackers to possess a valid certificate signed by your internal CA to establish a FGFM session, raising the exploitation bar significantly. Deploy within 3 days.

CRITICAL 9.8→IGNORE 0.0

SEVERITY REDUCED

Patch to fixed version — Upgrade to FortiManager 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15, or 6.2.13. This is the definitive remediation. Given KEV listing and active exploitation, this should be treated as an emergency change — target deployment within the noisgate remediation SLA of 90 days, but strongly prefer patching within days to weeks given confirmed in-the-wild exploitation.

CRITICAL 9.8→CRITICAL 9.8

Audit for prior compromise — Before or concurrent with patching, check IoCs: examine /fds/data/unreg_devices.txt for rogue serial numbers (e.g., FMG-VMTM23017412, FMG-VMTM19008093), look for archive files at /tmp/.tm or /var/tmp/.tm, review logs for 'Unregistered device localhost add succeeded' entries, and check for inbound connections from known UNC5820 IPs (45.32.41.202, 104.238.141.143, 158.247.199.37, 80.66.196.199). If compromise indicators are found, treat managed FortiGate credentials as breached and rotate immediately.

What doesn't work

WAF/IPS in front of FortiManager — FGFM is a proprietary binary protocol on TCP/541, not HTTP. Standard web application firewalls cannot inspect or filter this traffic. Network IPS signatures may exist but rely on pattern matching against a protocol most IPS engines do not deeply parse.
FortiManager admin password rotation — The vulnerability bypasses authentication entirely; changing admin passwords has zero effect on exploitation. The attacker never authenticates.
Disabling the web GUI — The vulnerability is in the fgfmd daemon (FGFM protocol on TCP/541), not the web management interface. Disabling HTTPS management access does not affect the FGFM listener.
Network segmentation alone without ACLs on 541 — Placing FortiManager on a management VLAN helps but does not block exploitation if FortiGates (or any compromised host on that VLAN) can reach port 541. The FGFM port must be explicitly ACL'd to known FortiGate sources.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	Confirmed active since June 27, 2024. Mandiant tracked threat cluster UNC5820 exploiting 50+ FortiManager instances across multiple industries. Automated exfiltration of managed device configs, credentials, and FortiGate IPs observed. Mandiant/Google Cloud blog
CISA KEV Status	Added October 23, 2024. Federal agencies required to patch by November 13, 2024. CISA alert
EPSS Score	0.94766 (top ~5% of all CVEs) — extremely high probability of exploitation activity.
Proof-of-Concept Availability	Public, weaponized. watchtowrlabs/Fortijump-Exploit-CVE-2024-47575 by Sina Kheirkhah of watchTowr — full RCE exploit with check and exploit modes. Nuclei template available at `projectdiscovery/nuclei-templates` (PR #11355). Additional PoC references on pocindex.io.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` — Network-reachable, zero complexity, no authentication, no user interaction. Maximum impact across confidentiality, integrity, and availability.
Affected Versions	FortiManager 7.6.0, 7.4.0–7.4.4, 7.2.0–7.2.7, 7.0.0–7.0.12, 6.4.0–6.4.14, 6.2.0–6.2.12. FortiManager Cloud 7.4.1–7.4.4, 7.2.1–7.2.7, 7.0.1–7.0.12, 6.4 (all).
Fixed Versions	FortiManager 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15, 6.2.13. FortiManager Cloud 7.4.5, 7.2.8, 7.0.13.
Exposure / Attack Surface	Shodan: ~60,000 internet-facing FortiManager devices (13K+ in US, 5.8K+ in China, ~3K in Brazil). Censys: 4,081 exposed admin portals, ~86% on default FGFM port (TCP/541). ~30% of exposed instances concentrated in the US.
Disclosure Timeline	Exploitation observed: June 27, 2024. Fortinet private notification to customers: October 13, 2024. Public advisory (FG-IR-24-423): October 23, 2024. CISA KEV addition: October 23, 2024.
Reporting Researcher	Reported by Fortinet internally; exploitation discovered by Mandiant (Google Cloud) during incident response. Public PoC by Sina Kheirkhah (watchTowr Labs).

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.8/10)

Why this verdict

Trivial exploitation, zero friction: The attack requires only network access to TCP/541 and a single crafted request. No authentication, no user interaction, no race conditions, no chaining. The public watchTowr PoC is point-and-shoot. This is as close to zero-click RCE as network vulnerabilities get.
Confirmed mass exploitation with nation-state-grade operational security: UNC5820 exploited this for four months before disclosure across 50+ organizations. The EPSS score of 0.94766 and KEV listing confirm this is not theoretical — it is actively weaponized at scale.
Role multiplier: FortiManager is canonically a high-value network management platform. 100% of FortiManager installations exist to manage FortiGate firewalls — it is a fleet-management appliance *by definition*. Compromise yields root on the appliance that stores credentials, configs, VPN secrets, and firewall policies for every managed FortiGate. The blast radius is not host-level — it is fleet-level perimeter control. A single FortiManager compromise cascades to every managed FortiGate, which are themselves perimeter/network-edge appliances. This is a supply-chain-scale outcome on a component where ≥95% of installs occupy the high-value role. The verdict floor is CRITICAL.
Massive internet-facing exposure: Unlike many management-plane vulnerabilities that require internal access, ~60,000 FortiManager instances are directly internet-reachable. Even restricting to the Censys figure of 4,081 exposed admin portals, the externally reachable population is substantial. Internal-only deployments are still reachable from any compromised host with a route to the management VLAN — which is the expected position of a FortiGate itself.
No compensating control enabled by default: The fgfm-deny-unknown workaround is not enabled by default and is only available on newer versions (7.0.12+, 7.2.5+, 7.4.3+). Custom certificate enforcement is opt-in and rarely deployed. The default-vulnerable population is the entire installed base.

Why not higher?

A 9.8 is effectively the maximum CVSS score for a network vulnerability without Scope change. The only theoretical increase would be to 10.0 with Changed scope, but the FGFM protocol exploitation is scoped to the FortiManager host itself (post-exploitation pivot to FortiGates is a separate action, not a direct consequence of the vulnerability primitive). The 9.8 is the correct ceiling.

Why not lower?

Every downgrade argument fails here. The 'requires internal network' friction does not apply — 60,000 instances are internet-facing. The 'requires specific configuration' argument does not apply — the default configuration is vulnerable. The 'limited blast radius' argument does not apply — FortiManager is by definition the fleet-management console for all managed FortiGate perimeter appliances. There is zero authentication, zero complexity, and confirmed mass exploitation by a tracked threat actor. Downgrading below CRITICAL would require evidence that the vulnerable population is negligible or that the exploitation path is unreliable, neither of which is true.

06 · Verification

Crowdsourced verification payload.

Run this script on each FortiManager appliance via SSH as root (or via the FortiManager CLI shell). It checks the running firmware version against known-vulnerable ranges. Invoke with: bash check_fortijump.sh

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# check_fortijump.sh — CVE-2024-47575 (FortiJump) version check for FortiManager
# Run on the FortiManager appliance as root via SSH or CLI shell.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

VERSION_STRING=$(get_system_status 2>/dev/null | grep -i 'Version:' | head -1)
if [ -z "$VERSION_STRING" ]; then
  # Try alternative method
  VERSION_STRING=$(diagnose sys status 2>/dev/null | grep -i 'Version:' | head -1)
fi

if [ -z "$VERSION_STRING" ]; then
  # Try reading from /etc/version or build info
  if [ -f /etc/version ]; then
    VERSION_STRING=$(cat /etc/version)
  fi
fi

if [ -z "$VERSION_STRING" ]; then
  echo "UNKNOWN — Could not determine FortiManager version."
  echo "Manually check: run 'get system status' in the FortiManager CLI."
  exit 2
fi

echo "Detected version string: $VERSION_STRING"

# Extract major.minor.patch
VER=$(echo "$VERSION_STRING" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)
if [ -z "$VER" ]; then
  echo "UNKNOWN — Could not parse version number from: $VERSION_STRING"
  exit 2
fi

MAJOR=$(echo "$VER" | cut -d. -f1)
MINOR=$(echo "$VER" | cut -d. -f2)
PATCH=$(echo "$VER" | cut -d. -f3)

echo "Parsed version: $MAJOR.$MINOR.$PATCH"

# Fixed versions: 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15, 6.2.13
VULNERABLE=0

if [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 6 ]; then
  [ "$PATCH" -lt 1 ] && VULNERABLE=1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 4 ]; then
  [ "$PATCH" -lt 5 ] && VULNERABLE=1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 2 ]; then
  [ "$PATCH" -lt 8 ] && VULNERABLE=1
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 0 ]; then
  [ "$PATCH" -lt 13 ] && VULNERABLE=1
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 4 ]; then
  [ "$PATCH" -lt 15 ] && VULNERABLE=1
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 2 ]; then
  [ "$PATCH" -lt 13 ] && VULNERABLE=1
elif [ "$MAJOR" -eq 6 ] && [ "$MINOR" -eq 0 ]; then
  # 6.0.x — all versions vulnerable, no fix available
  VULNERABLE=1
elif [ "$MAJOR" -lt 6 ]; then
  # Older than 6.x — likely EOL and vulnerable
  VULNERABLE=1
fi

# Check for fgfm-deny-unknown workaround
WORKAROUND="not checked"
DENY_UNKNOWN=$(config system global 2>/dev/null <<EOF
get
EOF
)
if echo "$DENY_UNKNOWN" | grep -q 'fgfm-deny-unknown.*enable'; then
  WORKAROUND="ENABLED (fgfm-deny-unknown)"
else
  WORKAROUND="NOT ENABLED"
fi

if [ "$VULNERABLE" -eq 1 ]; then
  echo "VULNERABLE — FortiManager $MAJOR.$MINOR.$PATCH is affected by CVE-2024-47575 (FortiJump)."
  echo "Workaround status: $WORKAROUND"
  echo "ACTION: Upgrade immediately. Fixed versions: 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15, 6.2.13."
  echo "Check IoCs: /tmp/.tm, /var/tmp/.tm, /fds/data/unreg_devices.txt"
  exit 1
else
  echo "PATCHED — FortiManager $MAJOR.$MINOR.$PATCH is not affected by CVE-2024-47575."
  exit 0
fi