CVE-2026-35616 in FortiClient EMS, How the Auth Bypass Works and What to Do Now

CVE-2026-35616 is an actively exploited FortiClient EMS vulnerability in a part of the stack that defenders should already treat as high-value infrastructure. Fortinet says the issue affects FortiClient EMS 7.4.5 through 7.4.6, that 7.2 is not affected, that FortiClient Cloud and FortiSASE have already been remediated on the vendor side, and that 7.4.7 contains the permanent fix. NVD also shows the flaw in CISA’s Known Exploited Vulnerabilities catalog, with a federal remediation due date of April 9, 2026. (FortiGuard Labs)

That short summary already tells you why this is not a “patch it when the weekend ends” issue. FortiClient EMS is not just a dashboard. It is the control plane for endpoint policy, remote access configuration, telemetry-linked client management, and ongoing administration of FortiClient-connected systems. A vulnerability here lands on a management surface with leverage over large numbers of endpoints, not on a disposable utility node with little downstream authority. (docs.fortinet.com)

Public writeups describe the problem in slightly different language. Fortinet and the NVD entry describe an improper access control flaw that may let an unauthenticated attacker execute unauthorized code or commands via crafted requests. Independent technical analysis goes deeper and shows why many researchers are treating it as a practical pre-authentication compromise of the EMS management plane: the application trusted spoofable HTTP headers as if they were trusted TLS client-certificate signals, and the certificate chain validation logic itself performed string checks without real X.509 signature verification. (nvd.nist.gov)

CVE-2026-35616 at a glance

The confirmed public record is compact enough to summarize before going deeper.

Item	Current confirmed status
Vulnerability	CVE-2026-35616
उत्पाद	FortiClient EMS
Affected versions	7.4.5 through 7.4.6
Not affected	7.2 branch
Cloud-side status	FortiClient Cloud remediated by Fortinet, no customer action; FortiSASE remediated by Fortinet, no customer action
Exploitation status	Fortinet says it has observed exploitation in the wild
Hotfix status	Vendor hotfixes published for 7.4.5 and 7.4.6
Permanent fix	Included in 7.4.7
KEV status	In CISA KEV
CISA due date	April 9, 2026

This table is distilled from Fortinet’s advisory and release notes together with the NVD KEV-linked entry. (FortiGuard Labs)

There is another reason to read beyond the headline summary. The public metadata is not perfectly tidy. Fortinet’s advisory summary says the issue has been exploited in the wild, yet the advisory metadata block still shows “Known Exploited No.” The advisory also displays a CVSS value of 9.1, while the NVD page currently shows the Fortinet CNA vector as 9.8 critical. That mismatch does not make the issue less urgent. It does underline a recurring operational lesson: when a zero-day is unfolding, the details that matter most are affected versions, exposure assumptions, available mitigations, and whether active exploitation is confirmed. Here, those points are already clear enough to justify immediate action. (FortiGuard Labs)

WatchTowr’s reporting adds one more point that matters for defenders: its Attacker Eye sensors observed exploitation on March 31, 2026, ahead of Fortinet’s public advisory on April 4. That means some environments may have been exposed for days before patching activity even began inside affected organizations. If your EMS instance was reachable during that window, the right mindset is incident response with remediation, not patch management with curiosity. (watchTowr)

Why a FortiClient EMS compromise is more serious than a normal management bug

Vendor documentation is useful here because it defines the blast radius in plain operational terms. FortiClient EMS is the centralized management system for multiple endpoints, provides network visibility, assigns security policies, remotely deploys FortiClient, updates user profiles regardless of location, administers endpoint connections, and manages endpoint status and signature information. That is already enough to move the discussion out of the narrow category of “a bad Web bug on an appliance.” (docs.fortinet.com)

