CVE-2026-35616: How to Find FortiClient EMS Instances on Your Network

A critical zero-day in Fortinet's endpoint management server has been actively exploited since late March. This post walks through how to identify FortiClient EMS instances on your network using RECON's investigation toolkit.

The Vulnerability

CVE-2026-35616 is an improper access control flaw (CWE-284) in the FortiClient EMS API. An unauthenticated attacker can send crafted requests that bypass API authentication and authorization, achieving remote code execution on the underlying server without valid credentials.

FortiClient EMS is the centralized management plane for FortiClient endpoint deployments. If an attacker owns EMS, they control endpoint security policy, VPN configurations, and compliance settings across every connected device.

The Shadowserver Foundation identified nearly 2,000 internet-exposed instances, concentrated in the U.S. and Europe. Shodan indexes approximately 1,000–1,400 publicly reachable instances.

Investigation Workflow

The first step isn't patching — it's knowing what you have. Below is a practical workflow using RECON's tools, demonstrated against Fortinet's official public demo instance — a maintained, non-vulnerable environment used here to illustrate the investigation process.

1. Port Scan: Find the Listeners

FortiClient EMS exposes HTTPS on port 443 and its management API on port 8013. Scan your management subnets for these ports, plus 10443 (alternate management). Any host with 8013 open warrants investigation — that's the EMS management endpoint.

Ports 443 (HTTPS) and 8013 (EMS management API) open. Port 10443 filtered.

2. TLS Inspect: Read the Certificate

Pull the certificate chain on open HTTPS ports. FortiClient EMS instances may present certificates with FortiClient-related strings in the subject or SAN fields. Self-signed certificates or unexpected issuers on management ports are red flags.

DigiCert-issued wildcard cert on TLS 1.3. In production, EMS servers often use Fortinet self-signed certs — a strong fingerprint.

3. HTTP Headers: Fingerprint the Server

Examine response headers for server signatures, security header patterns, and any Fortinet-specific markers in the response.

Apache with HSTS, CSP, and X-Frame-Options. Combined with port and TLS data, confirms whether a host is running FortiClient EMS.

4. DNS: Discover Forgotten Instances

Query internal DNS for common EMS naming patterns: ems.*, forticlient.*, fct-ems.*, fctems.*. Reverse DNS on management subnets can surface instances outside your asset inventory.

A record resolves to 96.45.36.106. Enumerate internal hostnames to find instances deployed outside normal change management.

Cross-Reference with External Data

If you find exposure you didn't expect, assume compromise until proven otherwise.

Remediation

1. Apply the hotfix for FortiClient EMS 7.4.5 and 7.4.6 immediately. Upgrade to 7.4.7 when available.
2. Restrict management ports. EMS API (8013) and admin interfaces should never face the public internet.
3. Audit for unauthorized changes. No IOCs published — detection relies on manual review. Check: endpoint policies, VPN profiles, firewall rules, admin accounts.
4. If compromised: Restore from a pre-compromise backup or rebuild. Patching alone does not remediate.

Sources

• → watchTowr: FortiClient EMS Zero-Day Active Exploitation
• → Tenable: CVE-2026-35616 Analysis
• → BleepingComputer: FortiClient EMS Flaw Exploited
• → The Hacker News: Fortinet Patches CVE-2026-35616
• → CISA KEV Catalog