The Chain Nobody's Advisory Describes: FortiSandbox's Three CVEs, Read Together

This site covered CVE-2026-25089 on its own four days ago: an unauthenticated OS command injection in FortiSandbox’s Web UI, actively exploited since mid-June, CISA KEV since July. That post is still accurate on its own terms. What it didn’t cover, because the source I was working from at the time didn’t connect it, is that CVE-2026-25089 isn’t the only unauthenticated bug FortiSandbox shipped this year, and at least one threat intelligence firm has reported seeing all three chained together into something worse than any of them individually.

The chain, as reported

Threat intelligence firm Defused published a report in June describing active exploitation of a three-CVE chain against FortiSandbox, distinct from and in addition to what I covered in the earlier post. The reported sequence:

CVE-2026-39813 (FG-IR-26-112, disclosed 16 April 2026) is a pre-authentication path traversal in FortiSandbox’s JRPC API, CWE-24, letting an unauthenticated attacker read arbitrary files off the appliance filesystem. Defused’s report describes attackers using that file-read capability specifically to pull the FortiSandbox configuration database and extract local admin credentials stored in it, turning a read-only bug into a working set of admin credentials.

CVE-2026-25089 (FG-IR-26-141, the CVSS 9.8 command injection covered in the earlier post) gets delivered next, but as an authenticated administrator action using the credentials just extracted, rather than the unauthenticated path Fortinet’s own advisory describes. Same vulnerability, different precondition, because the attacker walked in the front door instead of needing to skip it.

CVE-2026-39808 (also under FG-IR-26-112, same April disclosure as the path traversal) is an OS command injection that Defused’s report frames as the chain’s privilege-escalation step, taking the code execution already achieved and elevating it to root on the underlying system.

The complete sequence Defused describes: file read exposes admin credentials, credentials authenticate the command-injection payload, a second command-injection bug pushes that access to root. The practical result is unauthenticated root code execution, achieved through a path Fortinet’s own per-CVE severity ratings don’t individually suggest, since each bug on its own reads as bad but bounded, and only the combination removes every precondition at once.

Worth being precise about what’s confirmed and what isn’t

Everything in the section above comes from Defused’s June report and the secondary coverage of it, not from Fortinet’s own advisories, and it’s worth treating that distinction carefully rather than blending the two together. Fortinet’s PSIRT advisories (FG-IR-26-112 and FG-IR-26-141) confirm the individual vulnerabilities, their CVSS scores, and the affected version ranges. They don’t describe a chained attack path, and Fortinet hasn’t, as far as I can find, published anything acknowledging the specific three-step sequence Defused reports. Defused’s own account states patches for all three CVEs shipped in “FortiSandbox 5.4.3,” which doesn’t match the version numbers in Fortinet’s own advisories at all, those name 4.4.9 and 5.0.6 as the fixed releases on the 4.4.x and 5.0.x branches respectively. That’s either an error in Defused’s report, a reference to some other release branch entirely, or a detail Fortinet’s own advisory pages simply don’t reflect. I can’t resolve which, so I’m flagging it rather than repeating “5.4.3” as if it were confirmed.

None of that makes the underlying story implausible. Chaining a file-read bug into stolen credentials into a privileged RCE is an unremarkable, well-precedented attack pattern, and Defused’s report also states intrusion artifacts were found across at least seven FortiSandbox deployments in North American and European financial services and critical infrastructure. But a single threat intelligence vendor’s account of a chain, without a corroborating vendor advisory describing the same sequence, is a different evidentiary category than a CVE with a PSIRT record behind it, and this site has held that distinction before. Treat the individual CVEs as confirmed, since Fortinet’s own advisories say so, and treat the specific three-step chain as reported by one firm, credible, but not yet independently corroborated.

Why a chain against this specific product is worse than the sum of its parts

FortiSandbox’s job, as I described in the earlier post, is opening files that other Fortinet products, FortiGate, FortiMail, FortiWeb, decided were too suspicious to open themselves, then returning a verdict those products treat as authoritative. An attacker with root on the box that issues that verdict doesn’t need to touch any of the products depending on it. They can make FortiSandbox lie about files it’s asked to check, and nothing downstream has an independent way to notice the verdict was manipulated, because checking that verdict is the entire reason FortiSandbox exists in that architecture. A chain that gets an attacker to root without ever needing a stolen credential from anywhere else on the network is precisely the worst-case shape of bug this specific appliance can have.

What to actually check

If you run FortiSandbox anywhere, this isn’t really about which specific version string to chase. Confirm you’re on 4.4.9 or later on the 4.4 branch, or 5.0.6 or later on the 5.0 branch, since those cover the individually-confirmed CVEs regardless of whether the chain reporting turns out to be exactly right. Then go further than the version check: review FortiSandbox’s own admin audit logs for unexplained authentication events or configuration database access, since if the chain reporting is accurate, credential theft happened silently through a read path that a version check alone won’t reveal after the fact. And restrict the management interface to a dedicated network or jump host, the same mitigation Fortinet’s own advisory already recommends for CVE-2026-25089 in isolation, since it closes the entry point the whole chain depends on regardless of which individual step turns out to matter most.

Sources: Fortinet PSIRT FG-IR-26-141 · Fortinet PSIRT FG-IR-26-112 · Qualys ThreatPROTECT: Fortinet FortiSandbox Vulnerability Exploited by Attackers · Daily Security Review: Three FortiSandbox CVEs Chained for Unauthenticated Root Execution