The profile surface under EMS control is not trivial either. Fortinet’s own administration guide shows endpoint profiles for Remote Access, ZTNA Destinations, Web Filter, Video Filter, Vulnerability Scan, Malware Protection, Sandbox, Firewall, and System Settings. In other words, the platform sits in the middle of remote access posture, content-control behavior, malware policy, firewall settings, and endpoint system configuration. A compromise of the management server is not only a server compromise. It is also a policy integrity problem. (docs.fortinet.com)

The deployment and update model increases that leverage. Fortinet documents that once FortiClient and EMS establish a Telemetry connection, EMS can push FortiClient updates to endpoints. The same documentation also describes multiple enrollment and rollout paths, including deployment packages, MDM flows, and invitation-based onboarding. Once a system has become the trusted policy and update authority for a large endpoint fleet, compromise of that system carries a very different operational meaning than compromise of a stand-alone internal app. (docs.fortinet.com)

The API matters for the same reason. Fortinet’s documentation states that the FortiClient EMS API allows configuration operations on EMS. That is why an API-layer authentication bypass is so serious even before anyone argues about the precise label to attach to post-bypass impact. If the management API can be reached and trusted controls can be impersonated or bypassed, the attacker is not merely reading data. The attacker is stepping into a system designed to configure other systems. (docs.fortinet.com)

One more operational detail makes the exposure question painfully concrete. Fortinet documents a “Remote HTTPS Access” feature that, when enabled, lets administrators use a browser and HTTPS to log into EMS. The same page notes that administrators can disable this and limit access to the server itself. That means two things at once: first, there is a supported path for browser-based remote administration; second, whether the interface is broadly reachable is a deployment choice that directly affects real-world risk. (docs.fortinet.com)

What Fortinet confirmed, and what the public record still gets wrong

Fortinet’s advisory is straightforward on the core points. It describes CVE-2026-35616 as an improper access control vulnerability in FortiClient EMS that may allow an unauthenticated attacker to execute unauthorized code or commands via crafted requests. It says Fortinet has observed exploitation in the wild. It says 7.4.5 through 7.4.6 are affected, 7.2 is not, FortiClient Cloud and FortiSASE were remediated by the vendor, and 7.4.7 includes the fix while the published hotfix is sufficient in the meantime. Those are the facts to anchor on. (FortiGuard Labs)

The NVD entry aligns with the affected versions, unauthenticated nature, CWE-284 classification, and the basic impact description. More importantly for prioritization, the NVD page shows the issue in CISA’s KEV, with the date added listed as April 6, 2026 and the due date listed as April 9, 2026. In practice, KEV status is more valuable than a marginal CVSS argument because it tells you that the issue has crossed the threshold from “theoretically severe” into “actively relevant to real attackers.” (nvd.nist.gov)

What the public record can still obscure is how defenders should interpret the effect. Some articles simplify the issue into “Fortinet auth bypass.” Others simplify it into “unauthenticated RCE.” The more precise reading is this: the official vendor wording says unauthorized code or commands via crafted requests, while the independent reverse-engineering work shows a path to authenticated API access through spoofed certificate-authentication signals and defective certificate-chain validation. In a product designed to configure endpoint policy and related security controls, that is already enough to be treated as a major management-plane compromise. Whether you call the end state command execution, remote code execution, or privileged API compromise should not change your response priority. (FortiGuard Labs)

Another subtle error in early discussion was to treat every “FortiClient EMS” deployment as equally at risk. That is not what Fortinet said. Self-managed EMS 7.4.5 and 7.4.6 are the affected versions. FortiClient Cloud and FortiSASE were remediated on the vendor side and do not require customer action for this issue, according to the advisory. That distinction matters because rushed internal notices often flatten product family names into a single panic phrase and then send teams hunting in the wrong places. (FortiGuard Labs)

How CVE-2026-35616 works inside FortiClient EMS

The strongest public technical explanation so far comes from Bishop Fox’s patch and code analysis, and it changes the vulnerability from a vague advisory into a specific architectural lesson. FortiClient EMS uses Apache with mod_ssl in front of a Django application. In a normal TLS client-certificate design, Apache populates trusted WSGI environment variables such as SSL_CLIENT_VERIFY और SSL_CLIENT_CERT, and the application reads those trusted values. The problem here was that the Django middleware also accepted equivalent values from user-controlled HTTP headers. (Bishop Fox)

