CVE-2026-21643: FortiClient EMS SQL injection

CVE-2026-21643 is a critical SQL-injection vulnerability in the FortiClient EMS management server. Fortinet states that an unauthenticated attacker can send specifically crafted HTTP requests to the administrative GUI and execute unauthorized code or commands. The affected server release is exactly FortiClient EMS 7.4.4; Fortinet identifies 7.4.5 or later as the solution.

This finding is about the EMS server version, not the FortiClient agent version installed on managed Windows, macOS, or Linux endpoints. Fortinet also states in the advisory timeline that FortiEMS Cloud is not affected. Do not classify an endpoint or the cloud service as vulnerable merely because its name contains FortiClient.

Evidence basis and limits

I reviewed Fortinet PSIRT advisory FG-IR-25-1142, Fortinet's FortiClient EMS 7.4.5 administration documentation, the current CISA KEV feed, the CVE record, and the NVD record on 2026-07-22. I did not access an EMS deployment, inspect private source, send a crafted request, or validate a customer environment. The affected/fixed versions, attack path, severity, and KEV status below are official source facts rather than observations from a live server.

The current Fortinet advisory and CVE record identify only 7.4.4 as affected. Fortinet lists the 7.2 and 8.0 branches as not affected. Live NVD exact-affects 7.4.4 only. Live GHAD GHSA-r6vr-hwpr-qqch has vulnerabilities empty. Vendor names 7.4.5. 7.4.5 is not an NVD exclude. NVD historically displayed a broader 7.4 range, but its change history records the configuration being corrected to the exact 7.4.4 release. Use the current Fortinet/CVE product status rather than the superseded broad range. Do not invent a later 7.4.6 floor.

Official score displays have also differed, while all current sources classify the issue as critical. This recipe does not depend on a particular numeric score. Re-check FG-IR-25-1142 before approving a change because Fortinet can revise product, exploitation, or upgrade guidance.

Exploitation-status reconciliation

FG-IR-25-1142 currently contains two conflicting Fortinet signals: the advisory narrative says exploitation has been observed in the wild, while its sidebar still displays Known Exploited: No. CISA subsequently added CVE-2026-21643 to the KEV catalog on 2026-04-13 and currently requires U.S. federal civilian agencies subject to BOD 22-01 to apply vendor mitigations or discontinue use when mitigations are unavailable.

For remediation priority, treat the CVE as currently known exploited. That conclusion is based on the current CISA KEV entry and Fortinet's own narrative; it does not erase the contradictory Fortinet sidebar or prove that a particular EMS deployment was attacked. Preserve the source URLs and retrieval date in review evidence instead of silently choosing one historical field. Never try to resolve the discrepancy by probing a server.

When to use this recipe

Use it when a scanner, asset inventory, ticket, repository, or operator identifies a self-managed FortiClient EMS server that may run 7.4.4. The repository may own container/image references, VM definitions, installation or upgrade automation, deployment manifests, database/HA runbooks, ingress or network policy, inventory rules, monitoring checks, or vulnerability exceptions.

Do not use it to test the SQL-injection path, send crafted HTTP traffic, change a live EMS server without authority, or update managed endpoint agents as a substitute for fixing the server. Repository authority is not authority over the EMS application, database, HA cluster, ingress, or endpoint fleet.

Inputs

• A redacted inventory of every EMS server and HA node: owner, environment, deployment model, server version/build, HA role, database topology, and evidence timestamp.
• Approved read-only version evidence from Dashboard > Status > System Information, which Fortinet documents as showing the EMS version, build, hostname, uptime, mode, and database controls.
• Product-boundary evidence distinguishing self-managed FortiClient EMS from FortiEMS Cloud and distinguishing the EMS server release from endpoint FortiClient agent releases.
• Administrative-GUI exposure evidence: listener/ingress configuration, interfaces, DNS/load-balancer path, approved source networks, authentication boundary, and effective reachability from untrusted networks.
• Repository-controlled images, packages, manifests, automation, HA/database definitions, ingress policy, runbooks, generated artifacts, and exceptions.
• The current Fortinet-supported target, upgrade compatibility, database backup and restore plan, HA sequence, endpoint compatibility, maintenance impact, ordinary health checks, and rollback owner.
• Approved security evidence for the exposure window: relevant server, administrative, application, database, identity, ingress, and centralized logs; existing alerts; incident owner; and Fortinet support status.

