Your endpoint security agent is supposed to be the last line of defense. In this case, it was the delivery van. Attackers are now weaponizing FortiClient Enterprise Management Server itself to push malware to the very endpoints it was meant to protect — and they’re dressing it up as a Fortinet patch so users never blink.
How CVE-2026-35616 Turns Trusted Infrastructure Into a Malware CDN
The root cause is an improper access control flaw — CVE-2026-35616 — in FortiClient EMS that lets unauthenticated remote attackers execute arbitrary code via crafted requests. Fortinet confirmed active exploitation in early April and shipped emergency hotfixes for versions 7.4.5 and 7.4.6, while The Shadowserver Foundation reported roughly 2,000 internet-exposed EMS instances at the time. CISA moved fast, ordering federal agencies to patch by the end of that week.
EMS isn’t a side service — it’s the brain that pushes VPN policies and endpoint configurations to every workstation in the fleet. When attackers own EMS, they don’t need to phish anyone. They reconfigure the trusted update channel and let your own infrastructure deliver the payload. If you’re a midsize company running FortiClient to manage VPN access for remote workers, a single unpatched EMS instance means every laptop sitting behind that server is one policy push away from running attacker code under a signed Fortinet binary. Any product that pushes scripts to endpoints needs to be treated as Tier-0 infrastructure, not as a manageable appliance.
Why the EKZ Infostealer’s Delivery Chain Is the Real Story
The payload itself, tracked by Arctic Wolf as the EKZ infostealer, is unremarkable on paper — it scrapes credentials, credit cards, addresses, phone numbers, and cookies from Chromium-based and Firefox browsers, bypassing encrypted password protections and writing results to text files. The dangerous part is the delivery. According to Arctic Wolf, the intrusion starts with abusing endpoint APIs to perform administrative actions without authentication, then modifies the EMS configuration and VPN policies to inject malicious scripts. Seconds after endpoints establish an IPsec tunnel to a FortiGate firewall, the legitimate fortitray.exe launches batch scripts through Command Prompt, which in turn execute a base64-encoded PowerShell payload that downloads malware disguised as a Fortinet patch and exfiltrates data to an attacker-controlled VPS over HTTP.
Every EDR allowlist on the planet trusts fortitray.exe. Every SOC analyst sees PowerShell spawned by a Fortinet binary and assumes it’s an update routine. The attackers aren’t hiding from your detection stack — they’re hiding inside the assumptions baked into it. Imagine you’re a healthcare provider running a HIPAA-bound clinical platform where nurses authenticate into EHR systems via that same FortiClient VPN. Those harvested cookies bypass MFA without ever triggering a login alert, because the session token is already valid. Expect more 2026 campaigns to chain admin-plane vulnerabilities in management consoles with living-off-the-land execution under signed agent binaries — the era of “the malware is the malware” is ending.
What This Means for Supply Chain Trust in Software Updates
“Update delivered by the vendor’s own management server” used to be a strong trust signal. After this campaign, it isn’t. Arctic Wolf’s report explicitly notes that the payload was “presented as a Fortinet endpoint update and executed through FortiClient-managed VPN scripting workflows” — meaning the attackers exploited the social-engineering equity that Fortinet has built up with its own users. The cryptographic signing of fortitray.exe does nothing here, because the malicious payload is launched as a child process, not as a tampered binary.
The operational implication for engineering teams: any internal pipeline that auto-trusts vendor-pushed scripts needs the same provenance discipline you’d apply to a third-party software dependency. If you’ve ever built auditable supply chain tracking for physical goods, the same logic — verify the source, log every state transition, refuse silent updates — needs to apply to your endpoint management plane. In 2026, “who can push a script to my endpoint” is the new “who can sudo on my server,” and most orgs have no idea what that list looks like.
Detection Signals Worth Wiring Into Your SIEM Today
Arctic Wolf flagged a specific log artifact: the line Certificate not found in request header, followed within seconds by Certificate user: fortinet-ca2 … successfully updated. That sequence is a high-fidelity indicator of exploitation. Beyond that, the researchers recommend hunting for certificate-authentication anomalies, unexpected changes to Remote Access Profile configurations, new admin accounts, and logins originating from Tor exit nodes or VPS IP ranges.
Most SIEM rules around FortiClient focus on endpoint events, not the EMS admin plane. If you’re a SOC lead, the practical move this week is to ingest EMS admin logs, build a baseline for who normally creates Remote Access Profiles, and alert on any deviation. Pair that with egress monitoring for PowerShell processes spawned by Fortinet binaries reaching out to fresh VPS IPs over plain HTTP — that combination is almost never legitimate. Vendors will start shipping management-plane EDR coverage as a default in 2026, because the perimeter isn’t the laptop anymore, it’s the console that controls the laptop.
FAQ
Q: What is CVE-2026-35616 and how serious is it? A: It’s an authentication bypass in FortiClient Enterprise Management Server caused by improper access control. Unauthenticated remote attackers can execute arbitrary code via crafted requests, which Fortinet patched in versions 7.4.5 and 7.4.6 after confirming active exploitation in early April.
Q: What does the EKZ infostealer actually steal? A: According to Arctic Wolf, EKZ targets credentials, credit card details, addresses, phone numbers, and browser cookies from both Chromium-based browsers and Firefox. The cookie theft is the dangerous part — it lets attackers access accounts protected by multi-factor authentication without re-triggering an MFA prompt.
Q: How do I tell if my FortiClient EMS instance has been compromised?
A: Arctic Wolf points to a specific log signature: Certificate not found in request header followed seconds later by Certificate user: fortinet-ca2 … successfully updated. Also hunt for unexpected Remote Access Profile changes, new admin accounts, and admin logins from Tor or VPS IPs.
Key Takeaways
- Treat any management console that pushes scripts or configs to endpoints as Tier-0 infrastructure — patch windows for it should be measured in hours, not weeks.
- EDR allowlists for vendor binaries need to be paired with behavioral rules on what those binaries spawn; signed parent processes are no longer a clean trust signal.
- Cookie-stealing attacks bypass MFA silently, so session-binding controls (device-bound tokens, short-lived sessions) will matter more than another auth factor in the next 12 months.
- Internet-exposed admin planes are the 2026 attacker pivot of choice — if your EMS, vCenter, or orchestration console has a public IP, assume it will be the next CVE target.
- Wire the specific log indicators Arctic Wolf published into your SIEM this week; threat Intel only pays off when it survives the trip from PDF to detection rule.
- Expect a regulatory push, likely starting with CISA emergency directives, requiring federal contractors to inventory and harden endpoint management servers as critical assets.