The first critical mistake was the authentication gate. According to Bishop Fox’s decompilation, the code treated a request as certificate-bearing if either the trusted SSL_CLIENT_VERIFY variable was SUCCESS or the Django-mapped HTTP_X_SSL_CLIENT_VERIFY value was SUCCESS. That second value is directly controllable by any client that sends the HTTP header X-SSL-CLIENT-VERIFY. In other words, a signal that should only have existed inside a trusted proxy-to-application boundary was accepted from the outside world. (Bishop Fox)

The second critical mistake was even more damaging. The application’s certificate processing logic gave priority to HTTP_X_SSL_CLIENT_CERT, which is simply the Django representation of a client-supplied X-SSL-CLIENT-CERT header, over the trusted Apache variables that were supposed to carry real client certificate material. Once the first check let the request cross the gate, the certificate data itself could also come from a spoofable header. That is not just “auth bypass” in the abstract. It is a collapse of the trust boundary between reverse proxy and application logic. (Bishop Fox)

Then there is the certificate-chain validation problem. Bishop Fox found that validate_cert_chain() compared only subject and issuer Distinguished Name strings against embedded Fortinet root CAs. It did not perform X.509 cryptographic signature verification. That means the code did not actually prove a real signing relationship through the chain. It only checked whether the names looked right. In security terms, that is the difference between verifying a chain of trust and recognizing a costume. (Bishop Fox)

This is why the root cause should be thought of as two separate design failures that happened to align. The first failure was trusting externally supplied HTTP headers that imitated internal TLS metadata. The second failure was treating certificate-chain structure as enough, without signature verification. Either fix would have raised the bar. Together, their absence turned certificate-based device authentication into something an unauthenticated remote attacker could potentially fake from the wrong side of the trust boundary. (Bishop Fox)

Bishop Fox’s remediation analysis also helps explain what Fortinet’s hotfix is and is not. According to that analysis, the hotfix adds Apache RequestHeader unset directives to strip spoofable headers like X-SSL-CLIENT-VERIFY और X-SSL-CLIENT-CERT before they reach Django. That is an effective emergency measure because it restores the proxy/application boundary. But Bishop Fox also notes that the string-only certificate-chain validation remained in place until the code-level fix in 7.4.7. That distinction matters because it tells defenders what they are trusting the hotfix to accomplish. It is a necessary and practical control. It is not the same thing as a clean redesign of the application’s certificate-validation assumptions. (Bishop Fox)

Why an auth bypass here becomes a server and fleet problem

When a vulnerability lands in a management server, the right question is not only “Can the attacker get in?” The next question is “What authority does that system hold over everything else?” FortiClient EMS holds a lot. It can define endpoint policy, update profiles, manage remote access-related settings, administer client connections, and act through an API that performs configuration operations. That turns a vulnerable management surface into a potential force multiplier. (docs.fortinet.com)

The watchTowr writeup is useful on the defender side because it translates that abstract leverage into operational concerns: endpoint security policies, VPN configuration profiles, application firewall rules, administrator accounts and access controls, and endpoint compliance configurations. None of those are minor knobs. If an attacker can influence them after compromising EMS, the result can look less like a single server incident and more like a control-plane event that propagates distrust across the fleet. (watchTowr)

This is also why the terminology debate about “RCE versus auth bypass” is not where serious responders should spend time. Fortinet’s own wording says the flaw may allow unauthorized code or commands. WatchTowr explicitly frames the issue as allowing unauthenticated remote code execution, and independent analysis shows a route to authenticated API access by forging signals the application was never supposed to accept from clients. In practical enterprise risk terms, these descriptions all point in the same direction: a remotely reachable EMS instance on an affected branch is a crisis-tier exposure. (FortiGuard Labs)

