FortiSandbox, the Fortinet appliance that detonates suspicious files in an isolated environment, carries three vulnerabilities that, chained together, let an attacker with no credentials run commands as root on the device itself. No phishing, no stolen password, no second factor to defeat: reaching its management interface over the network is enough.
This is no longer hypothetical. CISA added CVE-2026-25089 to its Known Exploited Vulnerabilities (KEV) catalogue on 16 July 2026 and set 19 July as the remediation deadline for US federal agencies. Weeks earlier, several research teams had already documented active exploitation.
One point is worth making early, because it changes how the case reads: the fixed versions were already available when CISA issued its alert. The risk here does not lie in the absence of a patch, but in how long a security appliance can sit unpatched and unwatched.
What FortiSandbox is, and why this case is different
FortiSandbox receives suspicious files and URLs from the rest of the stack — the firewall, the mail gateway, the endpoint — runs them in a controlled environment and returns a verdict: malicious or not. It is a trusted node, sitting in a sensitive part of the network and wired into much of the surrounding security infrastructure.
That is why compromising it is nothing like compromising a laptop. Whoever gains root on this device gains visibility into what the organisation treats as suspicious, and inherits the appliance's privileged integrations with the rest of the stack. There is a further consequence worth stating carefully, because it has not been reported as observed in these attacks: with full control of the system, the reliability of the verdicts themselves can no longer be taken for granted. The control built to detect the attacker becomes their foothold.
Anatomy of the chain: three flaws that fit together
It is worth understanding the mechanics at a conceptual level, because it explains why the risk is so high. There are no exploits or reproducible steps here — only the logic of how three weaknesses fit together.
CVE-2026-39813: reading what you should not
This is a pre-authentication path traversal in the management interface. It lets an unauthenticated attacker read arbitrary files from the appliance's file system, including the configuration store where administrative credentials live. Put another way: the attacker does not need an account, because they can read the very material used to administer the device.
CVE-2026-39808: from reading to executing
This is an unauthenticated OS command injection (CWE-78), rated CVSS 9.1. An API endpoint accepts attacker-controlled input and passes it to the system command interpreter without neutralising special characters, so what should have been treated as data ends up running as an instruction. The outcome is command execution with root privileges.
CVE-2026-25089: the same class of flaw, in the web interface
Another OS command injection, this time in the web management interface and likewise exploitable remotely without authentication. It is the one CISA has flagged as exploited. Its severity appears with two different values depending on the source: the CNA record puts it at CVSS 9.8 and the PSIRT advisory at 9.1. The difference reflects the criteria behind each metric and does not change the conclusion: it is critical either way.
The problem is not each flaw in isolation but how they combine. The path traversal allows authentication to be bypassed and the command injection supplies the execution; chained, they deliver root access with no prerequisite beyond network reach to the device. No password, no second factor, no user interaction.
Severity, versions and active exploitation
Fortinet shipped the fixes over the course of 2026, and active exploitation was documented in mid-June, weeks before CISA added CVE-2026-25089 to its KEV catalogue on 16 July. The timeline is recorded by several independent teams: Help Net Security, Qualys, Security Affairs and The Register, alongside CISA's own alert.
| Branch / product | Affected versions | Fixed version |
|---|---|---|
| FortiSandbox 4.2 | All 4.2.x releases | Move to a supported branch (4.4.9+ / 5.0.6+) |
| FortiSandbox 4.4 | 4.4.0 – 4.4.8 | 4.4.9 or later |
| FortiSandbox 5.0 | 5.0.0 – 5.0.5 | 5.0.6 or later |
| FortiSandbox Cloud | 5.0.4 – 5.0.5 | 5.0.6 or later |
| FortiSandbox PaaS | 5.0.4 – 5.0.5 | 5.0.6 or later |
Always confirm the exact version and Fortinet's official PSIRT advisory before planning the upgrade.
The difference in scoring does not change the operational call: a critical flaw, exploitable without authentication and with confirmed exploitation, is prioritised the same whether it sits at 9.1 or 9.8. The point is that the score alone is not enough — you have to cross it with real exploitability and with the criticality of the asset, which is exactly what a KEV, EPSS and SSVC approach to prioritisation is for.
Why your usual controls do not cover this case
Most security plans assume an attacker needs an identity to get in. Here they do not. Because the chain requires no authentication, the second factor and identity policies are beside the point: there is no login to harden.
On top of that, security appliances tend to live in a blind spot. They do not run the EDR agent that watches your servers, they are monitored less closely than business workloads and they often keep a management interface reachable from more networks than they would ever need. The device you trust most ends up being the one you observe least.
Detection: what to look for if you run FortiSandbox
Even before patching, it is worth hunting for signs the chain has already been used. Some starting points for your operations team or your detection service:
- Management-interface access from unusual addresses or at odd hours, and anomalous HTTP requests towards the API endpoints.
- Unexpected outbound processes or connections originating from the appliance itself: an analysis box should not be initiating arbitrary traffic to the outside world.
- Changes to administrative accounts: new accounts, privilege escalations or configuration edits outside approved change windows.
- Anomalous reads of the configuration store, or file-system access that does not match the device's normal operation.
- Inconsistent verdicts: if samples that ought to be flagged as malicious slip through as clean, tampering with the analysis engine is worth ruling out.
If you have no visibility over these indicators, that is the conversation to have with your managed SOC or your threat hunting service, because the appliance is rarely wired into central telemetry by default.
Defence: the patch is the first step, not the last
The fix is necessary, but stopping at “update and forget” leaves loose ends. A sensible plan:
- Update to FortiSandbox 4.4.9 or 5.0.6 (or later, depending on the branch); on Cloud and PaaS, to 5.0.6 or later.
- Take management off the internet. The admin interface should not be reachable from public networks or user segments: restrict it to a dedicated management network.
- Assume compromise if the device was exposed. Rotate administrative credentials and the integration tokens shared with the firewall, mail gateway and endpoint, and review accounts and configuration.
- Be ready to respond. If you find signs of exploitation, trigger your incident response procedure before you rebuild and erase evidence.
- Watch your exposure continuously: knowing which appliances and management panels are reachable from outside is part of attack surface management.
The underlying point is that this is risk-based vulnerability management, not a one-off patch. A flaw on the KEV catalogue justifies a tighter remediation deadline than your usual monthly cycle.
NIS2, DORA and ENS: this is compliance too
The European frameworks do not mention FortiSandbox, but they do govern what this case puts to the test. NIS2 and DORA require an asset inventory — security appliances included — risk-based vulnerability management and incident response on defined timelines: a 24-hour early warning and a 72-hour notification under NIS2. A compromised security appliance is a reportable incident, not a technical footnote.
There is also a third-party dimension: the device is a vendor product and its security forms part of technology supply-chain oversight. If your organisation falls under NIS2 or DORA, you will need to be able to demonstrate the criteria by which you prioritise and remediate flaws like this one.
The uncomfortable lesson
It bears repeating that this is not a reproach aimed at one vendor, nor an isolated case. Any device that concentrates trust and privilege becomes a prime target, as we saw when managing the network became the way in. Your defensive stack is attack surface too: it deserves the same rigour in patching, segmentation and monitoring you reserve for your most critical assets, because when it fails you do not lose a server, you lose the referee.
This article describes the mechanics of the chain at a conceptual level, for defence and detection. It contains no exploits or reproducible steps. Always check the vendor's official versions and advisories before acting on production systems.