Do not commit credentials, certificates, license data, full database backups, raw logs, diagnostic bundles, endpoint inventories, hostnames, network topology, or customer data. Keep sensitive operational and forensic evidence in its approved system.

Affected and fixed versions

Fortinet publishes the following current matrix:

FortiClient EMS branch	Status for CVE-2026-21643	Required action
7.4 release 7.4.4	Affected	Upgrade to 7.4.5 or later
7.2	Not affected according to FG-IR-25-1142	No CVE-specific upgrade required
8.0	Not affected according to FG-IR-25-1142	No CVE-specific upgrade required
FortiEMS Cloud	Not affected according to the advisory timeline	No CVE-specific customer upgrade

Do not expand the affected set to every 7.4 release, and do not treat a managed FortiClient endpoint running version 7.4.4 as proof that its EMS server is affected. Conversely, endpoint-agent versions do not clear an EMS server that runs 7.4.4.

7.4.5 is the first fixed threshold documented by Fortinet, not necessarily the best long-term target on 2026-07-22. Select a currently supported Fortinet release at or above that threshold, compatible with the EMS deployment model, database, HA topology, integrations, and managed endpoint versions.

How to determine exposure safely

Fortinet documents a read-only GUI path for the server version:

1. Through an approved authenticated session, open Dashboard > Status.
2. Read System Information > Version, including its build number and any interim-build label.
3. Record whether the System Information widget reports standalone or HA mode, then obtain equivalent evidence for every HA node.
4. Redact the hostname and other environment identifiers before attaching evidence to a code review.

If no live-session authority is granted, use an operator-provided screenshot, signed asset inventory, installed-package report, or deployment evidence and mark the live version unverified. A container tag, desired-state manifest, or scanner result can locate ownership, but it is not proof of the running server.

Then establish reachability using approved configuration evidence:

• identify the administrative GUI listener and every ingress, proxy, load-balancer, VPN, and network policy in front of it;
• record which source networks can reach it and whether an untrusted network or compromised internal host could access that path; and
• determine the exposure window for every period in which 7.4.4 was running.

An EMS 7.4.4 server is affected even when its administrative GUI is private; restricted reachability changes attack opportunity and containment priority, not the vendor's affected-version status. Do not send a crafted request, SQL fragment, malformed parameter, callback, or other active probe. Version and configuration evidence are sufficient to require remediation.

Incident-response gate

Resolve the incident question before routine upgrade work because the CVE is currently in CISA KEV and Fortinet's narrative reports observed exploitation:

• If approved logs, alerts, or operator reports suggest attempted exploitation, unexpected administrative behavior, database activity, accounts, configuration changes, or command execution, stop the patch-only workflow.
• Preserve relevant evidence and notify the incident owner and Fortinet support before changing the server, database, ingress, credentials, or logs.
• Do not reboot, upgrade, restore, delete data, rotate credentials, or remove suspected artifacts until the incident owner decides what must be retained.
• Do not declare the server clean because one indicator or alert is absent.
• A fixed EMS version closes the vulnerable entry path; it does not establish recovery trust for a server that may already have been compromised.

This is conservative incident handling based on known exploitation. The public Fortinet advisory does not provide a complete forensic checklist for every EMS deployment model.

Temporary containment

FG-IR-25-1142 does not publish a product-specific workaround. Do not invent one or describe a WAF rule, request filter, endpoint-agent update, or version string check as vendor mitigation.

When an immediate upgrade is impossible, the responsible network and service owners may consider time-bounded isolation or strict source restriction of the administrative GUI as defense in depth. Label that as a local containment decision, not a Fortinet workaround or remediation. Record the approving owner, affected administration workflows, alternate access path, effective policy, validation, expiry, and restoration plan. If safe containment cannot be proved, stop with TRIAGE.md and escalate the upgrade or discontinuation decision required by the current CISA KEV action.

How to remediate CVE-2026-21643

