Fortinet FortiSandbox — the appliance organisations deploy specifically to detonate suspicious files in isolation before they reach production systems — had two OS command injection vulnerabilities added to CISA's Known Exploited Vulnerabilities catalogue on the same day: 16 July 2026.
CVE-2026-25089, CVSS 9.8, affects FortiSandbox 5.0.0 through 5.0.5 and 4.4.0 through 4.4.8. CVE-2026-39808, also CVSS 9.8, affects the 4.4.0 through 4.4.8 range. Both are the same vulnerability class — improper neutralization of special elements used in an OS command — disclosed together against overlapping version ranges of the same product.
The irony worth naming plainly
FortiSandbox exists to be the safe place a suspicious file goes. Its entire security model depends on the sandbox itself being more trustworthy than the untrusted content it analyses. A command injection vulnerability in that appliance inverts the tool's purpose: rather than isolating a threat, the appliance becomes the threat's way into whatever network segment it sits on to do its analysis work — typically a segment with direct visibility into other security infrastructure, mail flow, or file transfer pipelines, precisely because that's what it needs to see in order to do its job.
Two CVEs, same class, same disclosure date, overlapping version ranges: this reads as one security review finding two related command-injection paths in the same subsystem rather than two unconnected discoveries, similar to the pattern seen elsewhere in this window across other products. The overlapping affected range (4.4.0–4.4.8 named in both) reinforces that reading.
Why command injection in security appliances specifically deserves urgency
An OS command injection bug means the application is passing attacker-influenced input to a system shell without adequately sanitising it — one of the most direct paths from "the application processed my input" to "the operating system ran my command" that exists. There is no partial exploitation of this bug class: an attacker who can trigger it gets to run arbitrary commands with whatever privilege the vulnerable process holds, which on a purpose-built security appliance is frequently elevated by design so the appliance can inspect files thoroughly.
The version ranges tell their own story
CVE-2026-25089 spans FortiSandbox 5.0.0 through 5.0.5 and 4.4.0 through 4.4.8 — two separate branches, both affected. CVE-2026-39808 spans 4.4.0 through 4.4.8 alone. A vulnerability class that reproduces across both the current 5.0 branch and the older-but-still-supported 4.4 branch suggests the underlying flaw predates the branch split, likely living in shared code that both versions inherited rather than being introduced freshly in either. That has a direct practical consequence: an organisation that upgraded from 4.4 to 5.0 specifically to stay current on security patches may have carried this exact command-injection path forward into the branch it upgraded to, without the upgrade itself resolving anything.
What to check this week
Confirm your FortiSandbox version against both affected ranges precisely. CVE-2026-39808's 4.4.0–4.4.8 range overlaps with CVE-2026-25089's, meaning a device vulnerable to one is very likely vulnerable to both, and a patch addressing only the CVE your team happened to read about first may leave the sibling open.
Treat FortiSandbox's network placement as a live risk factor, not a settled architectural decision. The appliance's value depends on broad visibility into file traffic; that same visibility is what a command-injection compromise turns into an attacker's vantage point.
Audit what has passed through FortiSandbox during the affected window. If exploitation occurred, the appliance itself was the initial point of compromise — meaning its own logs and detonation history are what an incident response effort needs to review first, not a downstream system.
The broader lesson for any "defense in depth" appliance
FortiSandbox is one instance of a category worth naming explicitly: security appliances that organisations deploy as an additional, later layer of defence — sandboxes, secure email gateways, inspection proxies — inherit an unusual amount of implicit trust precisely because they were purchased to increase security. That trust rarely comes with a matching increase in scrutiny of the appliance's own attack surface. A command injection bug in a load balancer gets noticed because load balancers are assumed to be adversarial-input-adjacent by design; the same bug in a sandbox is easy to underestimate, because the product's category implies safety rather than risk. This pair is a concrete reminder that a security product's job description does not exempt it from being, itself, a target.
How Safeguard helps
Safeguard's continuous inventory treats security infrastructure — sandboxes, gateways, inspection appliances — as assets requiring the same scrutiny as the systems they're meant to protect, rather than trusted infrastructure exempt from the review applied elsewhere. Reachability analysis on a device like FortiSandbox is what confirms whether its network position genuinely limits a command-injection bug's blast radius, or whether the visibility the appliance needs to do its job is the same visibility a compromise would inherit.
