Fortinet FortiClient EMS 7.4.5/7.4.6 — improper-access-control on X-SSL-CLIENT-VERIFY header lets unauth attacker spoof mTLS state and reach management API; ITW exploited to push EKZ Infostealer per Arctic Wolf 2026-05-27

FortiClient EMS CVE-2026-35616 + EKZ Infostealer kill chain

Background. CVE-2026-35616 is the improper-access-control (CWE-284) flaw in Fortinet FortiClient EMS 7.4.5 and 7.4.6 disclosed on 2026-04-04 and added to the CISA KEV catalog on 2026-04-06; vendor coverage at disclosure focused on the auth-bypass primitive, with Arctic Wolf's 2026-05-27 publication being the first public exploitation-chain narrative tying the bypass to a downstream credential-theft payload (EKZ Infostealer). The vulnerability class — header-spoofing trust against a fronting reverse proxy — is the same shape as Microsoft's CVE-2026-45659 (separate product, same X-Forwarded-* trust pattern), and the EKZ delivery via the trusted EMS management channel is a defender-relevant escalation of the trusted-update-channel-as-supply-chain pattern previously associated with vendor-update vehicles.

Vulnerable component. The FortiClient EMS server's management API trusts the HTTP request header X-SSL-CLIENT-VERIFY to convey client-certificate validation state — the ProjectDiscovery Nuclei template for CVE-2026-35616 sends exactly that header with value SUCCESS as the entire exploit payload. The intended deployment model is that a fronting reverse proxy or load balancer performs the mutual-TLS handshake and stamps that header into the upstream request before forwarding to EMS. The server does not independently confirm that the negotiating peer presented a valid client certificate; it accepts the header as-is. An unauthenticated attacker on a network path to the EMS management plane spoofs X-SSL-CLIENT-VERIFY: SUCCESS and reaches privileged API endpoints without authenticating. CVSS:3.1 base 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N). EPSS 43.2 % at the 97.6th percentile.

Exploitation prerequisites. Network reach to the EMS management API (typically over the management VLAN or, in misconfigured deployments, directly on the internet); a vulnerable EMS server version 7.4.5 or 7.4.6; no other authentication. AD-joined EMS, MFA-protected EMS console accounts, and other authentication controls applied to interactive logons are not in the request path the spoofed header bypasses.

Exploitation chain in the Arctic Wolf campaign. Mapped to MITRE ATT&CK throughout. Initial access: header-spoofing against EMS management API (T1190 Exploit Public-Facing Application). Persistence and distribution: attackers modify Remote Access Profile configurations through the now-privileged API endpoint to push an Update task to managed FortiClient endpoints — the malicious PowerShell payload is delivered through the EMS update channel under the trusted fortitray.exe parent process and is therefore signed in the operational sense (T1195.002 Compromise Software Supply Chain — EMS as distribution vector; T1218 System Binary Proxy Execution via the trusted FortiTray binary). The PowerShell payload fetches FortiEndpoint_Patch.exe, presented to operators and AV as a legitimate Fortinet patch — actually the EKZ Infostealer. Defense evasion: EKZ copies itself into per-browser profile directories under each user's AppData\Local\Google\Chrome\User Data\<profile>, AppData\Roaming\Mozilla\Firefox\Profiles\<profile> and equivalents for Microsoft Edge, LibreWolf, Waterfox, Pale Moon, Thunderbird, defeating elevation-validation checks that gate access to encrypted credential and cookie stores via nss3.dll (T1555.003 Credentials from Web Browsers). Collection and exfiltration: encrypted credential stores and session cookies dumped, then exfiltrated via HTTP POST to actor infrastructure (T1071.001, T1041). The single-server-to-fleet cascade is the campaign's defining property: one compromised EMS server simultaneously distributes EKZ to every managed endpoint in the deployment.

Affected and patched versions. Affected: FortiClient EMS 7.4.5 and 7.4.6 — only those two builds; earlier branches and 7.4.7+ are not vulnerable. Patched: FortiClient EMS 7.4.7. The Fortinet PSIRT FG-IR-26-099 advisory carries the vendor's complete affected-version matrix and the out-of-band hotfix references for organisations that cannot move to 7.4.7 in their change window.

Detection concepts. None of these require IOC sharing — they are behavioural patterns against the campaign's mechanics.

