--- schema: 1 kind: vulnerability title: FortiClient EMS CVE-2026-35616 + EKZ Infostealer kill chain headline: FortiClient EMS CVE-2026-35616 + EKZ Infostealer kill chain summary: "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 …" discovered_at: "2026-05-29T05:00:15Z" event_date: 2026-05-27 run_id: 2026-05-29-c7f56b00 priority: notable immediate_action: null tags: - vulnerabilities - actively-exploited - pre-auth - auth-bypass - infostealer - supply-chain - cisa-kev regions: - europe - switzerland - global sectors: - public-sector - finance - energy - telco entities: [] cves: - id: CVE-2026-35616 cvss: "9.1" epss: null type: auth-bypass vector: zero-click auth: pre-auth status: - exploited - cisa-kev - patch-available sources: - url: "https://arcticwolf.com/resources/blog/forticlient-ems-exploited-via-cve-2026-35616-to-deliver-ekz-infostealer-disguised-as-a-fortinet-patch/" publisher: Arctic Wolf — EKZ Infostealer campaign role: primary - url: "https://fortiguard.fortinet.com/psirt/FG-IR-26-099" publisher: Fortinet PSIRT FG-IR-26-099 role: corroborating - url: "https://thehackernews.com/2026/05/threat-actors-exploit-critical.html" publisher: "The Hacker News, 2026-05-28" role: corroborating closed_sources: [] evidence: - quote: Arctic Wolf has observed threat actors actively exploiting CVE-2026-35616 in the FortiClient EMS management API to deliver a novel infostealer payload publisher: Arctic Wolf - quote: "Threat actors leveraged this weakness to modify Remote Access Profile configurations and inject malicious PowerShell scripts into managed endpoints. The payload, designated EKZ Infostealer, was disguised as a legitimate Fortinet patch" publisher: Arctic Wolf Labs verification: multi-source sourcing_note: null confidence: high update_of: null references: [] deep_dive: true deep_dive_category: other org_triage: null watchlist_hit: false actions: [] migrated_from: briefs/2026-05-29.md --- **Background.** [`CVE-2026-35616`](https://fortiguard.fortinet.com/psirt/FG-IR-26-099) is the [improper-access-control (CWE-284)](https://nvd.nist.gov/vuln/detail/CVE-2026-35616) flaw in Fortinet FortiClient EMS 7.4.5 and 7.4.6 disclosed on 2026-04-04 and added to the [CISA KEV catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) on 2026-04-06; vendor coverage at disclosure focused on the auth-bypass primitive, with [Arctic Wolf's 2026-05-27 publication](https://arcticwolf.com/resources/blog/forticlient-ems-exploited-via-cve-2026-35616-to-deliver-ekz-infostealer-disguised-as-a-fortinet-patch/) 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`](https://msrc.microsoft.com/update-guide/en-US/vulnerability/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](https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2026/CVE-2026-35616.yaml) 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](https://attack.mitre.org/techniques/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](https://attack.mitre.org/techniques/T1195/002/) Compromise Software Supply Chain — EMS as distribution vector; [T1218](https://attack.mitre.org/techniques/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\`, `AppData\Roaming\Mozilla\Firefox\Profiles\` 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`](https://attack.mitre.org/techniques/T1555/003/) ([T1555.003](https://attack.mitre.org/techniques/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](https://attack.mitre.org/techniques/T1071/001/), [T1041](https://attack.mitre.org/techniques/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](https://fortiguard.fortinet.com/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\` (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.