1. Inventory every standalone or HA EMS server, deployment artifact, database, and reinstall/recovery path. Exclude FortiEMS Cloud and endpoint agents from the server-upgrade matrix, but preserve endpoint compatibility evidence.
2. Resolve the incident-response gate before changing an exposed 7.4.4 server. Suspected compromise requires evidence preservation and an incident owner, not a patch-only conclusion.
3. Select a currently supported FortiClient EMS release at or above 7.4.5. Fortinet documents direct 7.4.5 upgrade support from EMS 7.4.3 and 7.4.4; validate the current vendor path for any newer target.
4. Verify EMS-to-FortiClient compatibility. Fortinet documents that EMS 7.4.5 supports FortiClient 7.4 and 7.2, so endpoint compatibility is a rollout prerequisite even though endpoint versions do not cause this CVE.
5. Back up the EMS database through the approved Fortinet procedure and recovery owner. Keep the backup and its password outside Git. When incident response is active, let the incident owner decide backup and preservation order.
6. Update every repository-controlled image/package reference, VM/container or Kubernetes definition, automation, HA/database runbook, ingress policy, inventory rule, monitor, generated artifact, and recovery definition that could reinstall 7.4.4.
7. For HA, document the human-reviewed node sequence and database implications. Fortinet recommends manual node upgrades rather than automatic upgrade for HA clusters.
8. Keep live upgrade, database, HA, ingress, credential, and endpoint-fleet actions with the authorized operator unless the task explicitly grants that exact production authority.

How to verify remediation

• Re-open Dashboard > Status > System Information and confirm that every running EMS node reports 7.4.5 or a later approved release, including the expected build and HA mode.
• Verify the running server, not merely a downloaded installer, image tag, desired-state manifest, or scheduled upgrade.
• Confirm repository-controlled images, manifests, automation, HA/recovery definitions, and generated artifacts no longer resolve to 7.4.4.
• Run existing non-adversarial checks for EMS login, Dashboard status, database health, license state, endpoint connectivity/telemetry, integrations, monitoring, and HA health. Do not exercise the SQL-injection path.
• Confirm any local administrative-GUI containment remains tracked with an owner and expiry or was removed through the approved restoration plan after fixed-version evidence was collected.
• Record target, HA role, before/after version and build, evidence time, verifier, database/HA result, ordinary health checks, and unresolved incident actions.

Do not suppress the finding until every controlled EMS node and reinstall path has fixed-version evidence. Do not call the environment uncompromised based on a successful upgrade or normal endpoint telemetry.

Rollback and stop conditions

Prefer forward recovery to another supported fixed release. If an operational regression requires restoring the Fortinet-documented EMS database backup or a prior server artifact, confirm that the application version and database are compatible. A rollback to 7.4.4 restores vulnerable software: isolate the administrative GUI through the approved local containment, retain an incident and upgrade owner, and set a time-bounded return to fixed software.

Stop and write TRIAGE.md when:

• the product boundary, running EMS version/build, HA membership, database topology, or administrative-GUI reachability cannot be proved;
• evidence refers only to managed endpoint agents or FortiEMS Cloud rather than the self-managed EMS server;
• the repository does not own the deployment, image, upgrade automation, ingress, or runbook needed for remediation;
• suspected exploitation creates an evidence-preservation or incident-response decision;
• the target release, upgrade path, endpoint compatibility, database backup, HA sequence, maintenance window, ordinary health checks, or rollback cannot be validated safely;
• containment or remediation requires live EMS, database, ingress, HA, credential, or endpoint-fleet authority not granted by the task; or
• meaningful verification would require crafted HTTP traffic, SQL injection, active probing, sensitive-data access, or a destructive test.

TRIAGE.md must name CVE-2026-21643, files and evidence inspected, redacted EMS target and owner, deployment model, observed and required server version, HA and database state, GUI reachability, exploitation-status source discrepancy, containment, compromise concern, authority or compatibility blocker, next responsible human, and safest next action.

The prompt

You are remediating CVE-2026-21643, a critical, currently KEV-listed SQL-
injection vulnerability in the FortiClient EMS administrative GUI.

Return exactly one output:

- a reviewer-ready change set that updates every repository-controlled,
  self-managed FortiClient EMS 7.4.4 server to a supported release at or above
  7.4.5 and documents safe verification, incident handling, and rollback; or
- `TRIAGE.md` when ownership, live state, evidence preservation, upgrade
  safety, authority, or verification cannot be resolved here.

### Guardrails

- Scope only CVE-2026-21643 and directly related EMS server inventory,
  version/image targets, administrative-GUI exposure, database/HA upgrade
  artifacts, safe verification, containment, and incident handoff.
- Do not confuse the EMS server with managed FortiClient endpoint agents.
  FortiEMS Cloud is not affected according to Fortinet's advisory timeline.
- Do not connect to, scan, probe, or mutate a live EMS deployment unless the
  task explicitly grants that exact authority.
- Do not generate, copy, or send a crafted HTTP request, SQL fragment,
  malformed parameter, callback, file, or proof-of-concept.
