FortiClientEMS 7.4.4: SQL injection (CVE-2026-21643)
An unauthenticated remote caller can inject SQL into FortiClientEMS 7.4.4 and potentially execute commands. Update the management server to protect its data and host privileges.
Public CVE record · Vendor or publisher advisory · Native module source
| Field | Value |
|---|---|
| Affected component and versions | Fortinet FortiClientEMS · see the advisory for affected versions and configuration |
| Fixed release | 7.4.5, 8.0.0 |
| Severity | CVSS 9.1 |
| Evidence status | Recorded fixture comparison |
| Test environment | Lab fixture or affected build documented in the evidence below |
| Eden release and module version | 1.103.0 |
| Tested at | 2026-11-12 UTC |
| First publicly published | 2026-11-12T18:25:13Z |
CVE advisory record · Vendor advisory · Module source
Result. The marked request reached the backend in the baseline and raised its counter. The native rule refused that request with HTTP 403 and preserved HTTP 200 for the benign probe. The synthetic fixture ran through Eden 1.103.0 on November 12, 2026 (UTC).
The vulnerability
The affected FortiClientEMS release can process crafted unauthenticated HTTP requests as part of a SQL operation. The vendor describes unauthorized command or code execution as a possible consequence, so authentication at the management interface does not remove the exposure described by the advisory.
Fortinet lists 7.4.4 as affected and 7.4.5 as the fix for the 7.4 series. The CVE record reports a CVSS base score of 9.1.
The Eden patch
Tier 1 — declarative policy. The recorded policy denies requests to /api/v2/clients and its descendants. The empty method list leaves the deny unrestricted by HTTP method. This is a coarse rule and blocked the benign probe on the same path.
{
"version": 1,
"profile": "http-structure-v1",
"policy": {
"version": 1,
"rules": [
{
"scope": {
"methods": [],
"path": "/api/v2/clients",
"descendants": true
},
"require": {
"kind": "deny"
}
}
]
}
}
Tier 2 — native Rust module. gabriel_forticlient_v1 waits for the request to be complete, checks whether the request target starts with /api/v2/clients, and looks for any configured marker in the body. The substring comparison is ASCII case-insensitive. Outside that prefix or without a marker, the module returns Continue. The shown lines are excerpts from the linked source.
const ROUTE: &[u8] = b"/api/v2/clients";
static NEEDLES: [&[u8]; 3] = [b"' OR ", b"union select", b"1=1"];
NEEDLES.iter().any(|n| find_ignore_case(body, n).is_some()) && return Ok(Decision::Refuse);
Implement the remediation
Use this procedure in an isolated fixture to reproduce the scoped restriction. Follow the vendor update for the underlying exposure. See deployment prerequisites.
- Prepare the target. Verify the loaded product and version against the advisory. Use a compatible Eden HTTP interlay and an authenticated operator with Configure permission. Use the recorded declaration and the linked source when applicable.
- Apply the declarative policy. Scope the policy to
/api/v2/clientsand descendants (all methods,deny). SetINTERLAYto the target interlay UUID in the authenticated Eden CLI. Run an authenticatedGET /api/v1/interlays/{interlay}withX-Eden-Verbose: true. Save its complete current settings object ascurrent-settings.jsonand retain the prior remediation declaration for recovery. SetIDEMPOTENCY_KEYto a fresh key for this intended mutation.
Save the JSON in the patch section as remediation.json.
jq -e --slurpfile policy remediation.json \
'.remediation = $policy[0] | {settings: .}' current-settings.json \
> interlay-update.json
eden api request PATCH "/api/v1/interlays/$INTERLAY" \
--header "Idempotency-Key:$IDEMPOTENCY_KEY" \
--body-file interlay-update.json --content-type application/json --confirm
- Verify the serving policy. Read back the interlay.
eden api request GET "/api/v1/interlays/$INTERLAY" \
--header 'X-Eden-Verbose:true'
Check that remediation_status.state is ready and both desired and effective SHA-256 values match the intended declaration. Replay the benign and marked requests in the recorded comparison on an isolated target. Check the recorded response and backend outcome for each probe.
4. Restore the previous policy. Coordinate the change with any other operator updating this interlay. Read current settings again and merge the saved remediation field into them. If the prior settings had no remediation field, omit it in the replacement. Send the same PATCH with a fresh idempotency key, then read back the intended state. Repeat the verification probes. Keep the affected route isolated if restoring the prior settings reopens exposure.
Vendor update. Use the advisory to select the fixed release for the installed branch. Reported fixed releases include 7.4.5, 8.0.0. Follow the vendor’s update instructions and confirm the version actually loaded by the service.
Fixture and probes
The fixture was a synthetic HTTP handler behind Eden. It answered the probes and kept a separate counter that increased when the handler recognized its marker bytes. The counter measures a fixture effect. An HTTP 200 from the baseline does not by itself establish that the counter moved.
Request. POST /api/v2/clients/search for the benign probe and the marked probe.
The benign fixture searched for active clients. The second sent a SQL predicate marker in the filter value. The backend incremented a counter when it received the matching bytes.
Measured comparison (2026-11-12 UTC)
The values after each status are the observed increases in the backend marker counter.
| Probe | Baseline | Tier 1 route deny | Tier 2 native module |
|---|---|---|---|
| Benign | HTTP 200, 0 | HTTP 403, 0 | HTTP 200, 0 |
| Marked input | HTTP 200, 1 | HTTP 403, 0 | HTTP 403, 0 |
Signed module authority
The module import returned HTTP 201 and required explicit activation. Signature verification was deferred at import. Read-only inspection returned HTTP 403, admission with a tampered statement returned HTTP 400, and admission with an invalid signature returned HTTP 403. The activation receipt reported the module serving on all expected shards.
After revocation, the same marked request received HTTP 503. Re-approval and reactivation restored HTTP 403. The source digest below identifies the linked Rust file. The binary digest identifies the artifact recorded in the activation evidence.
- Source SHA-256
2a133e17b385743e3dee54870c24fcc243aa6295ef7886686e038f2715710d5a - Tested binary SHA-256
4136e7d0741be8f2d5ceefa858e43d6d82d8ac39feab2d264a3901c5d2c8c18a
Test scope
The client-search path is synthetic. The actual FortiClientEMS handler and SQL execution were outside the run. The filter scans the complete request body without associating the marker with a specific parameter or SQL context.
Performance
The public evidence for this case does not include request-latency measurements.