FortiBleed vs FortiClient EMS RCE: Two Fortinet Incidents, Two Very Different Lessons

Fortinet has been in the security spotlight more than once, but not every Fortinet-related incident tells the same story.

Two cases stand out: FortiClient EMS Remote Code Execution in 2024 and the more recent FortiBleed credential compromise campaign. Both involve Fortinet technologies. Both created serious risk for organizations. Both were capable of opening the door to deeper compromise.

But the way they worked was very different.

One was a critical vulnerability that allowed attackers to execute code. The other was a large-scale credential compromise affecting Fortinet firewalls and VPN gateways. One was about exploiting software. The other was about abusing access that already worked.

That distinction is important because it changes how organizations should respond.

The 2024 FortiClient EMS RCE: When a Management Server Becomes the Entry Point

Fortinet’s PSIRT advisory for CVE-2023-48788 was published on 12 March 2024, describing a critical SQL injection issue in FortiClient EMS that could allow unauthorised code or command execution.

FortiClient EMS is not just another server. It is a management platform used to control endpoint security policies, VPN settings, and connected devices. That makes it powerful for administrators, and extremely attractive to attackers.

By late March 2024, exploitation activity had already been observed in the wild. Attackers were exploiting vulnerable FortiClient EMS servers to deploy unauthorised remote monitoring and management (RMM) tools and PowerShell backdoors. Reports also indicated that exploitation began as early as 24 March 2024, with threat actors targeting internet-exposed EMS services over TCP port 8013.

One particularly interesting observation was that, after the vulnerability was exploited and access was gained to an EMS device on one customer network, two additional devices were seen making HTTP POST requests to:

1.     77.246.103[.]110

2.     212.113.106[.]100

These requests used a new PowerShell user agent, suggesting follow-on activity after initial access. That detail matters because it shows the attack did not stop at “exploit successful.” It moved into post-exploitation: command execution, remote tools, backdoors, and potentially deeper access.

Medusa ransomware was also linked to the exploitation of CVE-2023-48788 in 2024. By June 2024, the ransomware group was actively exploiting the vulnerability across multiple incidents. In a separate attack observed in July 2024, initial access was likely obtained through a compromised FortiClient EMS server, with attacker activity occurring nearly three weeks before the ransomware was ultimately deployed.

So, CVE-2023-48788 was not just a patching problem. It became an incident response problem.

FortiBleed: When the Password Is the Payload

FortiBleed is a different kind of problem.

Instead of exploiting a newly disclosed Fortinet software vulnerability, FortiBleed is centered on credentials linked to Fortinet firewalls and VPN gateways. Researchers reported a large-scale campaign involving verified working usernames and passwords for Fortinet devices across many countries and sectors. FortiBleed is not currently proven to be a Fortinet zero-day. It is better described as a large-scale credential compromise campaign affecting FortiGate firewalls and VPN gateways.

The scary part is simple: attackers do not always need to exploit a vulnerability if they can simply log in.

With FortiBleed, the attacker’s advantage appears to come from credential reuse, previously leaked passwords, exposed services, brute forcing, and weak credential hygiene. In other words, this is not just a Fortinet story. It is also a story about organizations failing to rotate passwords, enforce MFA, restrict management interfaces, and treat firewall credentials as crown-jewel assets.

A firewall is supposed to guard the front door. FortiBleed shows what happens when attackers already have the keys.

Exploit vs Credential Abuse

The biggest difference between FortiClient EMS RCE and FortiBleed is the attack mechanism.

Area	FortiClient EMS RCE 2024	FortiBleed
Main issue	Critical SQL injection leading to RCE	Credential harvesting and abuse
CVE involved	CVE-2023-48788	No confirmed new CVE or zero-day at this stage
Primary product area	FortiClient Enterprise Management Server	FortiGate firewalls and VPN gateways
Attacker method	Exploit vulnerable EMS service	Use verified credentials or brute-force old/reused passwords
Access type	Code execution on vulnerable server	Login access to perimeter devices
Main risk	Initial access, SYSTEM-level execution, RMM tools, backdoors, ransomware	Unauthorized VPN/firewall access, persistence, traffic monitoring, lateral movement
Best immediate response	Patch EMS, investigate exploitation, check for RMM/backdoors	Rotate credentials, enforce MFA, restrict admin access, review VPN/firewall logs