- Do not treat a scanner string, endpoint-agent version, container tag,
  desired-state file, or scheduled upgrade as proof of the running EMS version.
- Treat this CVE as currently known exploited: Fortinet's narrative reports
  observed exploitation and CISA added it to KEV on 2026-04-13, despite the
  Fortinet sidebar still displaying `Known Exploited: No`.
- Do not store credentials, certificates, license data, database backups, raw
  logs, diagnostic bundles, endpoint inventories, hostnames, topology, or
  customer data in Git.
- Do not upgrade, reboot, restore, fail over, modify ingress, rotate
  credentials, or remove suspected artifacts automatically.
- Do not describe a fixed server as proof that prior compromise did not occur.

### Steps

1. Inventory repository-owned EMS images/packages, VM/container/Kubernetes
   definitions, automation, HA/database topology, ingress, runbooks, monitors,
   generated artifacts, recovery definitions, and vulnerability exceptions.
2. Build a redacted target matrix containing owner, deployment model, running
   EMS version/build and evidence date, HA role, database, administrative-GUI
   reachability, desired fixed release, endpoint compatibility, and repository
   control point. Separate EMS server data from endpoint-agent data.
3. Classify using the current Fortinet matrix:
   - EMS 7.4.4: affected; upgrade to 7.4.5 or later.
   - EMS 7.2 and 8.0: not affected.
   - FortiEMS Cloud: not affected according to the advisory timeline.
   Do not expand the affected range based on superseded NVD data.
4. Resolve the incident-response gate from approved, already-available
   evidence. If suspicious activity exists, stop routine patching, preserve
   evidence, and name the incident owner and Fortinet support handoff.
5. Select a currently supported EMS release at or above 7.4.5 and validate
   upgrade, endpoint compatibility, database backup/restore, HA sequence,
   maintenance, normal health checks, and rollback.
6. Update all repository-controlled images, definitions, automation, ingress
   policy, inventory rules, runbooks, monitors, generated artifacts, and
   recovery paths that could reinstall or expose 7.4.4.
7. If upgrade cannot be immediate, document only human-approved local
   administrative-GUI isolation/source restriction as defense in depth.
   Fortinet publishes no product-specific workaround in FG-IR-25-1142.
8. Add static policy tests that fail when a controlled EMS server, HA node,
   generated artifact, or recovery path remains at 7.4.4, or when an exception
   lacks owner, expiry, evidence, and fixed target.
9. Run only repository schema, formatting, rendering, and policy checks plus
   existing ordinary EMS health checks. Never exercise the SQL-injection path.
10. Document operator-only actions: database backup, upgrade/HA sequence,
    maintenance impact, Dashboard version verification, normal health checks,
    containment removal, and rollback.

### Stop conditions

Stop with `TRIAGE.md` if the server boundary or running version is unknown;
compromise is possible; the target, compatibility, backup, HA plan, or rollback
is unvalidated; live changes exceed authority; or verification would require
crafted traffic, exploit behavior, sensitive evidence, or a destructive test.

The output must distinguish repository evidence, operator-supplied evidence,
and unverified live state. It must preserve the Fortinet/CISA status
discrepancy and must not claim a server was patched, protected, or clean
without authorized execution evidence.

Output contract

Return one of:

• A reviewer-ready PR/change request that inventories every controlled EMS server, updates all image/package/deployment/HA/recovery references to an approved release at or above 7.4.5, supplies safe tests, and records human-owned database backup, upgrade, verification, incident, and rollback actions.
• TRIAGE.md containing bounded evidence, owner, deployment model, observed and required EMS server version, HA/database state, GUI reachability, exploitation status and source dates, containment, compromise concern, authority or compatibility blocker, and next action.

The output must say what was verified from repository artifacts, what came from an operator, and what remains unverified. It must not contain exploit material or claim that a live EMS deployment is fixed or trustworthy without approved execution evidence.

Primary references

• Fortinet PSIRT advisory FG-IR-25-1142
• GitHub Advisory GHSA-r6vr-hwpr-qqch
• Fortinet EMS 7.4.5 System Information widget
• Fortinet EMS 7.4.5 upgrade guidance
• Fortinet automatic-upgrade, backup, and HA guidance
• CISA Known Exploited Vulnerabilities catalog entry
• CISA KEV JSON feed
• CVE Program record for CVE-2026-21643
• NVD record for CVE-2026-21643

Related recipes

• CVE intelligence intake gate
• CVE-2025-25257 FortiWeb SQL injection
• How to remediate vulnerabilities with AI agents