CVE-2026-21643

What is FortiClient EMS?

Fortinet FortiClient Enterprise Management Server (EMS) is a centralized management platform for deploying, configuring, and monitoring FortiClient endpoint security agents across enterprise environments. It is deployed on-premises as a Windows Server application and supports Windows, macOS, Linux, and mobile endpoints.

Key functions include:

• Endpoint policy management — centrally deploy and enforce security policies (firewall rules, web filtering, antivirus settings, application control) across all managed devices
• VPN configuration — distribute and manage SSL-VPN and IPsec VPN profiles to endpoints
• Zero Trust Network Access (ZTNA) — enforce posture-based access controls before granting network access
• Multi-tenant support — allow a single EMS instance to serve multiple customers or departments with isolated schema contexts
• Fortinet Security Fabric integration — share endpoint telemetry with FortiGate, FortiAnalyzer, and other Fortinet products for coordinated response

EMS is a high-value target because it sits at the intersection of trust and access: it controls security policy across every managed endpoint, and a compromise gives an attacker a privileged channel to weaken defenses, push malicious configurations, or pivot laterally to the entire managed fleet. For Managed Service Providers, a single EMS compromise can affect multiple customer organizations simultaneously.

Overview

Fortinet FortiClient EMS 7.4.4 contains a pre-authentication SQL injection vulnerability (CWE-89) in its multi-tenant middleware. An unauthenticated remote attacker can inject arbitrary SQL via the Site HTTP header, enabling unauthorized data exfiltration or code execution on the database server. The vulnerability exists because the SiteMiddleware — introduced as part of the 7.4.4 multi-tenant refactor — executes before the AuthMiddleware, embedding the unsanitized header value into a raw SQL SET search_path statement before any credential check occurs.

Exploitation was confirmed in the wild weeks after Fortinet's February 2026 patch release, and CISA added the CVE to the Known Exploited Vulnerabilities catalog on April 13, 2026 with a three-day remediation deadline — reflecting the active exploitation and high exposure risk.

This CVE is distinct from but closely related to CVE-2026-35616 (CVSS 9.8), a separate improper access control flaw affecting FortiClientEMS 7.4.5–7.4.6 that was exploited as a zero-day. Organizations that patched 7.4.4 to 7.4.5 to remediate this CVE subsequently became exposed to CVE-2026-35616 — underscoring the need to track the full patch chain.

Affected Versions

Fix: Upgrade to FortiClientEMS 7.4.5 or later. Note that 7.4.5 and 7.4.6 are vulnerable to the related CVE-2026-35616; the fully safe target is 7.4.7 or the latest available release.

Technical Details

The vulnerability was introduced in FortiClientEMS 7.4.4 as part of a major middleware refactoring that added multi-tenant schema isolation. The SiteMiddleware reads an HTTP Site header to identify the tenant context and passes its value to PostgresConnection, which constructs a SET search_path statement using format-string interpolation rather than parameterized identifiers:

self.searchpath = f"SET search_path TO '{self._db_prefix}{self.db_name}', public, addons"

Because the Site value is embedded directly in the query string with no escaping, an attacker can break out of the quoted context with a single quote and append arbitrary SQL. The SiteMiddleware executes before AuthMiddleware, so the injected SQL runs before any authentication check.

Most practical attack endpoint: GET /api/v1/init_consts — requires no authentication, carries no rate limiting, and returns PostgreSQL errors in HTTP 500 responses, enabling reliable error-based single-request data extraction.

Exploitation methods confirmed in research:

• Error-based extraction — CAST type conversion errors leak query output directly in the HTTP 500 response body; no brute-forcing required
• Time-based blind — pg_sleep() payloads confirm injection and can extract data bit-by-bit
• Stacked queries — semicolon separation allows arbitrary SQL command execution

Attack characteristics:

• No credentials or session required (pre-authentication)
• Network-reachable with a single HTTP request
• Exploitation requires multi-tenant mode enabled (SITES_ENABLED: true); single-tenant deployments are not vulnerable

CWE-89 (SQL Injection): User-controlled data is incorporated into a SQL query without adequate neutralization, allowing the attacker to alter query logic. Fixed in 7.4.5 by replacing format-string construction with psycopg.sql.Identifier() for proper escaping.

Discovery

CVE-2026-21643 was discovered internally by Gwendal Guégniaud of the Fortinet Product Security Team. Fortinet published PSIRT advisory FG-IR-25-1142 on February 6, 2026 alongside the 7.4.5 patch. Post-disclosure technical analysis was subsequently published by Bishop Fox, whose research detailed the root cause via bytecode comparison across 7.4.3, 7.4.4, and 7.4.5, and confirmed the error-based extraction path via /api/v1/init_consts.

Exploitation Context

Active exploitation was first observed by Defused Cyber honeypot infrastructure approximately four days after public proof-of-concept details became available — roughly March 26, 2026, well after the February patch release but consistent with the window when reverse-engineered PoC tooling became publicly circulated. On March 30, 2026, Defused Cyber issued a public warning that the CVE was under active attack despite not yet appearing on the CISA KEV list.

Observed attack patterns included reconnaissance requests to /api/v1/init_consts to confirm EMS version and check SITES_ENABLED status, followed by systematic error-based SQL injection from single source IPs at high request rates consistent with automated exploitation.

Fortinet products have been a sustained target: at the time of this CVE's KEV listing, over 20 Fortinet CVEs appeared on the CISA KEV catalog, and the related CVE-2026-35616 was added simultaneously — both actively exploited within days of each other.

Remediation

1. Patch to 7.4.7 or later — do not stop at 7.4.5 or 7.4.6, as those versions are affected by the related CVE-2026-35616; upgrade directly to the latest available release
2. Restrict network access — if patching is delayed, block all inbound access to the EMS management interface (TCP 443) from untrusted networks using firewall ACLs; EMS should never be internet-facing
3. Verify multi-tenant mode — query GET /api/v1/init_consts and check for "SITES_ENABLED": true; single-tenant deployments with this flag set to false are not vulnerable to this specific path
4. Deploy via VPN or bastion host — route all EMS management access through a VPN or jump host rather than exposing the web interface directly
5. Audit for compromise — review EMS API logs for unexpected HTTP 500 responses from /api/v1/init_consts, bursts of requests with unusual Site header values, unauthorized account creation, or unexpected policy changes pushed to endpoints
6. Apply CVE-2026-35616 patch simultaneously — if upgrading from 7.4.4, skip directly to 7.4.7 to avoid landing on an intermediate version vulnerable to the related improper access control flaw
7. Discontinue use if patching and network isolation cannot be achieved before the BOD 22-01 deadline