• EMS management-API access without proper mTLS handshake. Where the EMS server logs X-SSL-CLIENT-VERIFY along with peer-certificate fingerprint, alert on any request carrying SUCCESS with no fingerprint or a fingerprint not from the operator-trusted CA. Where the reverse proxy in front of EMS logs the mTLS state, alert on EMS log records claiming success that do not correspond to a proxy log line with a matched negotiation.
• Unsolicited Remote Access Profile modification. Alert on any modification to RAP / endpoint-policy XML or its API equivalents that was not initiated from an EMS admin console session in the change-management window.
• Push-from-EMS installers that are unsigned or have anomalous filenames. EMS-pushed installers that are neither FortiClientSetup_*.exe nor a vendor-signed update should never reach a managed endpoint; alert on Sysmon EID 1 where parent process is the FortiClient managed-service binary and child is an unsigned binary with --silent install flags. The fake FortiEndpoint_Patch.exe name from this campaign deviates from the genuine FortiClientSetup_*.exe naming convention.
• Browser-profile-directory writes from non-browser processes. Sysmon EID 11 (FileCreate) targeting AppData\Local\Google\Chrome\User Data\<profile> (and equivalents), where the source image is not the browser binary itself, the parent process is not a known package manager, and the file extension is .exe / .dll. This is the EKZ self-copy primitive.
• fortitray.exe spawning PowerShell with -EncodedCommand / -enc. PowerShell -enc from a Fortinet trusted-binary parent process is the in-campaign behaviour Arctic Wolf documents and is not expected operationally.
• Outbound HTTP POST from an EMS-service account to non-Fortinet endpoints. Easy network-layer signal on egress firewall / SWG logs.

Hardening. Patch is the only complete remediation. Immediately upgrade FortiClient EMS to 7.4.7. While the change window is being scheduled, compensating controls: (1) block EMS management API ports from the internet completely, restricting access to a defined management network; (2) enforce mTLS termination at the proxy and have the proxy strip / overwrite the X-SSL-CLIENT-VERIFY header before forwarding to EMS, removing the spoof primitive entirely; (3) require admin-access MFA for the EMS console and rotate EMS service-account credentials post-patch; (4) audit all RAP / endpoint-policy XML against a known-good baseline. Post-incident: assume managed endpoints in any environment running 7.4.5 / 7.4.6 may have received EKZ; rotate cached browser credentials for sensitive accounts and treat session cookies in managed-endpoint browser stores as compromised.

FortiClient EMS CVE-2026-35616 actively exploited to push EKZ Infostealer through trusted endpoint-management channel

Arctic Wolf Labs published technical evidence on 2026-05-27 of an in-the-wild campaign abusing CVE-2026-35616, the CWE-284 improper-access-control flaw in Fortinet FortiClient EMS 7.4.5 and 7.4.6 (CVSS 9.1; on CISA KEV since 2026-04-06). The vulnerable code path trusts the X-SSL-CLIENT-VERIFY HTTP header set by a fronting reverse proxy or load balancer instead of validating client-certificate state itself; an unauthenticated attacker on the network spoofs the header to reach privileged management APIs. In the observed campaign, attackers modify Remote Access Profile configurations to push a PowerShell payload signed under the trusted fortitray.exe binary that fetches FortiEndpoint_Patch.exe — actually the EKZ Infostealer. EKZ copies itself into Chromium/Gecko browser-profile directories (Chrome, Microsoft Edge, Firefox, LibreWolf, Waterfox, Pale Moon, Thunderbird) to clear elevation-validation checks, then dumps encrypted credential and cookie stores via nss3.dll. Compromise of a single EMS server cascades to every managed endpoint. Patch is FortiClient EMS 7.4.7.

Why it matters to us: FortiClient EMS is widely deployed across Swiss federal and cantonal network-security estates and across EU public-sector networks. Deep-dive treatment in § 5 below.

CVE-2026-35616 — Fortinet FortiClient EMS pre-auth bypass, exploited to push EKZ Infostealer down the management channel

If you did nothing this week: an attacker with a working pre-auth bypass against your FortiClient EMS management API can — and per Arctic Wolf, is — modifying Remote Access Profile configurations and injecting malicious PowerShell into every managed endpoint, with the payload disguised as a legitimate Fortinet patch.

Arctic Wolf observed active exploitation of CVE-2026-35616 (CVSS 9.1, first covered 2026-05-29, Fortinet PSIRT FG-IR-26-099, now CISA KEV-listed) in which the EKZ Infostealer was distributed through the trusted endpoint-management plane. This is the operationally important framing for this audience: the malware arrives over the channel the endpoint is built to trust, so signature-trust and "it came from EMS" heuristics fail open. Any public-sector, finance, energy or telco estate running FortiClient EMS should patch, then hunt for unexpected Remote Access Profile changes and PowerShell pushed from the EMS server in the exposure window.