FortiClient EMS CVE-2026-35616: the hotfix window was not the dangerous part

The emergency hotfix Fortinet shipped for CVE-2026-35616 on Saturday 4 April did not fix the bug. It blocked the route attackers were using to reach it. That distinction had a shelf life of three days, and how organisations handled those three days is the part worth revisiting.

The flaw is an unauthenticated API authentication bypass in FortiClient EMS 7.4.5 and 7.4.6, carried in Fortinet's advisory FG-IR-26-099. Fortinet scored it 9.1. NVD scored the same CVE 9.8. CISA added it to the Known Exploited Vulnerabilities catalogue on Monday 6 April and set the remediation deadline at 9 April.

The complete code fix arrived in FortiClient EMS 7.4.7 on 7 April. Fortinet then re-released 7.4.7 on 10 April, because the first build risked data loss if an upgrade failed and you retried it.

So the window everyone worried about — running on a vendor fix that Bishop Fox assessed as incomplete — closed faster than the one that followed, in which the complete fix existed but was not yet safe to install twice. Five months on, that inversion is the lesson.

What the hotfix actually changed

Bishop Fox's teardown of the bypass explains why Fortinet could ship something over a weekend. FortiClient EMS runs a Django application behind Apache. The application read client certificate verification status from HTTP headers — X-SSL-CLIENT-VERIFY and X-SSL-CLIENT-CERT — and consulted those before the trusted mod_ssl WSGI environment variables that Apache populates itself. An unauthenticated attacker could simply set the headers and be believed.

The certificate validation behind them was no better. According to Bishop Fox, it performed string matching on Distinguished Names against embedded Fortinet root CAs with no X.509 signature verification at all. A forged certificate carrying the right DN string, generated with stock openssl, passed.

The hotfix added Apache RequestHeader unset directives to strip those headers before Django ever saw them. That is a sensible emergency change: no application logic touched, very little to regress, deployable at speed. It also left the certificate chain validation exactly where it was. Bishop Fox's reading is that the code-level repair to the authentication logic was deferred to 7.4.7.

This is the honest shape of a hotfix. It is not a smaller patch. It is a different class of control — configuration closing the reachable path while the defective code sits untouched underneath.

A hotfix that strips the attacker's delivery mechanism is not the same as a patch that removes the flaw. Treat the first as a tourniquet with a stated expiry, and book the second into the change calendar before you close the ticket.

CISA said something close to this in the catalogue itself, which is unusual. Alongside the boilerplate required action, the KEV note for CVE-2026-35616 tells agencies to check internet-accessible Fortinet products for signs of compromise and to apply any final mitigations from the vendor as soon as they become available. KEV notes do not ordinarily anticipate a further fix. This one did.

A three-day clock

The deadline deserves attention on its own. When CISA listed the 2024 FortiClient EMS SQL injection, CVE-2023-48788, it allowed 21 days. For CVE-2026-35616 it allowed three. For CVE-2026-21643, the second FortiClient EMS flaw added a week later on 13 April, it also allowed three. Whatever the catalogue's default used to be, Fortinet management infrastructure is no longer getting it.

Note the timing of the disclosure. Fortinet went public on the Saturday of the Easter weekend, with exploitation already running since 31 March. Benjamin Harris of watchTowr, whose sensors caught it first, put the attacker logic plainly to CyberScoop: "Attackers have shown repeatedly that holiday weekends are the best time to move."

Now read the right-hand column of that table. For almost the whole incident there was something deployable. The gap that actually cost organisations was not 4 to 7 April at all.

What happened to the ones who waited

Arctic Wolf reported in late May that it had found a campaign exploiting CVE-2026-35616 against EMS servers still unpatched roughly seven weeks after 7.4.7 shipped. The attack chain is the best argument available for reclassifying EMS as tier-0 infrastructure.

Having bypassed authentication, and logging in from Tor exit nodes and VPS hosts according to Arctic Wolf, the operators edited a Remote Access Profile so that a script executed whenever a managed endpoint brought up its VPN tunnel. A base64-encoded PowerShell launcher then fetched a credential stealer Arctic Wolf tracks as EKZ, which harvests passwords, cookies and autofill data from Chromium and Gecko browsers.

The payload was named FortiEndpoint_Patch.exe.

Sit with that. The compromise travelled down the management platform's own trusted software distribution path, during the precise weeks when every FortiClient administrator in the world was expecting patches, wearing a filename built to survive a glance at a process list.

Bishop Fox catalogued what else the bypass reached: authenticated API access at certificate-user privilege across sixteen endpoints. Enough to quarantine managed hosts, rotate JWT secrets, download ZTNA private keys, revoke certificates and register FortiGate devices. Upgrading reverses none of it.

Cleaning up, if you have not

Exposure estimates differ by method, and both come from organisations with a commercial interest in the answer. Shadowserver's scanning found roughly 2,000 reachable EMS instances, concentrated in the United States and Germany. Censys reported around 10,000 exposed EMS hosts, of which 3,835 served banners matching affected versions. Banner matching over-counts. Either way, the population is not small.

1. Check the build number, not the version string. Fortinet's release notes state that 7.4.7 build 2193.M is no longer vulnerable, against bug ID 1277073. But 2193.M is the build carrying the data-loss upgrade defect. You want 7.4.7 build 2194.M or later. A hotfixed 7.4.5 or 7.4.6 is still a hotfixed host.
2. Verify from outside the box. Bishop Fox published a non-intrusive check: a vulnerable server returns HTTP 500 when sent the spoofed headers, a fixed one returns a consistent 401.
3. Hunt backwards to 31 March. Arctic Wolf points at two EMS log events in sequence — a message that no certificate was found in the request header, followed by a successful certificate user update for fortinet-ca2.
4. Audit every Remote Access Profile for scripts that fire on tunnel establishment, and diff them against a known-good export rather than eyeballing the console.
5. Rotate what the bypass could read. ZTNA private keys, JWT secrets, issued certificates. If your EMS was internet-reachable and unpatched into May, assume disclosure instead of hoping.
6. Restrict TCP 8013 and the admin interface to a management network. Arctic Wolf recommends this as a standing control, not an incident measure.

FortiClient EMS now holds three KEV entries. CVE-2023-48788 from 2024, which CISA flags as used in ransomware campaigns. CVE-2026-21643, added on 13 April this year. And this one. Three unauthenticated routes to code execution on a platform whose whole function is pushing configuration and software to every endpoint you own.

If your vulnerability management programme still files EMS under endpoint tooling, it is in the wrong tier. It is a distribution channel with reach into every managed device, and the compensating control that matters most is not a header-strip directive from the vendor — it is making sure the thing is not answering the internet when the next Saturday advisory lands.