The Guard Got Robbed: CVE-2026-35616 and the FortiClient EMS Crisis

FortiClient EMS is the software enterprises trust to manage endpoint security across their entire fleet. Over the Easter holiday weekend, attackers exploited a second critical zero-day in the same product within a matter of weeks — bypassing authentication entirely before the system even checked who was asking.

Security management platforms occupy a privileged position in enterprise networks. They hold agent credentials, endpoint configurations, and in many cases, direct command channels to every managed device. When the management layer itself becomes the attack surface, the consequences scale with the trust the organization placed in it. That is the situation Fortinet customers are navigating right now, and the technical context behind it is worth understanding in detail.

What CVE-2026-35616 Is and Why It Matters

CVE-2026-35616 is classified as an improper access control vulnerability under CWE-284. Fortinet assigned it a CVSS score of 9.1 — critical — and published an out-of-band advisory (FG-IR-26-099) on Saturday, April 4, 2026, confirming active exploitation in the wild. The flaw affects FortiClient EMS versions 7.4.5 and 7.4.6. The 7.2 branch is confirmed unaffected. Fortinet's advisory does not specify whether the 8.0 branch is impacted. A full fix is expected in version 7.4.7, though Fortinet has released hotfixes for the two affected versions in the interim. According to Fortinet, the hotfixes are “sufficient to prevent it entirely.”

The vulnerability lives in the API layer of the EMS server. An unauthenticated attacker who can reach the EMS interface over the network can send specially crafted requests that sidestep authentication and authorization checks entirely. The CWE-284 classification is significant here: unlike CWE-287 (Improper Authentication), which describes flaws in how credentials are verified, CWE-284 describes a broader failure where the access control mechanism itself does not properly gate the resource. In practical terms, this means the API processes certain request structures before the authentication layer evaluates them — the check is not failed, it is never reached. Successful exploitation allows the attacker to execute arbitrary code or commands on the EMS server without supplying a single valid credential. The CVSS 3.1 base vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H — network-accessible, low complexity, no privileges required, no user interaction needed, with high impact to both confidentiality and integrity. Researchers Simo Kohonen of Defused Cyber and Nguyen Duc Anh are credited with discovering and responsibly disclosing the flaw. Defused Cyber reported the vulnerability to Fortinet after observing active zero-day exploitation, and Fortinet issued the advisory and hotfix on the same day it received the report.

The Attack Flow: From Unauthenticated Request to Code Execution

The core issue is that API authentication checks in affected versions can be bypassed through crafted request structures. An attacker does not need an account, a stolen token, or any prior foothold on the system. The attack originates entirely from outside the authentication perimeter.

Once the authentication layer is bypassed, the attacker gains the ability to execute code or commands in the context of the EMS service. The architectural implications are what elevate this from a standard remote code execution vulnerability. FortiClient EMS operates as the trust anchor for managed endpoints: it pushes security policies, distributes configuration updates, and maintains persistent communication channels with FortiClient agents across the fleet. The EMS server's identity is implicitly trusted by every endpoint it manages. An attacker with code execution on the EMS host inherits that trust position — they can potentially interact with managed endpoints using the same channels administrators rely on, without triggering the kind of anomalous-source alerts that lateral movement from a compromised workstation would generate.

Post-Exploitation: What Happens After the EMS Falls

Most coverage of CVE-2026-35616 stops at "arbitrary code execution," but the actual danger extends well beyond the EMS host itself. Understanding what an attacker can do after gaining code execution on a FortiClient EMS server reveals why this vulnerability class is categorically different from a typical RCE on a standalone service.

FortiClient EMS maintains a persistent trust relationship with every endpoint agent it manages. The EMS server holds the signing authority for policy updates, the credentials used to authenticate agent check-ins, and the communication channel through which it pushes configuration changes. When an attacker compromises the EMS host, they do not merely own one server — they inherit the management plane's implicit authority over the entire managed fleet. This means they can potentially push malicious policies, modify endpoint configurations, disable security controls on managed devices, or establish persistence through legitimate management channels that defenders are unlikely to flag as anomalous.

