Port 541 – UUCP-RLOGIN (FortiGate/FortiManager FGFM)

Port 541 has a split identity, and the gap between them is the whole story. By IANA registration the port belongs to uucp-rlogin, a legacy Unix-to-Unix Copy variant that tunnels a remote login — an obscure relic of pre-internet dial-up networking that you will essentially never meet on a live host today. In practice, an open TCP 541 almost always means the Fortinet FGFM channel — the FortiGate-to-FortiManager protocol that Fortinet firewalls and their central FortiManager use to manage each other. FGFM runs a TLS-wrapped session handled by the fgfmd daemon on FortiOS (the FortiGate) and fgfmsd on FortiManager, and the port opens the moment fgfm is added to an interface’s administrative access. That FGFM service — not uucp — is what nmap, Shodan, and pentesters actually find on 541, and in the last two years it has become one of the highest-value listeners on the internet.

This page covers both but weights the Fortinet reality, because that is what an open 541 means on a real engagement. It’s the same problem shape as port 264, where the IANA name (BGMP) is a historical footnote and an open port really means a security vendor’s management service (Check Point). On 541 the vendor is Fortinet — and unlike the mostly-recon Check Point case, an exposed FGFM port carries unauthenticated remote code execution bugs that are on the CISA Known Exploited Vulnerabilities list.

Why It’s Open

If 541 answers, you are almost certainly looking at a Fortinet device wired into central management, not a Unix box running uucp. On a FortiGate the port opens when fgfm (labelled FMG-Access in the GUI) is added to an interface’s allowaccess list so a FortiManager can reach in and push policy. Both endpoints run the FGFM daemon: a FortiManager listens on TCP 541 for incoming session requests, and a FortiGate exposes 541 on any interface where FMG-Access is enabled. When a FortiGate sits behind NAT it dials outbound to the FortiManager’s 541 instead — but plenty of internet-facing firewalls end up with fgfm left on a WAN interface, which is exactly the exposure that turns a management convenience into an attack surface.

The genuine uucp-rlogin case is effectively extinct — a museum piece on some ancient Unix host, not something you’ll find on an enterprise perimeter. For any modern or internet-facing target, treat an open 541 as Fortinet FGFM until proven otherwise. The same appliance usually exposes the rest of its management plane a scan or two away: the admin GUI and SSL-VPN on HTTPS 443 or 8443, the CLI on SSH 22, the IPsec VPN on IKE 500, and monitoring on SNMP 161 — so a hit on 541 is often the thread that maps the whole Fortinet estate.

Common Risks

• Unauthenticated remote code execution over FGFM. The headline issue. The FGFM daemon on both sides of the channel has shipped critical pre-auth RCE bugs — CVE-2024-23113 on the FortiGate (fgfmd format string) and CVE-2024-47575 “FortiJump” on FortiManager (fgfmsd missing authentication). Both are CVSS 9.8, both need no credentials, and both are on the CISA KEV list. An exposed 541 is a direct path to code execution.
• Weak device-registration trust. FGFM authenticates registering devices by certificate, but historically accepts any valid Fortinet-signed certificate — so an attacker can lift a cert from any FortiGate they can buy or reach and register a rogue device against a target FortiManager. That design gap is the mechanism behind FortiJump.
• Fleet-wide config and credential theft. FortiManager holds the configuration of every firewall it manages. A foothold via 541 exposes managed-device configs, IPsec/VPN pre-shared keys, and FortiOS256-hashed admin passwords — the FortiJump intrusions exfiltrated exactly this, giving attackers the keys to the whole managed fleet.
• Fingerprinting. Even before any exploit, an open 541 identifies the box as Fortinet and signals that central management is in use — which narrows the target and directs the next moves at the admin GUI/SSL-VPN, SSH, and IKE ports.
• Internet exposure. FGFM is a management protocol that should live only on a trusted management network. Any 541 reachable from untrusted networks is a misconfiguration worth flagging on its own.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and version

nmap -sV -p 541 <target>

There is no dedicated FGFM NSE script in Nmap. Version detection fingerprints the TLS service and, combined with the certificate, confirms you’re dealing with Fortinet FGFM rather than a genuine uucp-rlogin daemon. That identification alone is the first useful finding.

Inspect the FGFM certificate