The EMS RCE was a classic high-severity vulnerability: find the exposed service, send crafted requests, achieve code execution, then move further. FortiBleed is more uncomfortable because it is less exotic. It does not need to begin with a sophisticated exploit. It can begin with an old password.

Why FortiClient EMS RCE Was So Dangerous

CVE-2023-48788 was dangerous because it affected a management system. Management platforms are high-value targets because they sit above many endpoints. If attackers compromise a management server, they may gain a better view of the environment, more control, and more opportunities to deploy tools across the network.

In observed attacks, exploitation was followed by attempts to install remote monitoring and management tools such as ScreenConnect or Atera, or to deploy PowerShell-based backdoors. That pattern is familiar in modern intrusions. Attackers often use legitimate tools because they blend into normal administrative activity.

This is why patching alone is not always enough. If a vulnerable FortiClient EMS instance was exposed during the exploitation window, security teams should not simply update and move on. They should investigate whether exploitation already occurred. Important checks include unusual connections to the EMS service, suspicious child processes from SQL Server, PowerShell download activity, msiexec execution, unexpected RMM tools, new accounts, and outbound connections to unfamiliar infrastructure.

Why FortiBleed May Be Broader

FortiBleed is dangerous for a different reason: scale.

A single vulnerable EMS server may give access to one environment. A credential dataset containing thousands of firewall and VPN logins can expose organizations across industries and countries at the same time.

Firewalls and VPN gateways are especially sensitive because they often sit directly on the internet. They are trusted access points into internal networks. If attackers can authenticate successfully, they may not trigger the same alarms as a noisy exploit attempt. They may appear to be legitimate users.

That is why FortiBleed is not just a password problem. It is an identity, exposure, and monitoring problem. The campaign also shows how old security failures can return. Passwords leaked from previous incidents, default accounts left unchanged, reused credentials, weak administrator practices, and missing MFA can all become useful to attackers years later.

Security debt does not disappear. It waits.

The Real Lesson: Patch Management Is Not Enough

FortiClient EMS RCE teaches one lesson clearly: exposed critical vulnerabilities must be patched fast. FortiBleed teaches a second lesson: even patched systems can remain exposed if credentials are weak, reused, stolen, or unmanaged.

Together, the two incidents show that Fortinet environments need two layers of defense.

The first layer is vulnerability management: identify affected versions, patch quickly, monitor advisories, and reduce exposure of administrative services.

The second layer is identity and access hygiene: rotate credentials, remove default accounts, enforce MFA, restrict admin interfaces, review login history, and treat firewall/VPN access as privileged access. Many organizations do the first layer better than the second. FortiBleed shows why that is not enough.

What Organizations Should Do Now

For FortiClient EMS CVE-2023-48788:

• Upgrade FortiClient EMS to a fixed version immediately.

• Investigate any unpatched EMS instance that was internet-accessible in March 2024 or later.

• Check for suspicious FCMdaemon activity, SQL Server child processes, PowerShell downloads, msiexec execution, and unauthorized RMM tools.

• Look for persistence mechanisms, new accounts, backdoors, and unusual outbound connections.

• Treat confirmed exploitation as an incident, not just a vulnerability ticket.

For FortiBleed:

• Rotate all Fortinet firewall and VPN administrator credentials.

• Rotate VPN user passwords, especially old or reused credentials.

• Enforce MFA on all administrator and remote-access accounts.

• Restrict firewall management access so it is not publicly reachable.

• Review successful and failed login attempts.

• Check for unfamiliar administrator accounts, configuration changes, and suspicious VPN sessions.

• Confirm firmware is updated and configurations are hardened.

• Treat appearance in a FortiBleed dataset as a potential perimeter compromise.

Final Thought: The Exploit Changed, But the Target Stayed the Same

FortiClient EMS RCE and FortiBleed are not the same incident.

The 2024 EMS attack was about exploiting a critical software flaw to execute commands. FortiBleed is about abusing valid credentials to access firewalls and VPN gateways. One breaks in through a vulnerability. The other walks in through the front door.

But both incidents point to the same uncomfortable reality: attackers are aggressively targeting the systems organizations trust most.

Endpoint management servers.

Firewalls.

VPN gateways.

Administrator accounts.

Remote access infrastructure.

These are not side systems. They are the control points of the modern enterprise.

The lesson is clear: do not only ask, “Are we patched?” Ask, “Could someone still log in?”

Because in 2024, attackers proved they could exploit the management layer. With FortiBleed, they proved something even simpler. Sometimes, they already have the password.