The EMS service on Fortinet's default virtual machine deployment runs with elevated privileges and communicates with a PostgreSQL backend. As Bishop Fox documented in their CVE-2026-21643 analysis, the EMS service account in the default deployment configuration operates with PostgreSQL superuser privileges. An attacker who achieves code execution on the EMS host through CVE-2026-35616 would likely inherit those same database privileges, which opens secondary escalation paths through PostgreSQL's native command execution capabilities.

There is also a credential harvesting dimension that most reporting overlooks. FortiClient EMS stores VPN configuration profiles, SAML and RADIUS integration credentials, and endpoint registration tokens. An attacker with file system access to the EMS host can extract these artifacts and use them for persistent access even after the vulnerability is patched. This is why log review and credential rotation are essential parts of the remediation process, not optional follow-ups.

The Bigger Problem: Two Critical Flaws in Three Weeks

CVE-2026-35616 does not exist in isolation. It arrived days after CVE-2026-21643, a CVSS 9.1 SQL injection flaw in FortiClient EMS version 7.4.4, entered active exploitation. That vulnerability — discovered internally by Gwendal Guégniaud of the Fortinet Product Security team and disclosed on February 6, 2026 — allowed unauthenticated attackers to inject SQL commands through the Site HTTP header used for tenant identification in multi-tenant deployments. According to Bishop Fox's analysis, the header value was passed into a PostgreSQL search_path query using format-string interpolation rather than parameterized identifier handling — a change introduced when FortiClient EMS refactored its database connection layer for multi-tenant support in version 7.4.4. The vulnerable code existed in production for exactly one release cycle before being patched in 7.4.5. Single-site deployments were not affected by CVE-2026-21643, though this distinction does not apply to CVE-2026-35616, which affects all deployments running 7.4.5 or 7.4.6 regardless of configuration.

In early March 2026, Bishop Fox researchers published a technical analysis that pinpointed practical exploitation paths for CVE-2026-21643. Their research identified that the publicly accessible /api/v1/init_consts endpoint could be used to trigger the SQL injection before any authentication check. Because the endpoint returned database error messages and had no lockout protections, this transformed what could have been a blind SQL injection into a verbose one — dramatically accelerating data extraction. The EMS service account in Fortinet's default virtual machine deployment runs with PostgreSQL superuser privileges, which means successful SQL injection can escalate to operating system command execution through PostgreSQL's COPY ... FROM PROGRAM functionality. Defused Cyber subsequently observed active exploitation beginning around March 26, 2026.

The pattern here is worth naming. The patch for CVE-2026-21643 was version 7.4.5. CVE-2026-35616 then appeared in versions 7.4.5 and 7.4.6 — meaning the fix for one critical unauthenticated vulnerability shipped with another critical unauthenticated vulnerability already present. Defused Cyber observed active exploitation of both flaws in the wild, and Simo Kohonen (Defused Cyber) and Nguyen Duc Anh are credited with discovering CVE-2026-35616 specifically. Both carry a CVSS score of 9.1. It is not currently known whether the same threat actors are behind both exploitation campaigns or whether the vulnerabilities are being chained.

"This is the second unauthenticated vulnerability in FortiClient EMS in a matter of weeks." — Benjamin Harris, watchTowr CEO, via The Hacker News

watchTowr's CEO has been vocal about the compounding risk, noting that defenders who just finished patching one critical flaw now face another in the same product. The practical concern is not theoretical: organizations that moved to 7.4.5 to escape CVE-2026-21643 landed directly inside the CVE-2026-35616 blast radius. The remediation path requires applying the hotfix on top of 7.4.5 or 7.4.6, or waiting for 7.4.7 when it becomes available.

The Broader Vulnerability Context

The two FortiClient EMS zero-days sit within a broader pattern that security researchers have been tracking. David Shipley of Beauceron Security told CSO Online that CVE-2026-21643 represented the seventh SQL injection CVE in Fortinet products over the preceding twelve months. Shipley noted that the frequency raises questions about whether individual fixes are being accompanied by broader codebase reviews to identify similar patterns elsewhere.

