CISA has added CVE-2026-35616, an improper access control flaw in Fortinet FortiClient EMS, to its Known Exploited Vulnerabilities (KEV) Catalog after confirming the bug is being exploited in the wild. The issue is a pre-authentication API bypass in FortiClient EMS versions 7.4.5 and 7.4.6 that lets a remote, unauthenticated attacker defeat certificate-based authentication by spoofing HTTP headers. Because FortiClient EMS sits on the management plane for endpoint security, a successful exploit can hand attackers authenticated API access to a server that controls every managed endpoint. Patch immediately and verify your build is no longer vulnerable.

What was added to the KEV catalog

On April 6, 2026, the Cybersecurity and Infrastructure Security Agency listed CVE-2026-35616 in its Known Exploited Vulnerabilities Catalog. An entry only earns a spot on that list when there is confirmed evidence of real-world exploitation, so this is not a speculative risk — adversaries are already using it against live targets.

Per the CVE record, the improper access control weakness affects Fortinet FortiClientEMS 7.4.5 through 7.4.6 and may allow an unauthenticated attacker to execute unauthorized actions. Fortinet has confirmed exploitation in the wild.

The KEV Catalog operates under Binding Operational Directive (BOD) 22-01, which compels Federal Civilian Executive Branch agencies to remediate listed CVEs by a fixed due date. CISA urges every organization, public or private, to treat KEV entries as top-priority fixes:

"This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise." — CISA

How the vulnerability works

FortiClient EMS (Enterprise Management Server) is built on a Django application that normally sits behind Apache with mod_ssl handling client-certificate authentication. In a correct deployment, Apache validates the client certificate and passes the outcome to the WSGI application through trusted environment variables.

According to the technical write-up published alongside Bishop Fox's detection tool, the flaw stems from two compounding mistakes:

  1. Header trust. The Django application treats user-controllable HTTP request headers — X-SSL-CLIENT-VERIFY and X-SSL-CLIENT-CERT — as equivalent to the trusted Apache mod_ssl WSGI environment variables. The Apache configuration never strips these inbound headers, so a remote client can supply them directly.
  2. No cryptographic verification. The certificate chain validation routine performs only Distinguished Name (DN) string matching. It never checks a cryptographic signature, so an attacker can forge a certificate whose DN strings match what the server expects.

Put together, an unauthenticated attacker can inject spoofed X-SSL-CLIENT-VERIFY and X-SSL-CLIENT-CERT headers carrying a forged certificate and obtain authenticated API access — without ever possessing a legitimate client certificate.

Proof of concept and safe detection

Bishop Fox's open-source checker confirms exposure non-destructively by comparing two requests against the /api/v1/fabric_device_auth/fortigate/init endpoint.

First, a baseline POST with no spoofed headers:


POST /api/v1/fabric_device_auth/fortigate/init

Then the same POST carrying the spoofed verify header but no certificate data:


POST /api/v1/fabric_device_auth/fortigate/init
X-SSL-CLIENT-VERIFY: SUCCESS

Sending X-SSL-CLIENT-VERIFY: SUCCESS with no certificate PEM data reaches the detection path but cannot authenticate, because no certificate chain is supplied. The server stays stable and keeps handling connections, which is what makes the test safe to run.

Interpreting the responses:

  • Vulnerable servers return different responses. The baseline yields HTTP 401 ("Certificate not found in request header"), while the spoofed request yields HTTP 500. That happens because contains_certificate() passes the gate, but validate_cert_chain() then crashes on the missing PEM data.
  • Patched servers return identical HTTP 401 responses for both requests. The hotfix adds Apache RequestHeader unset directives that strip the attacker-supplied SSL headers before they ever reach Django.

The full methodology and write-up are available in the Bishop Fox repository.

Who is affected

Any organization running Fortinet FortiClient EMS 7.4.5 or 7.4.6 should treat CVE-2026-35616 as an emergency. The blast radius is amplified by the product's role: compromising the management server can cascade to every endpoint under its management scope. Priority groups include:

  • Federal Civilian Executive Branch agencies (mandatory remediation under BOD 22-01)
  • State, local, tribal, and territorial (SLTT) government entities
  • Critical infrastructure operators
  • Enterprises using Fortinet for endpoint management
  • Managed service providers running Fortinet deployments for clients

Detection and mitigation

  • Patch now. Apply Fortinet's fixed build for CVE-2026-35616. The hotfix introduces Apache RequestHeader unset directives that strip the spoofable SSL headers.
  • Test your server. Use the Bishop Fox checker to confirm whether your EMS instance returns the vulnerable HTTP 500 divergence or the patched, identical HTTP 401 behavior.
  • Tighten exposure. Review network segmentation and access policy around FortiClient EMS so the management interface is not reachable from untrusted networks while you remediate.
  • Hunt for abuse. Search logs for inbound requests to /api/v1/fabric_device_auth/fortigate/init carrying X-SSL-CLIENT-VERIFY or X-SSL-CLIENT-CERT headers, plus anomalous authentication or privilege-escalation events on EMS instances.
  • Adopt KEV as policy. If KEV entries are not already your highest-priority remediation tier, make that change now — the framework applies just as well to non-federal organizations.

Fortinet stays in the crosshairs

This is far from the first Fortinet product to land in the KEV Catalog. The vendor's wide enterprise footprint across firewalls, VPN gateways, and endpoint management makes it a recurring target for both nation-state operators and financially motivated crews, who have historically used Fortinet bugs to gain initial access to government and critical-infrastructure networks. CVE-2026-35616 fits that pattern and is a reminder to keep a disciplined patch cadence across every Fortinet system you run. With this flaw already on the KEV list, the remediation clock is running — assess exposure, patch, and verify without delay.