CVE-2026-35616

What it actually does

Improper access control in Fortinet FortiClientEMS 7.4.5 through 7.4.6 allows an unauthenticated network attacker to reach privileged management functions and execute unauthorized code or commands on the EMS host. Successful abuse yields remote code execution with the privileges of the EMS service, compromising confidentiality, integrity, and availability of the management plane and any data or credentials it holds. Because EMS is the control plane for enrolled FortiClient endpoints, host-level execution can be leveraged to alter endpoint policy, distribute malicious configuration, or harvest enrollment and authentication material.

Why it matters to the business

Compromise of FortiClient EMS threatens the organization-wide endpoint security stack: attackers can disrupt protection, push unauthorized software or policy to managed devices, steal credentials, and use the EMS as a beachhead for ransomware or data theft. This issue is in CISA KEV, is confirmed exploited in the wild, carries a CVSS 9.8 and an EPSS of approximately 0.94 (rising about 4% over 30 days), and had a CISA remediation due date of 2026-04-09. With more than 200 days since publication and no listed fixed versions in this record, any remaining 7.4.5–7.4.6 deployments represent overdue, high-urgency exposure of a central security-management system.

How an attack unfolds

An unauthenticated attacker scans for reachable FortiClient EMS management interfaces, then sends crafted requests that bypass access-control checks on versions 7.4.5 through 7.4.6. Those requests cause the EMS process to execute attacker-chosen commands on the server without login. After obtaining a foothold on the EMS host, the attacker can persist, steal EMS and endpoint credentials, and abuse legitimate EMS management channels to influence enrolled clients. Public reporting associates in-the-wild activity with this FortiClient EMS improper access control issue; operators should assume opportunistic internet scanning as well as targeted follow-on after any exposed instance is found.

How to fix it

Treat remaining 7.4.5 and 7.4.6 FortiClient EMS systems as critically exposed. Apply Fortinet’s latest patched EMS release immediately; this record lists no exact fixed versions, so confirm the current advisory and upgrade path directly from Fortinet and do not remain on 7.4.5–7.4.6. Until patched, restrict EMS management interfaces to trusted administration networks only, place EMS behind VPN or jump-host controls, and block unauthenticated internet or campus-wide access to EMS ports. Rotate EMS, database, and related service credentials after patching if exposure cannot be ruled out. Review enrolled-client policies for unauthorized changes and rebuild any EMS host with evidence of compromise rather than trusting an in-place cleanup.

How to confirm the fix worked

Inventory every FortiClient EMS instance and confirm the installed version is not 7.4.5 or 7.4.6 and matches Fortinet’s current fixed build. Verify management listeners are not reachable from untrusted networks. After upgrade, confirm EMS services start cleanly, agents still check in, and no unexpected administrative accounts, scheduled tasks, or policy objects were added. Use authenticated asset and vulnerability scans against EMS hosts and review change tickets to prove the patch window closed. If a system was online while vulnerable, assume possible prior abuse and complete the detection checks below before declaring the host trusted.

Typical attack path

1. Discover FortiClient EMS instances that are network-reachable, including internet-exposed management ports.
2. Fingerprint product version to confirm 7.4.5 or 7.4.6.
3. Send unauthenticated crafted requests that abuse the access-control flaw.
4. Achieve unauthorized command or code execution on the EMS host.
5. Establish persistence and collect EMS, database, and enrollment credentials.
6. Abuse EMS as a trusted management channel to alter endpoint policy or stage further access.
7. Move laterally from the EMS server into the broader enterprise.
8. Cover tracks in EMS, web, and system logs where possible.

How to detect it

Assume exploitation may already have occurred on any EMS 7.4.5 or 7.4.6 host that was reachable by untrusted users. Review EMS application and Apache/web logs for unauthenticated requests that produced privileged actions or server errors around command execution; correlate with Windows Security and Sysmon process-creation events where the EMS or Apache service spawned unexpected shells, scripting hosts, or admin tools. Inspect outbound connections from the EMS host to unusual destinations, new local accounts, new scheduled tasks, and unexpected changes to endpoint policies or installer packages. Network telemetry should flag internet-to-EMS traffic on management ports and subsequent EMS-to-endpoint management bursts. Named in-the-wild activity is tied to this FortiClient EMS access-control issue rather than a specific public APT alias, so hunt by behavior and EMS artifacts rather than a single actor name. Preserve logs covering at least from first deployment of 7.4.5/7.4.6 through patching.

• unauthenticated POST or PUT to FortiClient EMS management listeners on tcp/443, tcp/10443, or tcp/8013 from untrusted source IPs
• parent process Fcems.exe, daemons.exe, or Apache/httpd under FortiClientEMS spawning cmd.exe, powershell.exe, wscript.exe, cscript.exe, bash, or python.exe
• C:\\Program Files (x86)\\Fortinet\\FortiClientEMS\\logs\\
• C:\\Program Files\\Fortinet\\FortiClientEMS\\logs\\
• new or modified files under C:\\Program Files (x86)\\Fortinet\\FortiClientEMS\\ immediately after unauthenticated web requests
• Windows Event 4688 / Sysmon Event 1: EMS or Apache service account creating cmd.exe or powershell.exe
• unexpected scheduled tasks or services created on the EMS host around the time of crafted EMS requests
• EMS policy or installer package objects modified by non-admin or unknown principals
• outbound connections from the EMS host to previously unseen C2-like IPs or domains shortly after inbound unauthenticated EMS requests

What your security team should do

• Patch or replace every FortiClient EMS 7.4.5 and 7.4.6 instance immediately; this is overdue relative to the CISA KEV due date of 2026-04-09.
• Remove EMS management interfaces from the internet and from broad internal networks; allow only jump hosts or admin VLANs.
• Hunt now for prior exploitation using EMS, web, process-creation, and network logs covering the full period of exposure.
• Rotate EMS, database, API, and related credentials and review endpoint policies for unauthorized pushes.
• Isolate or rebuild any EMS host with evidence of unauthenticated command execution or unexplained child processes.
• Add continuous version and exposure monitoring for FortiClient EMS given active exploitation and very high EPSS.