"This is Fortinet's seventh SQL CVE over the past 12 months." — David Shipley, Beauceron Security, via CSO Online

The broader numbers provide context for the urgency. CISA has flagged 24 Fortinet vulnerabilities as actively exploited in total, 13 of which have been linked to ransomware campaigns. The pattern extends beyond FortiClient EMS: CVE-2024-55591, a critical FortiOS authentication bypass, was weaponized by the NightSpire ransomware group and accumulated over 140 victims across 33 countries. In March 2024, CISA ordered federal agencies to patch a separate FortiClient EMS SQL injection vulnerability that had been exploited in ransomware attacks and by Salt Typhoon, a Chinese state-sponsored hacking group, to breach telecommunications service providers. The FortiClient EMS product line has now contributed multiple entries to CISA's actively-exploited list within a single quarter.

Victor Okorie of Info-Tech Research Group, commenting on the CVE-2026-21643 exploitation, highlighted an operational reality: when vulnerabilities in a particular vendor's products have been successfully exploited in past campaigns, threat actors build institutional familiarity with the vendor's architecture. That familiarity lowers the cost of discovering each subsequent flaw, which is why concentrated vulnerability patterns in widely-deployed infrastructure products tend to attract sustained attacker attention over time. Okorie advised that organizations should check whether their EMS is internet-facing and, if so, remove it from direct exposure and place it behind a secure access gateway.

Shipley went further, arguing that Fortinet appears to address individual bugs without conducting broader codebase reviews that would surface similar patterns elsewhere in the product. In his view, the repeated appearance of the same vulnerability class suggests a reactive posture rather than a systematic remediation strategy.

Holiday Weekend Exploitation Timeline

Exploitation of CVE-2026-35616 ramped up over the Easter weekend. The timeline below reconstructs the sequence of events from initial exploitation through advisory publication. Click any event for additional context.

Defender's Detection and Forensics Checklist

If your organization was running FortiClient EMS 7.4.5 or 7.4.6 with any internet exposure between March 31 and the date you applied the hotfix, the following forensic indicators and detection steps should be prioritized. This is not a theoretical exercise — exploitation was confirmed across multiple independent sources before the advisory was even published.

# Quick forensic triage commands for the EMS host (Windows)

# Check for unusual child processes under the EMS service
wmic process where "ParentProcessId=[EMS_PID]" get Name,ProcessId,CommandLine

# Review recently created scheduled tasks
schtasks /query /fo LIST /v | findstr /i "TaskName Date Author"

# Check for unexpected outbound connections from EMS
netstat -ano | findstr "ESTABLISHED" | findstr "[EMS_PID]"

# Review Apache access logs for anomalous API calls
# Look for requests to auth endpoints with HTTP 200 from external IPs
# and for clusters of HTTP 500 responses from single IPs
findstr /i "init_consts auth/signin" "C:\path\to\apache\logs\access.log"

# Check PostgreSQL for COPY FROM PROGRAM usage (if query logging enabled)
findstr /i "COPY.*FROM PROGRAM" "C:\path\to\pg_log\*.log"

MITRE ATT&CK Mapping

SOC teams writing detection rules or building incident response playbooks need to understand where CVE-2026-35616 fits within the MITRE ATT&CK framework. The exploit chain maps cleanly to several documented techniques. Click any card below for detection context.

The most operationally significant mapping is T1072. When an attacker controls the management plane, every action they take through the EMS-to-endpoint channel looks like normal administrative activity. Traditional network detection rules that flag anomalous lateral movement will not trigger because the traffic flows through the same channels and protocols used for legitimate policy distribution. This is what makes management platform compromises categorically different from standard host compromises, and it is why the ATT&CK mapping matters for detection engineering: defenders need to instrument the EMS platform itself for anomalous policy changes and agent communications, not just the network perimeter.