The deeper lesson is about management planes in general. Security teams often model risk as if endpoints are the high-value systems and management consoles are only administrative wrappers around them. That model breaks down as soon as the management console becomes the mechanism for configuration, compliance, remote access, deployment, and posture enforcement. In a system like EMS, the management plane is not adjacent to the endpoint fleet. It is upstream of it. (docs.fortinet.com)

What to triage first if you run FortiClient EMS

Start by answering the simplest questions with evidence, not assumptions. Do you run self-managed FortiClient EMS, or do you run FortiClient Cloud or FortiSASE? If you run self-managed EMS, what exact version is installed? Is remote HTTPS administration enabled? Was the interface reachable from the internet or from broad internal segments where an attacker could plausibly reach it after a foothold? These questions matter more in the first hour than any speculative hunt for a polished public exploit. (FortiGuard Labs)

Your version triage should be exact, not approximate. If the environment is on 7.4.5 or 7.4.6 and the hotfix has not been applied, treat the server as exposed if reachable. If the environment is on 7.2, this CVE is not the issue you are solving. If the environment is on 7.4.4, you are in a different but still serious position because CVE-2026-21643 affected that branch and was also observed exploited in the wild. FortiClient EMS risk right now is version-specific, and compressing adjacent vulnerabilities into one blurred message is how teams make poor change decisions under pressure. (FortiGuard Labs)

The next priority is exposure classification. Fortinet’s own docs show that remote HTTPS administration can be enabled for browser-based access. Bishop Fox’s mitigation guidance is explicit that the vulnerability requires direct HTTPS access to the EMS web interface on port 443. That does not mean “public internet only.” It means any path that lets an attacker reach that interface matters. An externally reachable interface is the obvious worst case, but a flat internal path from compromised workstation to EMS is also not acceptable risk. (docs.fortinet.com)

After that, separate remediation from incident response but run them in parallel. Remediation means hotfixing or moving to 7.4.7. Incident response means preserving logs, checking for configuration drift, reviewing administrative changes, and deciding whether server integrity is still trustworthy. Patch management closes the hole. It does not tell you whether somebody used the hole before you got there. The watchTowr timeline makes that distinction unavoidable because exploitation was observed before the vendor disclosure. (watchTowr)

Patching CVE-2026-35616 without creating new problems

Fortinet’s emergency guidance is direct: apply the hotfix on 7.4.5 or 7.4.6 now, or move to 7.4.7, which contains the permanent fix. The 7.4.6 resolved issues page identifies CVE-2026-35616 as fixed in FortiClient EMS 7.4.6 GA hotfix 1, build 7.4.6.2170.1277073, and the 7.4.7 release notes show the CVE no longer affects that version. For 7.4.5 and 7.4.6, Fortinet published separate hotfix installation instructions, example package names, and SHA-256 values. (docs.fortinet.com)

The vendor documents show the same operational pattern for both affected branches: download the correct hotfix package from Fortinet Support, verify the SHA-256 checksum, apply it with emscli, then list installed hotfixes and confirm the status is applied. Fortinet’s example checksums in the release-note hotfix pages are 9f7d4f2c63176c5e766de8d0d6b0977af0b5795362d31ce6da72fcceb025d0c1 for the 7.4.5 hotfix package example and 3e76dc2b712a2988afd50459022f28e3fbda9a0a29f7f31674026620040cf2f5 for the 7.4.6 hotfix package example. (docs.fortinet.com)

# Apply the vendor hotfix on the affected EMS server
sudo emscli execute hotfix --apply ./<hotfix filename>

# Verify that the hotfix status is applied
sudo emscli execute hotfix --list

The exact filename should match the branch-specific package you obtained from Fortinet Support and verified against the published checksum. Fortinet’s 7.4.5 and 7.4.6 hotfix instructions both show this emscli flow and use --list to confirm applied status. (docs.fortinet.com)

