CVE-2026-35616 is an improper access control vulnerability in Fortinet FortiClient EMS. CISA added it to the Known Exploited Vulnerabilities catalogue on 6 April 2026, which means attackers have used it in real attacks. Fortinet FortiClient EMS contains an improper access control vulnerability that may allow an unauthenticated attacker to execute unauthorized code or commands via crafted requests.
What this vulnerability means in practice
Improper access control means the product is making trust decisions too loosely, so a request that should have been denied can reach sensitive functions. In a remote management product, that is especially dangerous because the control plane often has broad visibility and authority over many endpoints.
For FortiClient EMS, the practical issue is not just that an unauthenticated requester can interact with the product, but that crafted requests may cross a boundary the server should have enforced. That turns a normal management surface into a high-value attack path for command execution and administrative abuse.
Why this class of flaw is dangerous
Access control failures are dangerous because they break the assumption that only trusted users or systems can perform sensitive actions. When the flaw is exploitable before authentication, attackers can skip the usual identity checks and go straight to impact.
That matters most in software that manages fleets of endpoints, policies, and security settings. A single weakness in the management layer can expose data, configuration, and execution paths that are far more sensitive than the application’s front-end features suggest.
How organisations check exposure and confirm impact
Start with an accurate inventory of where FortiClient EMS is deployed, then confirm whether any instance is reachable from untrusted networks or exposed through reverse proxies, VPN concentrators, or cloud ingress. Vendor advisories and the CISA KEV catalogue are the authoritative places to confirm version-specific remediation guidance and exploitation status.
Exposure assessment should also include operational context: which management hosts are Internet-accessible, which credentials or service accounts can interact with the console, and whether logs already show suspicious requests or unexpected administrative actions. If a system is in scope and externally reachable, treat it as a priority even before compromise is proven.
Remediation, detection, and post-incident review
Remediation should follow the vendor’s guidance as soon as possible, with compensating controls used only to buy time. If patching is delayed, restrict access at the network layer, remove unnecessary exposure, and increase monitoring around the management interface and any backend processes it can trigger.
Detection should focus on abnormal requests, unexpected command execution, and any new files, processes, or scheduled tasks created after suspicious access to the EMS service. After patching, review the environment for signs that the flaw was already used, because exploited management interfaces often leave behind persistence, stolen configuration, or modified administrative settings.
Risk and Threat Considerations
Because this flaw can be reached by an unauthenticated attacker, the main risk is not only unauthorised access but potential control-plane compromise. A management product that is exposed and exploitable can become a launch point for broader endpoint compromise, policy tampering, or lateral movement.
Failure mechanism: The server accepts crafted requests without enforcing the intended access boundary, allowing the attacker to invoke functions that should have required authentication or stronger authorisation.
Impact: Attackers may be able to execute commands, alter management actions, or use the product’s trust position to expand access across managed systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Improper access control is directly about limiting what a requester can do. |
| IA-2 — Identification and Authentication (Organizational Users) | The flaw lets unauthenticated requests reach sensitive functions. | |
| SI-4 — System Monitoring | Post-exploitation review depends on detecting abnormal commands and tampering. | |
| Recommendation — Restrict management actions to the minimum permissions needed for each operator and service. Require strong authentication before any administrative function is exposed. Monitor the management plane for suspicious requests, process creation, and config changes. | ||
| CIS Controls v8 | 5 — Account Management | This issue is fundamentally about controlling who can access privileged functions. |
| 12 — Network Infrastructure Management | Exposure reduction and segmentation are central for internet-reachable management services. | |
| Recommendation — Limit and review administrative access paths to the EMS management interface. Segment management services and remove unnecessary external exposure. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a management-plane emergency, not a routine application bug. The highest-risk instances are those that are reachable from untrusted networks and tied to broad endpoint administration or security operations.
What to watch for: Focus on unusual request patterns to the EMS service, unexpected child processes, and any configuration or policy changes that were not part of approved administration activity. If you have a Vulnerability Management Guide in your programme, use its prioritisation logic to keep KEV-listed issues at the front of your remediation queue.