Compensating Controls When Patching Is Delayed

The correct response to CVE-2026-35616 is to apply the hotfix immediately. There are no acceptable alternatives to patching when a pre-authentication RCE with active exploitation and a public proof of concept is in play. However, operational reality means some organizations may face delays — change control boards that meet weekly, EMS instances in air-gapped environments with manual update processes, or dependency conflicts that require testing before deployment. For those organizations, the following compensating controls reduce exposure during the gap between awareness and patch application. None of them eliminate the risk. They buy time, and that time should be measured in hours, not days.

The single highest-impact compensating control is restricting network access to the EMS web interface. If the EMS administrative interface is not reachable from the internet, the attack surface shrinks to internal threat actors and already-compromised hosts. This means placing the EMS behind a VPN or jump host, applying firewall rules that restrict HTTPS access to the EMS port (typically TCP 443 or 8013) to known administrative IP ranges, and confirming that no load balancers, reverse proxies, or NAT rules are inadvertently exposing the interface. This should be treated as a permanent architectural change, not a temporary workaround.

Web application firewall (WAF) or intrusion prevention system (IPS) rules can provide a partial detection layer, but their effectiveness against CVE-2026-35616 specifically depends on whether vendors have published signatures for the exploit's request patterns. As of April 5, 2026, major IPS vendors including Fortinet's own FortiGuard IPS service may have signatures available or pending for this CVE. Organizations should check their IPS signature databases for CVE-2026-35616-specific rules and enable them in blocking mode. Generic API abuse detection rules — those that flag unusual HTTP methods, oversized headers, or non-standard content types against known API paths — may catch some exploitation attempts but should not be relied upon as a primary control.

If patching truly cannot happen within the same business day, consider taking the EMS offline entirely and managing endpoints in standalone mode until the hotfix is applied. FortiClient agents will continue to operate with their last-received policy if the EMS becomes unreachable. This is disruptive, but less disruptive than having the management plane compromised and used to push malicious configurations to every managed endpoint in the fleet.

PostgreSQL Hardening as a Blast Radius Reduction

Bishop Fox documented that the EMS service account in Fortinet's default VM deployment runs with PostgreSQL superuser privileges. This default configuration amplifies the impact of both CVE-2026-35616 and CVE-2026-21643, because an attacker who achieves code execution or SQL injection can immediately escalate through PostgreSQL's COPY ... FROM PROGRAM functionality to execute operating system commands. Reducing these database privileges is a distinct remediation step that many organizations overlook, and it provides defense-in-depth that persists across future vulnerabilities in the same product.

Organizations should revoke SUPERUSER from the EMS service account and grant only the minimum privileges the application actually requires: SELECT, INSERT, UPDATE, and DELETE on EMS-specific tables, plus any schema-level permissions needed for migrations. The pg_hba.conf file should be restricted to localhost-only connections so the PostgreSQL instance is not reachable from other hosts on the network. If the EMS application does not require COPY ... FROM PROGRAM, that capability should be explicitly revoked. These changes should be tested in a staging environment first, but once validated, they should become part of the organization's standard EMS deployment baseline — not a temporary measure tied to this specific CVE.

Microsegmentation of EMS Server Communications

Most guidance on network controls for CVE-2026-35616 focuses on restricting inbound access to the EMS web interface. That is necessary, but it addresses only half of the exposure. If the EMS host is compromised, the attacker uses its trusted outbound channels — the same channels used for legitimate policy distribution and agent communication — to reach managed endpoints. Restricting the EMS server's own egress reduces the attacker's ability to pivot even after gaining code execution.

Effective microsegmentation for the EMS host means restricting its outbound network access to only the specific ports and protocols required for agent communication (typically the FortiClient agent communication port and the management console port), blocking its ability to initiate connections to the broader internet or to non-endpoint subnets that have no legitimate management relationship, and implementing east-west traffic monitoring between the EMS and anything that is not a managed endpoint. If the EMS host suddenly begins making SMB connections to file servers, RDP connections to domain controllers, or DNS queries to unfamiliar external resolvers, those are high-fidelity indicators of post-exploitation lateral movement. Organizations that deploy host-based firewalls or identity-aware microsegmentation platforms (such as Illumio, Guardicore, or Zscaler Workload Segmentation) should create explicit policies for the EMS server's communication profile and alert on any deviation.