Do not turn this into an excuse for a sloppy upgrade jump. Fortinet’s 7.4.6 and 7.4.7 documentation also records upgrade-related issues relevant to emergency planning. The 7.4.7 resolved issues page says that after upgrade from 7.4.4 or 7.4.5 to 7.4.6, some environments saw problems with RADIUS configuration for admin login, OAuth 2 fabric connectors, and scheduled backup on remote server. The 7.4.6 upgrade documentation flags the same issue and says certain 7.4.4 or 7.4.5 environments must first install a hotfix package before attempting the upgrade to 7.4.6. Under emergency pressure, teams often over-simplify this into “just upgrade to the latest branch immediately.” That may still be the right answer, but not if it breaks the controls you rely on to administer or recover the platform. (docs.fortinet.com)

The safest operating pattern is usually straightforward. If you are on 7.4.5 or 7.4.6, apply the published hotfix immediately to stop active exposure. Then plan a controlled move to 7.4.7 once the environment is stable and post-hotfix validation is complete. If your team needs a single sentence to work from, it is this: hotfix to get safe, then upgrade to get clean. (FortiGuard Labs)

How to validate the hotfix and hunt for exploitation

The nicest thing about a vendor hotfix is not that it exists. It is that you can verify whether it changed behavior in the place that mattered. Bishop Fox’s non-destructive scanner logic is useful because it focuses on behavior instead of attempting a full exploit. In their analysis, an unpatched target returns a different response when a spoofed X-SSL-CLIENT-VERIFY: SUCCESS header is present than when it is absent, because the spoofed header reaches Django and changes the control flow. After the hotfix, Apache strips the spoofed header before it reaches the application, and the responses match. (Bishop Fox)

That matters because it aligns with the hotfix’s design. The point of the emergency mitigation is to restore the proxy/application trust boundary by unsetting spoofable headers. Your validation should therefore prove that user-supplied certificate-authentication headers no longer affect server behavior. If your team uses a safe check on owned systems, the question is not “Can we weaponize this?” The question is “Can a spoofed header still change the code path?” That is the correct validation target for the patch Fortinet actually shipped. (Bishop Fox)

There is also a broader workflow lesson here. In emergency vulnerability response, the hard part is usually not writing a summary. It is preserving a trustworthy evidence chain from exposure identification to remediation validation. Penligent’s public writing on AI pentest reporting makes exactly that point: a report is only useful if it can survive retest, and evidence matters more than polished prose. That standard fits CVE-2026-35616 almost perfectly. Whether you validate manually or with a more automated workflow, what counts is a reproducible before-and-after record. (penligent.ai)

The same principle appears in Penligent’s public writing on verified AI pentesting, which defines a useful workflow not as “the model thinks it found something,” but as a bounded, replayable process that preserves state and proves claims with inspectable artifacts. For management-plane incidents like this one, that is the right habit: keep the change history, the validation result, and the remediation state tied together. Fast conclusions without replayable evidence are how teams talk themselves into false confidence. (penligent.ai)

The public record is thin on vendor-provided IOCs, so detection should be hypothesis-driven rather than signature-led. WatchTowr explicitly notes that Fortinet had not published indicators of compromise in its writeup timeframe and recommends log review and configuration auditing instead. That should push defenders toward two categories of checks: evidence that spoofed certificate-related headers or abnormal API behavior occurred, and evidence that EMS-controlled policies or administrative objects changed in ways the team cannot explain. (watchTowr)

Here are two simple log-hunting patterns that map cleanly to the disclosed root cause. They are examples, not vendor-provided rules, so field names will need to match your environment.

# Example 1, hunt for spoofed certificate-auth headers reaching your web tier
index=web OR index=proxy
(host="<ems-host>" OR dest="<ems-host>")
("X-SSL-CLIENT-VERIFY" OR "X-SSL-CLIENT-CERT")
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, uri_path, http_status

# Example 2, look for sudden EMS API status anomalies around auth-gated flows
index=web OR index=proxy
(host="<ems-host>" OR dest="<ems-host>")
uri_path="/api/*"
(http_status=401 OR http_status=500)
| timechart span=15m count by http_status