openssl s_client -connect <target>:541 </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer

FGFM is wrapped in TLS, so the handshake hands back the device certificate. On Fortinet gear the subject/issuer frequently expose the appliance serial number and a FGT/FMG naming pattern — enough to confirm the vendor and often the exact model from an unauthenticated connection.

Confirm the port answers

nc -nv <target> 541

A response confirms something is listening; pair it with the probes above to decide whether it’s FGFM or (almost never) an actual uucp-rlogin service.

Check the version against the KEV CVEs

Once the FortiOS or FortiManager build is known (from the certificate, the admin GUI on 443, or the login banner), compare it against the fixed releases for CVE-2024-23113 and CVE-2024-47575 below. An FGFM listener on an unpatched build is the whole finding.

Log every open 541, the certificate details, and the resolved FortiOS/FortiManager version so they land in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The uucp-rlogin service that owns the IANA registration has essentially no modern CVE footprint. Every tracked vulnerability that matters on port 541 belongs to the Fortinet FGFM channel that actually lives there — and two of them are critical, unauthenticated, and actively exploited:

• CVE-2024-47575 — “FortiJump” (the headline). A missing-authentication flaw (CWE-306) in the FortiManager FGFM daemon (fgfmsd) lets a remote, unauthenticated attacker execute arbitrary code or commands via crafted FGFM requests to TCP 541. CVSS v3.1 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Affects 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 and several FortiManager Cloud builds; fixed in 7.6.1 / 7.4.5 / 7.2.8 / 7.0.13 / 6.4.15 / 6.2.13. Detailed in Fortinet PSIRT FG-IR-24-423, added to the CISA KEV catalog, and exploited as a zero-day since June 2024. Public exploit: watchtowrlabs/Fortijump-Exploit-CVE-2024-47575.
• CVE-2024-23113 — FortiOS fgfmd format string. An externally-controlled format string (CWE-134) in the FortiGate-side FGFM daemon lets a remote, unauthenticated attacker run code or commands via specially crafted packets to 541. CVSS v3.1 9.8 (same vector). Affects FortiOS 7.4.0–7.4.2, 7.2.0–7.2.6, 7.0.0–7.0.13 (plus FortiProxy, FortiPAM, and FortiSwitchManager); FortiOS 6.x is not affected. Detailed in FG-IR-24-029, added to CISA KEV in October 2024. Public research and PoC: watchtowr’s writeup and p33d/CVE-2024-23113.
• FGFM device-registration trust (no single CVE). FGFM historically accepts any valid Fortinet-signed certificate for device registration, so an attacker can reuse a certificate from any FortiGate to register a rogue device against an exposed FortiManager. This isn’t a standalone CVE — it’s the enabling weakness that makes FortiJump reachable — and the practical fix is set fgfm-deny-unknown enable plus strict network access control (see Mitigation).

Note that not every FortiManager CVE belongs on 541: the wordexp OS-command-injection bug CVE-2023-25607, for example, is an authenticated flaw in the GUI management interface, not the FGFM service — don’t attribute it to this port.

Mitigation

• Never expose 541 to the internet. FGFM is a management protocol. Remove fgfm / FMG-Access from any WAN or untrusted interface’s allowaccess and keep it only on a dedicated management interface reachable by the FortiManager.
• Lock it down with a local-in policy. On the FortiGate, add a local-in policy that accepts TCP 541 only from the FortiManager’s IP address and denies everything else — a correctly restricted port shows as filtered to an outside scan rather than open.
• Deny unknown devices on FortiManager. Run config system global → set fgfm-deny-unknown enable so the FortiManager rejects management requests from device serial numbers that aren’t already in its Device Manager database — the recommended workaround that closes the FortiJump registration path (note it isn’t available as a workaround on 7.6.0, which must be patched).
• Patch to fixed builds. Upgrade FortiOS and FortiManager to releases that fix CVE-2024-23113 and CVE-2024-47575; both are on CISA KEV with federal remediation deadlines, so treat them as emergency-priority.
• Monitor and alert. Watch FortiManager event logs for Deny request from an unregistered device messages and unexpected FGFM sessions — repeated registration attempts from unknown serials are reconnaissance, not normal behaviour.
• Harden the rest of the plane. A box found on 541 exposes the rest of its management surface too — secure the admin GUI/SSL-VPN on 443/8443, the CLI on SSH 22, kill legacy Telnet 23, and review IKE on 500.