Detection Engineering for T1072 (Software Deployment Tool Abuse)

The ATT&CK mapping section of this article identifies T1072 as the highest-risk technique because an attacker controlling the EMS can push malicious policies through legitimate management channels that defenders will not flag as anomalous. However, identifying the risk is not the same as detecting it. SOC teams need concrete instrumentation to close this detection gap, and generic network monitoring will not suffice — the traffic looks identical to normal administrative operations.

The detection approach must instrument the EMS application itself, not just the network perimeter. Start by baselining normal policy distribution patterns: how frequently does the EMS push configuration changes, during what hours, to how many endpoints at once, and which administrative accounts initiate those changes? Any deviation from that baseline should generate an alert. Specific indicators to instrument include policy change events that occur outside of approved change windows, bulk configuration pushes that affect a large percentage of managed endpoints simultaneously (particularly if no change ticket corresponds to the activity), newly created or modified EMS administrative accounts that were not provisioned through the organization's identity management workflow, and modifications to VPN profiles, security policy assignments, or agent update schedules that do not correlate with a documented administrative action. If the EMS supports audit logging for policy modifications, those logs should be forwarded to the SIEM in real time and excluded from any log rotation that could destroy evidence during the forensic window.

Regulatory, Insurance, and Notification Implications

A compromised FortiClient EMS server is not a routine security incident. Because the EMS holds endpoint configurations, VPN credentials, and agent communication channels, exploitation of CVE-2026-35616 can trigger regulatory notification obligations that would not apply to a standard workstation compromise. The specifics depend on jurisdiction, industry, and the type of data the EMS manages, but several common scenarios warrant attention.

If the EMS stores or provides access to protected health information (PHI) through managed endpoint VPN configurations, a confirmed compromise may trigger HIPAA breach notification requirements. Healthcare organizations have faced exactly this scenario: the ransomware attack on the University of Mississippi Medical Center demonstrated how quickly a management-plane compromise can cascade into clinic closures and multi-agency federal response when PHI is in scope. If the EMS manages endpoints that process payment card data, PCI DSS Requirement 12.10 (incident response) applies, and the forensic scope may need to extend to all endpoints managed by the compromised EMS to determine whether cardholder data environments were affected. For organizations subject to SEC cybersecurity disclosure rules (effective since December 2023), a management-plane compromise with fleet-wide implications may constitute a material cybersecurity incident requiring disclosure within four business days of determination.

Cyber insurance policies typically require policyholders to apply critical security patches within a defined window — commonly 30 to 45 days from vendor publication, though some policies specify shorter timelines for actively-exploited vulnerabilities. Fortinet's advisory confirms active exploitation and provides a hotfix. Organizations that delay applying the hotfix beyond their policy's patching window risk having a subsequent claim denied on the basis of failure to meet policy conditions. Given that the PoC is public and exploitation is confirmed, insurers are likely to take a strict view on timelines for this particular vulnerability.

The forensic scope question is what distinguishes EMS compromise from typical incidents. If the EMS was compromised, the blast radius potentially includes every endpoint the EMS managed during the compromise window. Demonstrating that endpoints were not affected requires log evidence, policy integrity verification, and potentially agent-level forensic examination — work that scales with the size of the managed fleet. Organizations should begin scoping this work immediately if there is any indication of compromise, rather than waiting for full forensic confirmation before initiating notification workflows.

Who Runs FortiClient EMS: Sector Exposure and Deployment Models

