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.