These patterns follow directly from the root cause and from Bishop Fox’s observation that pre-hotfix behavior can diverge when spoofed certificate headers reach Django. If your log pipeline records request headers or reverse-proxy normalization, they are worth running retroactively across the exposure window. (Bishop Fox)

What incident response should look like when IOCs are thin

When the vendor has not handed you a polished IOC pack, you need to build the investigation around high-value state and plausible abuse paths. WatchTowr’s checklist is a good starting point: review endpoint security policies, VPN configuration profiles, application firewall rules, administrator accounts and access controls, and endpoint compliance configurations for unauthorized changes. That list is useful precisely because it is not based on one brittle signature. It is based on what a compromised EMS would be valuable for. (watchTowr)

Fortinet’s own diagnostic tooling supports a more evidence-centered response than many teams realize. The EMS administration guide says a diagnostic logs package can include CPU and memory snapshots, PostgreSQL logs, performance data, and optionally a partial database backup. The same page says the package can be created in the GUI or through EMSCLI using execute diagnostic. In a case like CVE-2026-35616, that makes the diagnostic package part of your triage muscle memory, not an afterthought to open only when support asks for it. (docs.fortinet.com)

That does not mean the diagnostic package is a complete forensic answer. It means it gives you a documented way to preserve server-side state while you decide whether integrity is still defensible. If you suspect an attacker may have interacted with EMS as a configuration authority, preserving database-backed configuration state and related logs early is more valuable than arguing over labels later. The partial database backup option is especially useful for preserving comparison points, even though Fortinet is careful to say it is not a replacement for regular backups. (docs.fortinet.com)

The hardest decision is the one teams postpone too long: whether the server can still be trusted after patching. WatchTowr’s guidance is blunt and reasonable. If compromise is suspected, do not try to “clean in place” unless you can verify integrity with confidence. Restore from a known-good backup from before the likely compromise window, or rebuild the EMS instance and migrate data. For a management plane, trust recovery matters more than uptime pride. The cost of keeping a maybe-clean controller is often higher than the cost of rebuilding it once. (watchTowr)

This is where the timeline matters operationally. If exploitation was observed on March 31 and the public advisory landed on April 4, then the minimum useful retrospective window is not “when we first saw the vendor email.” It is the days before that. The right approach is to anchor your log and configuration review to the earliest plausible exposure period, not to your internal awareness date. (watchTowr)

A practical incident-response matrix for this CVE looks like this:

Workstream	Immediate question	Evidence to preserve	यह क्यों मायने रखती है
Version and exposure	Was EMS on 7.4.5 or 7.4.6 and reachable?	Version records, access paths, firewall state	Establish whether the CVE was relevant and reachable
उपचार	Was the hotfix applied and verified?	Change ticket, emscli --list output, checksum verification	Prove exposure is closed
Server state	Do logs show abnormal API behavior or header abuse?	Web and proxy logs, diagnostic package	Test the disclosed root cause against real traffic
Control-plane integrity	Did policy, profile, or admin state change unexpectedly?	EMS config history, DB-backed objects, account changes	Detect post-compromise use of EMS authority
Trust recovery	Is in-place cleanup trustworthy?	Backup lineage, rebuild plan, validation results	Decide whether to restore or rebuild

The matrix reflects the public guidance and the product’s own documented diagnostic capabilities. (watchTowr)

Hardening FortiClient EMS after the emergency patch

Patching closes today’s hole. Hardening determines whether the next management-plane flaw will turn into the same story. The first control is network reachability. Bishop Fox’s mitigation guidance says the vulnerability requires direct HTTPS access to the EMS web interface on port 443, and Fortinet documents that remote HTTPS administration is a configurable feature. That combination points to an obvious baseline: if administrators do not need broad browser-based access from outside tightly controlled management paths, do not expose it. Limit the interface to dedicated management networks or equivalent restricted paths. (Bishop Fox)