FortiClient EMS is not a niche product. It is deployed across a broad range of industries and organization sizes, driven by the fact that many enterprises already use Fortinet's firewalls and VPN appliances and extend that ecosystem to endpoint management. Government agencies, healthcare systems, financial institutions, educational institutions, and managed service providers (MSPs) are well-represented in the customer base. Fortinet's positioning in the midmarket and enterprise space means that many EMS deployments manage thousands of endpoints across distributed sites.

Managed service providers represent a particularly concentrated risk. An MSP running a single FortiClient EMS instance to manage endpoints across multiple client organizations creates a one-to-many attack scenario: compromising the MSP's EMS gives the attacker potential access to every client environment managed through that instance. This is the same supply chain amplification pattern that made the Kaseya VSA ransomware attack in 2021 so impactful. MSPs running FortiClient EMS 7.4.5 or 7.4.6 should treat this vulnerability with the same urgency they would a direct compromise of their own infrastructure, because functionally, it is.

MSP-Specific Isolation and Response Steps

MSPs face obligations beyond their own infrastructure security. If the MSP's EMS was internet-exposed during the exploitation window, every client environment managed through that instance falls within the potential blast radius. The MSP should immediately notify affected clients that a management-plane vulnerability with confirmed active exploitation affected the platform managing their endpoints, regardless of whether compromise has been confirmed. Waiting for forensic certainty before client notification is a mistake in this scenario: the scope of potential impact is too broad, and clients need the opportunity to begin their own response activities in parallel.

Architecturally, MSPs should evaluate whether a single shared EMS instance is appropriate for multi-client management going forward. Per-client EMS instances with dedicated network segments eliminate the one-to-many escalation path entirely. Where per-client instances are not operationally feasible, the MSP should at minimum implement client-specific network segmentation so that the EMS's management channels to Client A's endpoints cannot be used to reach Client B's network, and deploy separate administrative credentials per client environment so that credential harvesting from one client's configuration does not immediately grant access to others. Contractual obligations should also be reviewed: many MSP service agreements include incident notification timelines and security baseline requirements that this scenario may trigger.

FortiClient EMS runs on Windows Server. There is no Linux or macOS server deployment option. This matters for the forensic response: defenders are working with Windows-native artifacts (Event Logs, scheduled tasks, services, NTFS timestamps) and Windows-based PostgreSQL installations. Cloud-hosted EMS deployments on AWS, Azure, or GCP are equally affected if they are running the vulnerable versions — the hosting model does not change the software's vulnerability posture. Fortinet also offers a virtual machine deployment template that ships with specific default configurations, including the PostgreSQL superuser privilege issue documented by Bishop Fox. Organizations using the VM template should assume that their database privileges match the defaults unless they have explicitly hardened them.

Historical Pattern: FortiClient EMS and CVE-2023-48788

CVE-2026-35616 and CVE-2026-21643 are not the first time FortiClient EMS has been targeted in active exploitation campaigns. In March 2024, CISA added CVE-2023-48788 — a critical SQL injection vulnerability in FortiClient EMS — to its Known Exploited Vulnerabilities catalog after confirmed exploitation in ransomware attacks. That vulnerability, which affected FortiClient EMS versions 7.0.1 through 7.0.10 and 7.2.0 through 7.2.2, was also exploited by Salt Typhoon (a Chinese state-sponsored threat group) to breach telecommunications service providers.

The pattern is worth examining. CVE-2023-48788 was a SQL injection. CVE-2026-21643 was a SQL injection. CVE-2026-35616 is an access control bypass. All three are pre-authentication vulnerabilities in the same product, all carry critical CVSS scores, and all were exploited in the wild. The product has now contributed three distinct critical pre-authentication vulnerabilities to active exploitation catalogs within roughly two years. Meanwhile, the broader Fortinet ecosystem continues to attract attacker attention: Amazon Threat Intelligence documented a campaign where a single low-skill actor used commercial AI to compromise over 600 FortiGate devices across 55 countries in just 38 days, underscoring how accumulated Fortinet vulnerabilities are being operationalized at scale.