Real-World Example

In October 2024 Fortinet disclosed CVE-2024-47575, quickly nicknamed FortiJump — but the attacks had already been running for months. A threat cluster tracked as UNC5820 had been exploiting the FortiManager FGFM service on TCP 541 as a zero-day since at least June 27, 2024. The move was brutally simple: because FGFM’s device registration would accept any valid Fortinet certificate, the attackers took a certificate from a FortiGate they controlled, connected to an internet-exposed FortiManager on 541, registered a rogue device with no authentication, and issued FGFM commands that let them run code on the manager.

From there the payoff was the whole fleet. FortiManager stores the configuration of every firewall it manages, so the intruders exfiltrated managed-device configs, IP addressing and policy, and FortiOS256-hashed admin passwords — the material needed to pivot into every downstream FortiGate. Fortinet’s remediation guidance leaned on exactly the controls above: patch, restrict 541 to trusted management, and enable fgfm-deny-unknown. Paired with the FortiGate-side format-string RCE CVE-2024-23113 on the same port, FortiJump is the textbook case of why an “obscure” IANA port name is a distraction: what actually listens on 541 is a critical management channel, and when it faces the internet it becomes fleet-wide remote code execution.

FAQ

What is port 541 used for?

Two things, depending on what’s actually listening. By IANA registration, TCP 541 is uucp-rlogin, a legacy Unix-to-Unix Copy remote-login variant that is effectively never seen today. In practice, an open TCP 541 is the Fortinet FGFM channel — the FortiGate-to-FortiManager protocol that Fortinet firewalls and their FortiManager use to manage each other, handled by the fgfmd/fgfmsd daemons over TLS.

Why is port 541 open on my FortiGate?

Because fgfm (shown as FMG-Access in the GUI) is enabled on that interface’s administrative access, so a FortiManager can reach in to push configuration. It’s normal on a management interface; it should not be on a WAN or any interface facing untrusted networks. If you don’t use FortiManager, remove fgfm from allowaccess and the port closes.

Is port 541 FGFM or uucp?

Almost always FGFM. uucp-rlogin is the registered assignment but is essentially extinct, so a live uucp speaker on 541 is a rarity. Nmap, Shodan, and pentest scans that turn up 541 are finding the Fortinet FGFM service in the overwhelming majority of cases — fingerprint it with nmap -sV and inspect the TLS certificate to confirm.

Is port 541 dangerous?

When it’s exposed, yes. The FGFM service on 541 has two critical, unauthenticated remote-code-execution CVEs on the CISA KEV list — CVE-2024-47575 (FortiJump, on FortiManager) and CVE-2024-23113 (on FortiOS) — both CVSS 9.8. An internet-reachable, unpatched 541 is a direct route to code execution and, via FortiManager, to the configuration of every firewall it manages.

How do I secure or close port 541?

Remove fgfm/FMG-Access from untrusted interfaces so the port only listens on your management network, add a local-in policy allowing TCP 541 only from the FortiManager’s IP, enable set fgfm-deny-unknown enable on FortiManager to block unknown device registrations, and patch FortiOS/FortiManager to builds that fix CVE-2024-23113 and CVE-2024-47575. Rescan afterwards to confirm the port shows filtered or closed from untrusted networks.

TL;DR

• Service: Registered to uucp-rlogin (legacy, effectively extinct) — but an open 541 is almost always Fortinet’s FGFM FortiGate-to-FortiManager management channel (fgfmd/fgfmsd over TLS)
• Default port: 541/TCP
• Biggest risk: unauthenticated remote code execution — CVE-2024-47575 “FortiJump” (FortiManager, CVSS 9.8, CISA KEV) and CVE-2024-23113 (FortiOS, CVSS 9.8, CISA KEV), plus FortiManager-managed fleet compromise
• Mitigation: keep 541 off untrusted interfaces, restrict it to the FortiManager IP with a local-in policy, enable fgfm-deny-unknown, and patch to fixed FortiOS/FortiManager builds
• Same “IANA name vs vendor reality” pattern as port 264 (Check Point) — the registered name is a distraction; what listens is a vendor management service