The second control is administrative integrity around policy changes. FortiClient EMS is not only a server that stores data. It is a policy distribution and endpoint control system. That means changes to endpoint profiles, remote access settings, firewall behavior, and administrative accounts should be auditable as first-class security events. Many teams log authentication well enough and configuration poorly. In an EMS environment, that is backwards. A perfect login trail does not help much if malicious policy drift is invisible. (docs.fortinet.com)

The third control is version discipline. The last few months have now produced two actively exploited, unauthenticated critical issues in adjacent FortiClient EMS versions. That should change how teams think about this product’s patching rhythm. The decision should not be “we will update EMS when there is a maintenance window.” It should be “EMS is a high-value management plane and belongs on the same accelerated review track as exposed identity, VPN, and admin-edge systems.” The product’s role in endpoint administration justifies that treatment. (watchTowr)

The fourth control is routine retest. This is the part organizations skip when the pager quiets down. A hotfix applied but not verified is better than nothing, but it is not a finished response. At minimum, teams should confirm that the patch state is visible in EMS, that the interface is no longer broadly reachable where possible, and that a safe validation method shows the header-spoofing behavior is gone. In environments with multiple management surfaces, a repeatable retest workflow matters more than another slide deck. (Bishop Fox)

CVE-2026-21643 and why FortiClient EMS now deserves a different risk model

CVE-2026-35616 is more important if you understand it as part of a pattern. Fortinet’s February 2026 advisory for CVE-2026-21643 describes an unauthenticated SQL injection in FortiClient EMS 7.4.4 that may allow unauthorized code or commands via specifically crafted HTTP requests. Fortinet also said that issue had been observed exploited in the wild, and the fix path was to move 7.4.4 to 7.4.5 or above. The 7.2 and 8.0 branches were listed as not affected. (FortiGuard Labs)

The technical classes are different. CVE-2026-21643 was a SQL injection issue. CVE-2026-35616 is an improper access control and certificate-authentication trust-boundary failure. But from a risk-model perspective, they rhyme in ways that matter more than the labels. Both hit the EMS management plane. Both were reachable by unauthenticated attackers over the network. Both were confirmed exploited. Both force defenders to think about what happens when the endpoint control plane, rather than the endpoints themselves, becomes the adversary’s entry point. (FortiGuard Labs)

Bishop Fox’s analysis of CVE-2026-35616 makes the architectural continuity explicit. Their writeup says the same middleware architecture, OpenApi decorator system, and PostgreSQL connection layer they reverse-engineered for CVE-2026-21643 were central to this one as well. That does not mean the bugs are identical or necessarily chainable. It means defenders should stop treating these as unrelated accidents and start treating FortiClient EMS as a system whose exposed control paths deserve aggressive scrutiny. (Bishop Fox)

A practical comparison helps:

Category	CVE-2026-21643	CVE-2026-35616
Vulnerability class	Unauthenticated SQL injection	Improper access control and API authentication bypass
Affected version range	7.4.4	7.4.5 through 7.4.6
Vendor exploit status	Observed exploited in the wild	Observed exploited in the wild
Fix path	Upgrade to 7.4.5 or above	Apply branch hotfix immediately or move to 7.4.7
Defender lesson	Do not leave 7.4.4 standing	Do not assume the “fixed” successor branch is safe without retest

The table summarizes the official Fortinet advisories and the subsequent fix path for the later CVE. (FortiGuard Labs)

That pattern should also shape your change planning. Imagine the confusion inside a large enterprise running mixed EMS versions across regions. One team knows 7.4.4 is bad because of the SQLi, upgrades to 7.4.5, and then learns days later that 7.4.5 itself is in the affected range for an actively exploited auth bypass. That is not an academic edge case. It is exactly the kind of situation where security, infrastructure, and change-control teams start working from stale mental models. The only defense against that is disciplined version inventory and an assumption that the management plane belongs in the fast lane for security review. (FortiGuard Labs)

Mistakes teams are likely to make in the first 24 hours

