Is CVE-2026-35616 (Fortinet FortiClient EMS Improper Access Control) being exploited in the wild?

What “exploited in the wild” means for this Fortinet CVE

For a KEV-listed CVE, “exploited in the wild” means the issue is no longer theoretical or limited to lab proof-of-concept activity. In practice, that shifts the question from “should we watch this?” to “have we confirmed whether any exposed EMS instance or adjacent management path is reachable in our environment, and can we reduce exposure now?”

Because this vulnerability affects a management-facing product, exposure is often determined less by the presence of the software alone and more by how it is deployed, whether it is Internet-reachable, and whether administrative or automation interfaces are exposed to untrusted networks. That is why KEV entries are useful triage signals, but they do not replace asset confirmation and service exposure checks.

When a vendor management platform is publicly reachable, the security boundary is thinner than teams often assume. The practical question is not only whether FortiClient EMS is installed, but whether any instance is listening where an unauthenticated attacker could send crafted requests and reach code execution or command execution paths.

Zero-Day and Exploited Vulnerabilities Guide is the right companion for this kind of triage because it focuses on KEV-driven prioritisation, emergency mitigation and post-patch checking.

How to confirm exposure and reduce blast radius

Start by inventorying every FortiClient EMS instance, then verify where it is deployed, who can reach it, and whether any management endpoint is exposed beyond the trust zone it was designed for. If the system sits on a network segment that is reachable from the Internet or from broadly trusted internal networks, treat that as immediate exposure until proven otherwise.

For products that handle management or endpoint orchestration, exposure often includes more than the main application port. Check reverse proxies, VPN paths, load balancers, published admin portals and any automation or integration endpoints that may have been overlooked during hardening. A false sense of safety often comes from assuming “internal-only” when a relay, exception, or temporary rule made the service reachable.

Apply the vendor’s fix or mitigation as the primary control, then validate that the change actually removes the vulnerable path rather than only hiding it. For KEV-listed issues, this should be paired with a short-lived containment review: isolate the instance if patching is delayed, restrict source addresses, and remove unnecessary access paths that could preserve attacker reach.

CISA Known Exploited Vulnerabilities Catalog is the authoritative source for the exploitation status and required remediation expectation, while Fortinet should be used for version-specific fix guidance and deployment notes.

What to check if you cannot patch immediately

If patching must wait, the priority is to narrow the attack surface and look for signs that someone may already have used the flaw. Review access logs, reverse-proxy logs, EDR telemetry and any application audit records for unusual requests, unexpected child processes, new scheduled tasks, unplanned service changes or outbound connections from the EMS host.

Because the direct answer indicates unauthenticated exploitation is possible, do not limit hunting to credentialed user activity. Search for anomalous unauthenticated traffic, odd request patterns, process spawning from the EMS service context, and any evidence that the host was used as a launch point into adjacent systems. If the instance handles secrets, tokens, or administrative sessions, assume those may need review even if you have not yet confirmed full compromise.

NIST Cybersecurity Framework 2.0 helps structure this response across identify, protect, detect and respond, while MITRE ATT&CK Enterprise Matrix is useful for mapping the post-exploitation behaviours you should hunt for after an initial foothold.

Risk and Threat Considerations

A KEV-listed management vulnerability is dangerous because it can move quickly from exposure to full administrative compromise, especially when the vulnerable system sits near endpoint or network orchestration functions. In this case, unauthenticated request handling raises the likelihood of direct exploitation, not just opportunistic scanning.

Failure mechanism: The attacker abuses improper access control in a management service, sends crafted requests without valid authentication, and reaches code or command execution paths that should have been blocked.

Impact: A successful exploit can expose the EMS host, surrounding management plane, stored credentials or tokens, and may enable further compromise of managed endpoints or internal systems.

Practitioner Guidance

What to verify: Confirm every EMS deployment, every exposed management path, and every exception that could make the service reachable from untrusted networks. If you cannot prove a system is unreachable, treat it as exposed.

What to prioritise: Patch or mitigate first, then hunt for compromise indicators. For KEV-class issues, waiting for a perfect investigation before reducing exposure usually expands blast radius.

Practitioner takeaway: For a KEV-listed access-control flaw in a management product, the safest operating assumption is active exploitation plus unknown exposure until you have both patched and validated the environment.

Related resources from NHI Mgmt Group

• Guide: Edge Device Security Guide
• CVE-2026-35616 (Fortinet FortiClient EMS Improper Access Control)
• Is CVE-2018-13374 (Fortinet FortiOS and FortiADC Improper Access Control) being exploited in the wild?
• Is CVE-2026-34908 (Ubiquiti UniFi OS Improper Access Control) being exploited in the wild?
• Is CVE-2026-48907 (Widget Factory Joomla Content Editor Improper Access Control) being exploited in the wild?