For organizations evaluating their long-term architectural posture, the recurring pattern raises a strategic question: should the endpoint management server for the security fleet be a product with this track record of pre-authentication vulnerabilities in its public-facing interfaces? This is not a question about whether Fortinet makes good firewalls or whether FortiClient is a capable endpoint agent. It is a question about whether the management plane — the component with the broadest trust relationship in the security architecture — should be the component with the highest historical rate of critical unauthenticated exposure.

Organizations that choose to remain on FortiClient EMS should, at minimum, ensure that the EMS interface is never directly internet-facing, regardless of patch status. Beyond that baseline, three architectural approaches warrant evaluation. First, implement a proxy or authenticating gateway in front of the EMS so that all API interactions pass through a layer the organization fully controls, adding defense-in-depth that does not depend on the EMS application's own access control implementation. Second, if the organization has the operational maturity to support it, evaluate whether a different endpoint management platform with a stronger track record on pre-authentication security would reduce management-plane risk. This is a significant undertaking, but for organizations where the EMS manages endpoints in regulated environments or critical infrastructure, the cost of repeated emergency patching and forensic scoping may eventually exceed the cost of migration. Third, adopt a zero-trust posture toward the EMS itself: treat it as a semi-trusted component rather than a fully trusted management plane, instrument its behavior as rigorously as any other potentially compromisable host, and design the network architecture so that a compromised EMS cannot unilaterally reach every endpoint it manages without additional authentication or authorization checks at the network layer.

What to Do Right Now

Fortinet's guidance is explicit: treat this as an emergency response situation. The following steps apply to any organization running FortiClient EMS with versions 7.4.5 or 7.4.6.

• Apply the hotfix immediately. Fortinet has released hotfixes for both 7.4.5 and 7.4.6. Release notes with hotfix links are available for FortiClient EMS 7.4.5 and FortiClient EMS 7.4.6. Fortinet states the hotfixes are “sufficient to prevent it entirely.” Do not defer this to a standard change window.
• Audit internet exposure. The Shadowserver Foundation tracks over 2,000 exposed EMS instances, with the majority in the United States and Germany. A separate CSO Online report citing Shadowserver identified more than 2,400 instances with exposed web interfaces, and Shodan reports approximately 1,000 publicly accessible instances. If your EMS administrative interface is reachable from the public internet, that exposure needs to end before patching, not after.
• Review access logs for pre-patch activity. Exploitation began on or before March 31. If your organization did not apply the hotfix on publication day, there is a window of potential exposure to examine. For CVE-2026-35616, look for anomalous API calls to authentication endpoints and unexpected command executions originating from the EMS server process. For CVE-2026-21643, Bishop Fox identified specific indicators: unusually long response times (5–20+ seconds) on /api/v1/auth/signin or /api/v1/init_consts in Apache access logs, and repeated HTTP 500 responses from a single IP address on the /api/v1/init_consts endpoint. Any lateral movement originating from the EMS server should be investigated immediately.
• Restrict EMS web interface access to trusted administrative networks. This applies as a permanent configuration posture, not only as a temporary compensating control. Management platforms have no reason to be reachable from arbitrary internet addresses.
• Monitor for CVE-2026-21643 chain activity. It is unknown whether both CVEs are being used together. Given that both are pre-authentication and both affect EMS, defenders should treat the possibility of compound exploitation as credible until evidence suggests otherwise.
• Confirm your branch. CVE-2026-35616 affects only the 7.4 branch (versions 7.4.5 and 7.4.6). The 7.2 branch is confirmed unaffected. Fortinet has not stated whether the 8.0 branch is impacted — organizations running 8.0 should monitor Fortinet's advisory for updates.
• Harden PostgreSQL privileges on the EMS host. If your EMS deployment uses Fortinet's default VM template, the database service account likely runs with PostgreSQL superuser privileges. Revoke superuser, restrict the service account to minimum required permissions, and limit pg_hba.conf to localhost-only connections. This reduces the blast radius of both current and future pre-authentication vulnerabilities.
• Segment EMS server outbound communications. Restrict the EMS host's egress to only the ports and protocols required for agent management. Block its ability to initiate connections to the broader internet or non-endpoint subnets. Alert on any outbound connections from the EMS to unexpected destinations.
• Instrument the EMS for T1072 detection. Baseline normal policy distribution patterns and alert on deviations: out-of-window policy changes, bulk configuration pushes without change tickets, new administrative accounts, and VPN profile modifications that do not correlate with documented administrative actions. Forward EMS audit logs to the SIEM in real time.