The first mistake is treating this as a score problem instead of an exploitation problem. Whether you anchor on 9.1 in the advisory or 9.8 in the NVD’s displayed CNA vector, the issue is already in KEV and already observed exploited. You do not gain anything by debating decimals while the management plane remains exposed. (FortiGuard Labs)

The second mistake is reading only one field on one page. Fortinet’s advisory summary says exploitation was observed in the wild even though the metadata block still shows “Known Exploited No.” Security teams that operationalize off scraped fields without reading the advisory text are especially vulnerable to this kind of mismatch during fast-moving events. (FortiGuard Labs)

The third mistake is patching and stopping there. This is a management-plane vulnerability with a documented root cause in spoofed authentication headers and a known exposure window before public disclosure. That combination should always trigger a second track: validate the fix and review the configuration authority that EMS held during the vulnerable period. (watchTowr)

The fourth mistake is collapsing all nearby FortiClient EMS issues into one memo and one change ticket. CVE-2026-21643 affects 7.4.4. CVE-2026-35616 affects 7.4.5 through 7.4.6. The fix path and urgency differ by branch, and the 7.4.6 upgrade path had its own operational caveats. Sloppy version thinking is how outage risk and security risk reinforce each other. (FortiGuard Labs)

The fifth mistake is assuming cloud and self-managed deployments are interchangeable in the response plan. Fortinet’s advisory specifically says FortiClient Cloud and FortiSASE were remediated by the vendor and require no customer action for this issue. If you manage both vendor-hosted and self-managed products, your incident communication needs to preserve that distinction. (FortiGuard Labs)

CVE-2026-35616 takeaway

The most important lesson in CVE-2026-35616 is not only that a bad auth bypass was found and hotfixed. It is that FortiClient EMS now clearly belongs in the same risk conversation as other exposed control planes that can shape enterprise trust, endpoint posture, and remote access behavior. Fortinet’s own documentation makes clear how much authority EMS holds. The last few months of FortiClient EMS advisories make clear that attackers understand that authority too. (docs.fortinet.com)

If you run self-managed EMS on 7.4.5 or 7.4.6, the immediate priorities are simple: apply the published hotfix or move to 7.4.7, verify the remediation behavior, preserve and review server-side evidence, audit high-value configuration state, and decide honestly whether the instance is still trustworthy. If your EMS interface was reachable during the exploitation window, handle the response like a control-plane security incident, not like routine maintenance. (FortiGuard Labs)

Further reading and reference links

Fortinet PSIRT advisory for CVE-2026-35616, affected versions, exploitation statement, hotfix guidance, and cloud-service status. (FortiGuard Labs)

NVD entry for CVE-2026-35616, including KEV status, due date, CWE, and displayed CNA vector. (nvd.nist.gov)

Fortinet 7.4.5 hotfix instructions, including checksum and emscli flow. (docs.fortinet.com)

Fortinet 7.4.6 hotfix instructions and resolved-issues page identifying the hotfix build that fixes the CVE. (docs.fortinet.com)

Fortinet 7.4.7 resolved-issues page showing the issue no longer affects that version. (docs.fortinet.com)

Bishop Fox technical analysis of the root cause, trusted-header issue, certificate-chain validation weakness, and non-destructive validation logic. (Bishop Fox)

watchTowr’s exploitation timeline and incident-response guidance focused on configuration auditing and trust recovery. (watchTowr)

FortiClient EMS administration documentation covering centralized endpoint management, remote HTTPS administration, endpoint profiles, deployment behavior, and diagnostic package generation. (docs.fortinet.com)

Fortinet PSIRT advisory for CVE-2026-21643, which is useful context for understanding why EMS should now be treated as a higher-priority management-plane risk. (FortiGuard Labs)

Penligent’s public article on AI pentest reports and evidence-backed retesting, which is relevant to post-patch validation and defensible reporting. (penligent.ai)

Penligent’s public article on verified AI pentesting workflows, which is relevant to repeatable remediation validation for exposed management systems. (penligent.ai)