Detect CVE-2026-35616 — Fortinet FortiClient EMS Improper Access Control Exploitation in Splunk
Detects exploitation attempts targeting CVE-2026-35616, an improper access control vulnerability (CWE-284) in Fortinet FortiClient Enterprise Management Server (EMS). This vulnerability is listed in CISA's Known Exploited Vulnerabilities catalog, indicating active exploitation in the wild. Attackers may leverage this flaw to bypass access controls on the EMS server, potentially enabling unauthorized configuration changes, endpoint agent manipulation, or lateral movement through managed endpoints.
MITRE ATT&CK
SPL Detection Query
index=* (sourcetype="fortinet:forticlient" OR sourcetype="fortinet:ems" OR sourcetype="syslog" host="*ems*")
| eval normalized_msg=lower(coalesce(message, _raw))
| where match(normalized_msg, "(access.denied|authorization.fail|privilege.escal|unauthorized|bypass|improper.access|access.control)")
OR (match(normalized_msg, "(forticlient|fcems|ems)") AND match(normalized_msg, "(error|fail|denied|reject)"))
| eval severity_indicator=case(
match(normalized_msg, "privilege.escal"), "CRITICAL",
match(normalized_msg, "bypass|unauthorized"), "HIGH",
match(normalized_msg, "access.denied|authorization.fail"), "MEDIUM",
true(), "LOW"
)
| stats count AS event_count, earliest(_time) AS first_seen, latest(_time) AS last_seen, values(src_ip) AS source_ips, values(dest_ip) AS dest_ips, values(severity_indicator) AS severity_indicators BY host, user, normalized_msg
| where event_count > 1
| sort - event_countSearches Fortinet FortiClient and EMS sourcetypes for access control failure patterns indicative of CVE-2026-35616 exploitation. Aggregates by host and user to surface repeated or escalating access violations. Severity indicator field aids triage prioritisation.
Data Sources
Required Sourcetypes
False Positives & Tuning
- EMS policy synchronisation events that generate transient access failures during update windows
- Legitimate admin role changes on the EMS server triggering access re-evaluation log entries
- FortiClient agent reconnection storms after network outages producing burst denial events
- Security scanner or vulnerability assessment tools probing EMS API endpoints
Other platforms for CVE-2026-35616
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1FortiClient EMS Unauthenticated API Endpoint Probe
Expected signal: Web server access log entries on EMS showing HTTP requests to API paths from an unknown source IP, with response codes logged. Network flow records show connections from test host to EMS port 8013.
- Test 2FortiClient EMS Privilege Escalation via Access Control Bypass (Simulated)
Expected signal: EMS audit log entries recording the low-privilege user's access attempts to admin-tier endpoints. Windows Security Event Log 4648 if token acquisition involved explicit credential use.
- Test 3FortiClient EMS Management Port Reconnaissance from External Network Segment
Expected signal: Network IDS/IPS alerts for port scan activity targeting EMS management ports. Firewall deny logs if EMS ports are restricted. NetFlow records showing probe connections from test segment to EMS IP.
- Test 4FortiClient Agent Mass Policy Modification via Compromised EMS
Expected signal: EMS audit log entry recording policy creation event with the admin token's associated username. API access log entry for POST to /api/v1/policies. Managed endpoint logs showing receipt of new policy push if EMS propagates it.
Response Playbook
Triage
- Identify the FortiClient EMS server version(s) in your environment and cross-reference against Fortinet's PSIRT advisory FG-IR-26-099 to confirm whether installed versions are within the affected range.
- Review FortiClient EMS server logs (typically under /var/log/ems/ or the EMS web console audit log) for anomalous access patterns: repeated authentication failures, unexpected API calls, or access from unknown source IPs within the last 72 hours.
- Correlate EMS log anomalies with network flow data to identify any unusual inbound connections to EMS management ports (default 8013, 8014, 443) from IPs not in your approved management allowlist.
- Check the EMS console for any unauthorised policy changes, new endpoint group memberships, rogue endpoint registrations, or configuration modifications that cannot be attributed to known administrators.
- Assess whether the EMS server is internet-exposed or reachable from untrusted network segments — exposure significantly elevates risk given KEV status.
Containment
- If exploitation is confirmed or strongly suspected, immediately isolate the FortiClient EMS server from the network (remove from DMZ or restrict via firewall ACL to management-only CIDRs) to prevent further attacker interaction with managed endpoints.
- Revoke and rotate all EMS administrator credentials, API tokens, and service account passwords. Audit all EMS admin accounts for unauthorised additions and disable any unrecognised accounts immediately.
- Apply Fortinet's official patch or workaround from FG-IR-26-099 on an emergency basis, following your organisation's emergency change process. Confirm patch integrity via Fortinet's published hash before deployment.
Evidence Collection
- Preserve EMS server audit logs, application logs, and web server access logs to an immutable, analyst-controlled location before any remediation that could overwrite them. Include at minimum the 7 days prior to detection.
- Capture a memory image and disk snapshot of the FortiClient EMS server if active compromise is suspected, to support forensic investigation of any persistence mechanisms, webshells, or dropped binaries.
- Export network flow records (NetFlow/IPFIX) and firewall connection logs for the EMS server's IP for the same 7-day window to reconstruct attacker reconnaissance and lateral movement paths.
Escalation Criteria
- !Escalate to incident response leadership immediately if evidence of post-exploitation activity is found: e.g., new admin accounts on EMS, modified endpoint policies deploying malicious scripts, or C2 traffic originating from EMS-managed endpoints.
- !Escalate and invoke crisis communications if the FortiClient EMS server manages endpoints across multiple business units or client environments, given the potential for the vulnerability to be used as a pivot point for wide-scale lateral movement or ransomware deployment.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
FortiClient EMS audit log entries (EMS web console → Logs → Audit) showing access events from unexpected source IPs or usernames around the time of suspected exploitation - >
Web server access logs on the EMS host (Apache/nginx) showing unusual HTTP methods, paths, or status codes — particularly 200 responses to paths that should require elevated privileges - >
Windows Event Log (if EMS runs on Windows Server): Event ID 4625 (failed logon), 4648 (explicit credential logon), and 4720 (new account created) on the EMS host - >
Network capture or flow records showing connections to EMS management ports (8013, 8014) from IPs outside the management allowlist - >
File system changes on EMS server — new files in web root, scheduled tasks, registry run keys, or services created after the exploitation window
Tuning Guidance
Start by establishing a baseline of legitimate EMS management source IPs and admin usernames, then scope detection to flag events from sources outside that baseline. EMS environments with frequent policy pushes or large endpoint fleets will generate higher volumes of access events — set minimum event-count thresholds (e.g., >=3 failures per 15 minutes from a single source) to reduce noise. If your EMS is only accessible from a dedicated jump host or management VLAN, add a NOT condition excluding those known-good CIDRs. Tune severity field values in EMS logs to match your vendor version's log schema — field names and values may differ between EMS versions. Disable or suppress detections during approved maintenance windows where bulk agent reconnects are expected.
Hunting Queries
30-day retrohunt for persistent low-volume access control failures from single source IPs against FortiClient EMS, which may indicate slow-and-low exploitation attempts or adversary reconnaissance ahead of a more aggressive exploitation phase.
CommonSecurityLog
| where TimeGenerated > ago(30d)
| where DeviceVendor =~ "Fortinet"
| where DeviceProduct has_any ("EMS", "FortiClient")
| summarize EventCount=count(), UniqueSources=dcount(SourceIP), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated) by SourceIP, Activity
| where EventCount > 5 and UniqueSources < 3
| order by EventCount descindex=* sourcetype="fortinet:ems" earliest=-30d
| stats count AS hit_count, dc(src_ip) AS unique_sources, min(_time) AS first_seen, max(_time) AS last_seen BY src_ip, action
| where hit_count > 5 AND unique_sources < 3
| sort - hit_countAtomic Red Team Tests
Simulates an attacker probing FortiClient EMS API endpoints without valid credentials to identify endpoints affected by the improper access control vulnerability. Lab use only — requires a test EMS instance.
Command
TARGET_EMS="http://ems-lab.local:8013"; for ENDPOINT in /api/v1/endpoints /api/v1/policies /api/v1/users /api/v1/config; do echo "[*] Probing $ENDPOINT"; curl -sk -o /dev/null -w "%{http_code} $ENDPOINT\n" "${TARGET_EMS}${ENDPOINT}"; doneCleanup
No cleanup required — read-only probe with no side effects on the target.Expected Telemetry
Web server access log entries on EMS showing HTTP requests to API paths from an unknown source IP, with response codes logged. Network flow records show connections from test host to EMS port 8013.
Expected Detection
CommonSecurityLog or EMS audit log entries showing repeated API access attempts from an unknown source IP, triggering the access failure pattern rules.
Simulates an authenticated low-privileged user attempting to access administrative EMS API endpoints that should be restricted to admin roles, testing whether access control enforcement is effective.
Command
$EMS_URL = 'https://ems-lab.local'; $LowPrivToken = 'REPLACE_WITH_LOWPRIV_TOKEN'; $AdminEndpoints = @('/api/v1/admin/config', '/api/v1/admin/users', '/api/v1/admin/policies/global'); foreach ($ep in $AdminEndpoints) { $resp = Invoke-WebRequest -Uri "$EMS_URL$ep" -Headers @{Authorization="Bearer $LowPrivToken"} -SkipCertificateCheck -ErrorAction SilentlyContinue; Write-Output "$ep -> $($resp.StatusCode)" }Cleanup
Remove test user token from EMS after testing. No persistent changes made to EMS configuration.Expected Telemetry
EMS audit log entries recording the low-privilege user's access attempts to admin-tier endpoints. Windows Security Event Log 4648 if token acquisition involved explicit credential use.
Expected Detection
EMS access denial events for the test user's requests to admin endpoints, surfaced by Splunk or Sentinel queries filtering on authorization failure patterns.
Simulates adversary network reconnaissance against FortiClient EMS management ports from a network segment that should not have access, testing both network controls and detection coverage.
Command
TARGET="ems-lab.local"; nmap -sV -p 443,8013,8014,10443 --script http-title,http-headers "$TARGET" -oN /tmp/ems_recon_$(date +%Y%m%d_%H%M%S).txt; echo '[*] Scan complete. Results saved.'Cleanup
rm -f /tmp/ems_recon_*.txtExpected Telemetry
Network IDS/IPS alerts for port scan activity targeting EMS management ports. Firewall deny logs if EMS ports are restricted. NetFlow records showing probe connections from test segment to EMS IP.
Expected Detection
Network-layer detection rules alerting on port scanning of known EMS management ports from unauthorised network segments. Chronicle or QRadar correlation rules for reconnaissance-followed-by-access-failure patterns.
Simulates post-exploitation scenario where an attacker with access to EMS attempts to push a modified policy to all managed endpoints, which could be used to deploy malicious configurations or disable security controls at scale.
Command
EMS_URL='https://ems-lab.local'; ADMIN_TOKEN='REPLACE_WITH_ADMIN_TOKEN'; curl -sk -X POST "$EMS_URL/api/v1/policies" -H "Authorization: Bearer $ADMIN_TOKEN" -H 'Content-Type: application/json' -d '{"name": "ATOMIC_TEST_POLICY", "description": "Test policy - delete after atomic test", "endpoints": "all"}' | python3 -m json.toolCleanup
Manually delete the ATOMIC_TEST_POLICY from EMS console under Endpoint Policy > Policy Management after test completion.Expected Telemetry
EMS audit log entry recording policy creation event with the admin token's associated username. API access log entry for POST to /api/v1/policies. Managed endpoint logs showing receipt of new policy push if EMS propagates it.
Expected Detection
EMS audit log monitoring rule detecting unexpected policy creation outside of approved change windows, or policy creation by an account not in the authorised policy-admin group.