Two critical, unauthenticated remote code execution vulnerabilities in Fortinet’s FortiClient Endpoint Management Server were actively exploited within weeks of each other. The first was a SQL injection flaw that had been patched months earlier but wasn’t exploited until late March. The second was a true zero-day, exploited before Fortinet even published its advisory, with attackers timing the initial exploitation for the Easter holiday weekend.
If you’re running FortiClient EMS in your environment, this is an emergency response situation. If you’re responsible for assessing or advising organizations that do, there are some important lessons here about how endpoint management infrastructure has become a priority target.
The Timeline#
The timeline played out as follows:
February 6, 2026: Fortinet discloses CVE-2026-21643, a critical SQL injection vulnerability (CVSS 9.1) in FortiClient EMS v7.4.4 affecting the multi-tenant deployment feature. A fix is included in version 7.4.5.
Early March 2026: Bishop Fox publishes a technical deep dive on CVE-2026-21643, detailing practical exploitation paths. The analysis reveals that the HTTP header used for tenant identification is passed directly into a database query without sanitization, and this happens before any authentication check.
March 24-25, 2026: Defused Cyber detects the first active exploitation of CVE-2026-21643 through their honeypot infrastructure, roughly seven weeks after the patch was available.
March 31, 2026: watchTowr’s sensors capture the first exploitation attempts against a new, previously unknown vulnerability in FortiClient EMS. This is CVE-2026-35616, a zero-day.
April 4, 2026 (Easter Saturday): Fortinet publishes an emergency advisory for CVE-2026-35616 (CVSS 9.1) and releases out-of-band hotfixes. The advisory confirms active exploitation in the wild.
April 6, 2026 (Easter Monday): CISA adds CVE-2026-35616 to the Known Exploited Vulnerabilities catalog with a remediation deadline of April 9.
Two critical unauthenticated flaws in the same product, both exploited in the wild, within a two-week window.
The Vulnerabilities#
CVE-2026-21643 is a SQL injection flaw in the FortiClient EMS web interface. It affects version 7.4.4 specifically, which refactored the middleware stack for multi-tenant deployments. An unauthenticated attacker who can reach the EMS web interface over HTTPS can smuggle SQL statements through the “Site” header in an HTTP request. No credentials, no user interaction, one crafted request.
Successful exploitation gives the attacker access to the backend PostgreSQL database, including admin credentials, the full endpoint inventory, security policies, and endpoint authentication certificates.
CVE-2026-35616 is an improper access control vulnerability in the FortiClient EMS API. It affects versions 7.4.5 and 7.4.6 (notably, the versions that patched the first flaw). An unauthenticated attacker can bypass API authentication and authorization entirely through crafted requests, achieving code execution on the underlying server.
Researchers have not confirmed whether the same threat actor is behind both exploitation campaigns, and it’s unknown whether the two flaws are being chained together. But the practical effect is the same: FortiClient EMS has been under sustained attack for weeks regardless of which version you’re running.
Why EMS Is a High-Value Target#
FortiClient EMS isn’t just another server in the environment. It’s the central management plane for your entire endpoint fleet. It enforces security policies, manages VPN configurations, controls application firewall rules, and governs endpoint compliance posture across every managed device.
A compromised EMS server gives an attacker the ability to:
- Push malicious security policies to every managed endpoint
- Modify VPN configurations to redirect traffic
- Disable endpoint protections across the fleet
- Access endpoint authentication certificates for lateral movement
- Harvest the complete device inventory for reconnaissance
This makes EMS a force multiplier for attackers. Compromising one server potentially gives them control over every endpoint it manages. That’s not a vulnerability in a leaf node. It’s a vulnerability in the root of your endpoint security architecture.
The Fortinet Targeting Pattern#
Put this in context. Fortinet products are among the most widely deployed network security solutions in the world. That market position makes them an attractive target for the same reason Windows was the primary target for malware in the 2000s: the sheer volume of deployments means a single vulnerability yields massive reach.
CISA has flagged 24 Fortinet vulnerabilities as actively exploited to date. Thirteen of those were used in ransomware attacks. State-sponsored groups including Salt Typhoon have exploited FortiClient EMS flaws to breach telecommunications providers. This is an established pattern, not an anomaly.
The Shadowserver Foundation is currently tracking approximately 2,000 FortiClient EMS instances exposed to the internet globally, with the majority concentrated in the United States and Europe. That’s 2,000 potential entry points into enterprise endpoint management infrastructure.
The Holiday Weekend Factor#
watchTowr’s CEO Benjamin Harris made a point worth repeating. The timing of the zero-day exploitation ramping up on March 31, the start of the Easter holiday weekend in many countries, is likely not coincidental.
Holiday weekends create a predictable window where security teams are at reduced capacity, on-call engineers are distracted, and the gap between compromise and detection stretches from hours to days. Attackers know this. They’ve demonstrated it repeatedly.
The initial exploitation behavior that watchTowr captured was “low and slow,” careful, targeted activity. As the holiday weekend progressed and the zero-day became more widely known, the activity shifted to opportunistic, indiscriminate scanning. That’s the typical pattern: targeted exploitation first, mass exploitation once the window starts closing.
For practitioners, the lesson is operational. Your patch triage process needs to account for the fact that zero-days don’t wait for business hours. If you rely on a “we’ll handle it on Tuesday” approach to weekend advisories, you’re giving attackers exactly the head start they’re counting on.
What to Do Right Now#
If you’re running FortiClient EMS 7.4.5 or 7.4.6: Apply the hotfix for CVE-2026-35616 immediately. Fortinet has published hotfix instructions in the EMS release notes for both versions. Don’t wait for version 7.4.7. The hotfix is sufficient to prevent exploitation entirely.
If you’re still running FortiClient EMS 7.4.4: You’re exposed to CVE-2026-21643. Upgrade to 7.4.5 or 7.4.6, then apply the CVE-2026-35616 hotfix. You need both.
If you’re running FortiClient EMS 7.2 or below: Neither vulnerability affects your version. But you should still evaluate your upgrade path and exposure.
For all versions, check your exposure. FortiClient EMS should not be directly exposed to the internet. If your EMS management interface is reachable from outside your network, that’s a configuration issue independent of these CVEs.
Audit for signs of compromise. Fortinet has not published indicators of compromise for either vulnerability. Detection relies on log review and configuration auditing. Specifically, review:
- Endpoint security policies for unauthorized changes
- VPN configuration profiles for modifications
- Application firewall rules for unexpected entries
- Administrator accounts for newly created or modified credentials
- Endpoint compliance configurations for weakened settings
- API access logs for anomalous request patterns
If compromise is suspected: Don’t try to clean the affected instance in place. Restore from a known-good backup taken before the likely compromise window, or rebuild the EMS instance entirely and migrate the data to it. When you can’t confidently verify integrity, a full rebuild is the most defensible approach.
The Compliance Angle#
For organizations with FortiClient EMS managing endpoints in PCI DSS scope, both vulnerabilities create specific compliance considerations.
Requirement 6.3.3 mandates that critical and high-severity patches be applied within a defined timeframe (the standard says “promptly,” and most organizations define this in their patching policy, typically within 30 days for critical patches). A zero-day with confirmed active exploitation compresses that timeline to “immediately.” If your patching policy doesn’t account for emergency out-of-band patches, this is the scenario that exposes that gap.
Requirement 5.2 requires that anti-malware mechanisms are maintained and actively running. FortiClient EMS is the management server that enforces this for FortiClient-managed endpoints. If the management server is compromised, the integrity of every endpoint’s anti-malware configuration is in question.
Requirement 11.6.1 (applicable after the March 31, 2025 deadline) requires mechanisms to detect unauthorized changes. An attacker with access to EMS can push policy changes that appear authorized from the endpoint’s perspective. The question is whether your change detection capabilities cover EMS policy modifications, not just file integrity on the endpoints themselves.
Looking Forward#
The back-to-back exploitation of two critical FortiClient EMS flaws within weeks is a reminder that endpoint management infrastructure occupies a uniquely sensitive position in the security stack. It sits at the intersection of endpoint security, VPN access, and compliance enforcement, making it a natural convergence point for attackers seeking maximum impact from a single compromise.
The fact that organizations patching the first vulnerability (by upgrading to 7.4.5) were then immediately exposed to the second is a frustrating reality of the current vulnerability landscape. Patching isn’t a one-time event. It’s a continuous process that requires monitoring the same products you just updated.
For security teams managing Fortinet infrastructure, the immediate priority is clear: apply the hotfixes, audit for compromise, and restrict internet exposure of management interfaces. For the broader practitioner community, this incident reinforces why management plane security deserves the same urgency as perimeter security. When attackers compromise the system that manages your endpoints, they don’t need to attack each endpoint individually.
They already have the keys.