# Verify your FortiClient EMS version via CLI
# Run on the EMS host or check the admin console under System Information

# Affected: 7.4.5, 7.4.6
# NOT affected: 7.2 branch (confirmed)
# 8.0 branch: status not specified in Fortinet advisory (FG-IR-26-099)
# Hotfix required — full fix expected in 7.4.7
# Hotfix links:
# 7.4.5: https://docs.fortinet.com/document/forticlient/7.4.5/ems-release-notes/832484
# 7.4.6: https://docs.fortinet.com/document/forticlient/7.4.6/ems-release-notes/832484

Key Takeaways

1. Patch immediately, not Tuesday: Hotfixes for FortiClient EMS 7.4.5 and 7.4.6 are available now. Exploitation is active and has been since at least March 31. Standard change control timelines are not appropriate here.
2. Management platforms are high-value targets: FortiClient EMS holds command channels to managed endpoints across the enterprise. A compromise here is not a single-host incident — it is a management-plane incident with fleet-wide implications.
3. The patch chain created a new exposure window: Organizations that patched CVE-2026-21643 by upgrading to 7.4.5 now need to apply the CVE-2026-35616 hotfix on top of that version. Neither CVE is fully addressed until the hotfix is applied or 7.4.7 ships.
4. Two critical unauthenticated flaws in three weeks warrants broader review: Both vulnerabilities in FortiClient EMS required no credentials, were exploited before patches were widely applied, and carry identical CVSS scores. Fortinet products have accumulated 24 CISA-flagged actively-exploited vulnerabilities, with 13 linked to ransomware. Organizations relying on Fortinet management infrastructure should evaluate their overall exposure posture and ensure they have visibility into all internet-facing Fortinet deployments.
5. Holiday-period exploitation is a documented pattern: The Easter weekend timing was consistent with established attacker tradecraft. Organizations should ensure that critical vulnerability response processes remain active during holiday periods, particularly for internet-facing management infrastructure.
6. Patching alone is not sufficient if compromise occurred: If your EMS was internet-exposed during the exploitation window (March 31 onward), applying the hotfix stops future exploitation but does not address existing compromise. Credential rotation, log review, and policy integrity verification are necessary to confirm the environment is clean.
7. Database privilege reduction limits blast radius now and for future CVEs: Fortinet's default VM deployment runs PostgreSQL with superuser privileges. Revoking those privileges and restricting database connections to localhost reduces the damage any future pre-authentication vulnerability can cause — it is defense-in-depth that persists beyond this specific CVE.
8. Detection engineering must instrument the EMS itself, not just the network: The highest-risk post-exploitation technique (T1072) uses the EMS's own legitimate management channels. Network-level detection will not catch it. Organizations need to baseline normal policy distribution patterns and alert on deviations, including out-of-window changes, bulk configuration pushes, and unplanned administrative account modifications.

The role FortiClient EMS plays — centralized, trusted management of endpoint security — is precisely what makes it high-impact when compromised. A management platform with command channels to every endpoint it manages represents a fundamentally different risk profile than a compromised workstation or edge device. The priority actions are clear: apply the hotfix, close internet exposure, harden the PostgreSQL backend, segment the EMS server's outbound communications, instrument the platform for anomalous policy activity, and review access logs from the past week for any indicators of pre-patch exploitation. For organizations where the EMS manages endpoints in regulated environments or across multiple client organizations, the remediation scope extends to credential rotation, endpoint trust verification, and an honest assessment of whether the management plane architecture provides adequate defense-in-depth against the next pre-authentication vulnerability in this product line.