.webp)
If your business uses Fortinet's endpoint security stack, there's an active exploitation campaign targeting FortiClient EMS right now that you should know about. Security researchers at Arctic Wolf published findings this week showing that attackers have been leveraging CVE-2026-35616 - a vulnerability in FortiClient Endpoint Management Server - to silently push malware to every endpoint under management. The malicious payload arrives disguised as a legitimate Fortinet patch update.
This one is worth paying attention to because the attack method is particularly effective: it doesn't target each device individually. Instead, it compromises the management server and lets that server do the work of distributing malware to all connected endpoints. If your organization manages 20 laptops through FortiClient EMS, all 20 can be hit from a single point of entry.
What Is CVE-2026-35616?
CVE-2026-35616 is an improper access control flaw in FortiClient Endpoint Management Server (EMS). In plain terms: it allows an unauthenticated attacker to send privileged API requests to the EMS server as if they had valid admin credentials. There's no login required, no phishing link to click - just network access to the server's management port.
Fortinet was first notified of this vulnerability on March 31, 2026 after it was observed being exploited in the wild. Patches have been released, but a significant number of deployments remain unpatched, which is why Arctic Wolf is seeing active attacks now.
FortiClient EMS is the central management console for organizations that use FortiClient on their endpoints - it pushes policies, manages VPN configurations, and can execute scripts on connected devices. That last capability is exactly what made this attack work.
How the Attack Actually Works
Understanding the mechanics here helps explain why this particular vulnerability is more serious than a typical unpatched application. Most exploits require a foothold on a device before they can spread. This one uses your security infrastructure as the delivery mechanism.
Step 1: Authentication Bypass
Attackers send specially crafted HTTP requests to the FortiClient EMS API. The server processes them as legitimate administrative actions despite the absence of valid credentials. Arctic Wolf's researchers were able to reproduce this consistently in a lab environment. The server logs show a telltale entry: "Certificate not found in request header" - followed within seconds by what appears to be a legitimate Fabric device update confirmation. If you see this pattern in your EMS logs, it warrants immediate investigation.
Initial exploitation activity in observed attacks was linked to logins originating from Tor exit nodes, specifically from IP addresses 185.220.101.15 and 192.42.116.14, within hours of the API bypass.
Step 2: Modifying VPN Script Configurations
Once attackers have administrative access to EMS, they modify the Remote Access Profile - the configuration that governs VPN behavior on managed endpoints. FortiClient EMS has a legitimate feature called "on_connect" that allows administrators to run scripts automatically when a device establishes a VPN tunnel. It's designed for things like mapping network drives or applying configuration changes when employees connect.
The attackers inserted a malicious script into this profile. Any endpoint that subsequently connects via IPsec VPN automatically runs the script - no interaction from the user required.
Step 3: Credential Stealer Deployment
The script is stored in FortiClient's standard VPN logging directory with GUID-based filenames to blend into legitimate log files. It decodes a base64-encoded PowerShell payload that downloads a file called FortiEndpoint_Patch.exe from an attacker-controlled server - named to look like a routine Fortinet update. The malware runs silently, waits 90 seconds, then exfiltrates its output via HTTP POST.
The process chain on an infected device looks like this: fortitray.exe launches cmd.exe, which runs powershell.exe, which downloads and executes FortiEndpoint_Patch.exe.
What EKZ Infostealer Actually Steals
Arctic Wolf named the payload EKZ Infostealer based on internal symbol names found in the decrypted code. It was previously undocumented before this campaign. Here's what it targets:
Browser Credentials
EKZ targets both Chromium-based browsers (Chrome, Edge) and Firefox/Gecko-based browsers including LibreWolf and Thunderbird. For Chrome, it doesn't just grab stored passwords - it specifically bypasses Chrome's v20 AES-256 encryption by calling IElevator::DecryptData to obtain the master key before decrypting the credential database. This is a more sophisticated extraction technique than older infostealers that relied on simpler methods.
For Firefox, it loads nss3.dll dynamically and extracts data from key4.db, logins.json, and cookies.sqlite.
Session Cookies - The MFA Problem
Harvested data includes saved passwords, autofill entries, credit card details stored in browsers, and session cookies. That last item is operationally significant. Session cookies represent an authenticated session that already exists - they're what keeps you logged into your email or business applications after you've completed your MFA challenge.
If an attacker has your session cookie for Microsoft 365, your bank portal, or your cloud accounting software, they can authenticate as you without needing your password or your MFA code. The MFA was already satisfied when you logged in originally. This is why credential theft through infostealers has become the preferred initial access method for many threat actors - stolen session cookies bypass the authentication controls businesses have invested in.
All harvested data gets written to a log.txt file in the ProgramData directory before exfiltration to the attackers' infrastructure.
How to Tell If You're Affected
There are several specific things to check if your organization runs FortiClient EMS. These are the indicators of compromise (IOCs) Arctic Wolf identified:
In FortiClient EMS Logs
- Look for "Certificate not found in request header" followed by a Fabric device update entry within seconds - this pattern indicates exploitation attempts against the API
- Check for unusual login events, particularly from IP addresses you don't recognize
- Review your Remote Access Profile and endpoint policies for on_connect or script directives you didn't configure
On Managed Endpoints
- Check C:\Program Files\Fortinet\FortiClient\logs\Trace\scripts\ for .cmd files with GUID-formatted names that you didn't create
- Look for a log.txt file in C:\ProgramData\ that appeared recently without explanation
- Search process history for FortiEndpoint_Patch.exe or p.exe - these are not legitimate Fortinet files
Network-Level Indicators
- Outbound HTTP POST traffic to 83.138.53.110
- Any inbound connections from 185.220.101.15 or 192.42.116.14 (Tor exit nodes associated with this campaign)
If you have a managed SOC or endpoint detection and response solution in place, your security team should be hunting for these IOCs now. If you don't have those controls, this is a reasonable prompt to evaluate whether you should.
What to Do Right Now
The steps here are clear. The hard part is getting them prioritized and executed quickly.
1. Patch FortiClient EMS Immediately
This is the primary fix. Fortinet has released hotfixes addressing CVE-2026-35616. Check your current FortiClient EMS version against Fortinet's PSIRT advisory for FG-IR-26-049 and upgrade to a patched version. Don't let this one sit in the backlog.
2. Restrict Access to EMS Port 8013
FortiClient EMS listens for management traffic on port 8013. There's no reason this port should be accessible from arbitrary internet addresses. Use your firewall to restrict inbound access to port 8013 to trusted IP ranges only - your office network, your IT team's IPs, or your VPN range. This is a sensible hardening step regardless of whether you've already patched.
3. Audit Your Remote Access Profiles
Log into FortiClient EMS and review every Remote Access Profile. Look specifically at on_connect and script directives. If you see any script entries you didn't configure, treat them as malicious and remove them before they execute on additional devices connecting to VPN.
4. Force Password Resets for Affected Users
If you find evidence of EKZ Infostealer execution on any endpoints, the users of those devices should reset passwords for every browser-stored credential - business email, cloud applications, banking portals, anything stored in Chrome, Edge, or Firefox. Since session cookies were also targeted, terminate active sessions for affected accounts in your identity platform (Azure AD, Google Workspace, etc.).
5. Review Your Vulnerability Management Process
This vulnerability was reported to Fortinet on March 31, 2026 and has been actively exploited since. A solid vulnerability management process catches and patches critical security tool updates within days, not months. If patches are sitting undeployed, that gap is worth addressing as a process issue.
The Broader Lesson: Security Tools Need Patching Too
There's an important point embedded in this attack: the tools you rely on for security are themselves software, and they have vulnerabilities. FortiClient EMS is a security product - it manages endpoint protection. But it ran unpatched in a lot of environments and became the attack vector.
This isn't specific to Fortinet. The same dynamic applies to every security vendor - antivirus products, SIEM platforms, firewall management consoles, backup software. All of it needs to be on your patch management radar. The 2026 Verizon DBIR found that software vulnerability exploitation is now the number one initial access vector, accounting for 31% of all breaches - up from 20% the previous year. Attackers are increasingly targeting trusted infrastructure rather than individual users.
A good managed IT services provider should be tracking patches across your entire stack, including security software, not just Windows updates. If your current setup doesn't include coverage of third-party application patching, it's worth asking why.
If You Need Help Assessing Your Fortinet Environment
If you're running FortiClient EMS and aren't sure whether you're on a patched version, or you want a second set of eyes on your VPN profile configurations and endpoint logs, we're happy to help. Our cybersecurity team works with Fortinet environments regularly and can help you work through the IOC checks and patching process. Reach us at (949) 381-1010 or through our contact page.
Frequently Asked Questions
Does this affect FortiClient VPN users directly, or just the EMS server?
The vulnerability is in FortiClient EMS - the server used to centrally manage FortiClient deployments. End users running FortiClient VPN on their laptops are affected only if their organization uses EMS to manage those devices. If your IT team pushes VPN configurations and policies through a management console, that's likely EMS. Individual FortiClient users who manage their own settings manually are not directly targeted by this exploit.
We have MFA enabled. Are we still at risk?
Yes. EKZ Infostealer specifically targets session cookies in addition to stored passwords. Session cookies represent sessions where MFA has already been satisfied. An attacker who obtains a valid session cookie can authenticate to your cloud applications without needing to pass an MFA challenge. Patching EMS and resetting passwords after any confirmed infection are the appropriate responses - MFA alone doesn't address this specific threat.
How do I check what version of FortiClient EMS we're running?
Log into your FortiClient EMS console. The version number is typically displayed in the top navigation or under System - Dashboard. Compare it against the versions listed in Fortinet's PSIRT advisory FG-IR-26-049 to see if your deployment is on a patched build. If you're not sure who manages your EMS server or how to access it, your IT team or managed IT provider should be able to tell you quickly.
What if we don't use FortiClient EMS but do use FortiGate firewalls?
CVE-2026-35616 is specific to FortiClient EMS, not FortiGate firewall appliances. If your organization uses FortiGate for perimeter security but doesn't centrally manage endpoints through FortiClient EMS, this particular vulnerability doesn't apply to your environment. Keeping FortiGate firmware current is still standard practice, but this specific exploit is not a FortiGate issue.
How long does patching FortiClient EMS typically take?
The actual patch application is usually 30 to 60 minutes for a straightforward upgrade, plus time for testing and validation. The harder part is often scheduling and approval, especially in environments with formal change management. Given active exploitation, this one warrants treating as an emergency patch - meaning the next available window, not the next monthly maintenance cycle.
