FortiSandbox CVE-2026-25089: Unauth RCE in the Box That Judges Your Malware

CISA gave U.S. federal agencies until Sunday, 19 July 2026 to patch two Fortinet FortiSandbox flaws — a three-day window that only exists because attackers are already inside the fleet. Both are unauthenticated OS command injection bugs rated CVSS 9.8 on NVD, and Fortinet shipped fixes for them back in April and June. The interesting part is not the patch lag. It is which box got popped. FortiSandbox is not a firewall or a VPN concentrator. It is the appliance the rest of your Fortinet fabric asks before it decides whether a file is malware. Remote code execution on the judge is a different class of problem than RCE on a guard.

What FortiSandbox actually is

FortiSandbox is a malware-detonation platform. FortiGate, FortiMail, FortiWeb, FortiClient and the rest of the fabric forward suspicious files and URLs to it, it detonates them in instrumented VMs, and it returns a verdict — clean, suspicious, malicious. Those verdicts are not advisory. Help Net Security describes it plainly: FortiSandbox is "a platform that other Fortinet security products depend on for threat verdicts to enforce blocking decisions and trigger automated responses." When the sandbox says clean, the mail gateway delivers the attachment. When it says malicious, the firewall drops the flow and the SOC gets a ticket.

That architecture is the reason this CVE matters more than its number suggests. Most edge appliances sit in front of the thing you care about. The sandbox sits inside the decision loop. Own it, and you are no longer bypassing the control — you are the control.

The two bugs: unauthenticated command injection

Both actively exploited flaws are the same weakness class — CWE-78, OS command injection — reachable with no credentials and no user interaction.

CVE	Type	Vector	CVSS (NVD)	Fixed in	Disclosed
CVE-2026-25089	OS command injection (web UI)	Unauth, crafted HTTP	9.8 (Fortinet rates 9.1)	4.4.9 / 5.0.6	9 Jun 2026
CVE-2026-39808	OS command injection	Unauth, crafted HTTP	9.8	4.4.9	14 Apr 2026
CVE-2026-39813	Path traversal in the JRPC API	Auth bypass	—	4.4.9 / 5.0.6	Jun 2026

CVE-2026-25089 lives in the web management UI (Fortinet advisory FG-IR-26-141, credited to Adham El Karn of Fortinet's own product security team). A specifically crafted HTTP request injects into an OS command the appliance runs on the attacker's behalf. There is no login step, no privileged prerequisite, no phishing. The third bug in the cluster, CVE-2026-39813, is a path traversal in the FortiSandbox JRPC API that lets an attacker bypass authentication outright — a natural pairing that lets an intruder reach management functions they were never meant to touch.

The affected ranges are wide: FortiSandbox 4.2.0–4.2.8, 4.4.0–4.4.8 and 5.0.0–5.0.5, plus the Cloud and PaaS builds on the 5.0.4–5.0.5 line. If you run FortiSandbox and have not touched it since spring, you are almost certainly on a vulnerable build.

Patched in April and June. Exploited in July

The timeline is the uncomfortable part. Fortinet fixed CVE-2026-39808 on 14 April and CVE-2026-25089 on 9 June. Weeks later, threat-intelligence firm Defused reported the flaws being abused in the wild around 16 June, and Qualys tracked the same activity the following day. On 16 July, CISA added both to the Known Exploited Vulnerabilities catalog and, under Binding Operational Directive 26-04, set a three-day federal remediation deadline of 19 July.

Read that gap again: a fix was available for three months on one bug and one month on the other, and the fleet still got hit. Security appliances are the worst-patched infrastructure most organisations run, for a predictable reason — they are trusted. Nobody schedules a maintenance window to reboot the thing that is supposed to be watching for trouble. It sits outside the server patch cadence, often under vendor or MSP management, often on a "don't touch it, it's working" exception. The result is a fleet of 9.8s exposed to the internet long after the patch existed.

The verdict oracle problem

Here is what RCE on the sandbox buys an attacker that RCE on a firewall does not.

First, verdict manipulation. If you control the process that decides clean vs malicious, you can make your own payload come back clean. The mail gateway that would have quarantined your loader now delivers it, because the oracle it trusts told it to. You have not evaded the detection layer — you have recruited it.

Second, the catalog. A detonation sandbox holds a running record of everything the fabric found suspicious: the samples, the URLs, the source mailboxes, the detonation reports. That is a map of what your defences catch and, by inference, what they miss. It tells an intruder which of their tools already burned and which are still viable.

Third, the pivot. The sandbox is wired into the fabric by design — it talks to FortiGate, FortiMail and the management plane. A box with that much east-west reach is an ideal staging point, and it is one defenders rarely watch as an origin of traffic because its whole job is to receive.

Counterfactual. Your SOC gets a FortiSandbox verdict: attachment X, clean. It is delivered. Three weeks later X is the initial access for a ransomware case. The post-incident question is not "why did the sandbox miss it" — the sandbox did not miss it. The sandbox was told what to say. On a compromised oracle, a clean verdict is not evidence of anything.

None of this requires a novel exploit. It requires an unauthenticated HTTP request to a box that has been sitting unpatched since spring.

Remediation

FortiSandbox is management infrastructure. Treat this as a Tier-0 incident, not a routine appliance update.

1. Am I affected? Check the running build from the CLI or the dashboard:

diagnose sys version
# or, in the GUI: System > FortiSandbox > Firmware

You are vulnerable if you run FortiSandbox 4.2.0–4.2.8, 4.4.0–4.4.8, or 5.0.0–5.0.5, or FortiSandbox Cloud/PaaS 5.0.4–5.0.5. Then check exposure — the management UI should never be internet-facing:

# from an external vantage point
curl -sk -o /dev/null -w "%{http_code}\n" https://<sandbox-mgmt-ip>/

2. Patch — exact fixed versions. Upgrade to FortiSandbox 4.4.9 or later, or 5.0.6 or later (Cloud and PaaS: 5.0.6+). 4.4.9 closes all three CVEs on the 4.4 branch; 5.0.6 closes them on the 5.0 branch. Builds on 4.2.x must move to a fixed branch. Cross-check against FG-IR-26-141 on the Fortinet PSIRT before you call it done.

3. Can't patch this hour? Compensating controls.

• Remove the management/web UI from any internet-facing interface immediately — restrict it to a management VLAN and a jump host. Unauthenticated, network-reachable is the entire precondition; cut the reachability and you cut the attack.
• Apply strict ACLs so only the fabric devices that must submit samples can reach the service ports.
• If you cannot isolate it fast, power-management is preferable to leaving a known-exploited 9.8 exposed.

4. Hunt for compromise. Patching does not evict an intruder who arrived before you patched. Map the hunt to MITRE ATT&CK:

• T1190 — Exploit Public-Facing Application: anomalous or malformed HTTP requests to the FortiSandbox web UI / JRPC API in appliance logs, especially with shell metacharacters in parameters.
• T1059 — Command and Scripting Interpreter: unexpected child processes spawned by the sandbox web service; commands the appliance has no business running.
• T1078 — Valid Accounts / auth bypass (CVE-2026-39813): administrative actions with no preceding successful login event.
• T1041 / T1071 — Exfiltration and C2: outbound connections originating from the sandbox management interface to never-seen destinations. This box ingests and pulls updates; it should not be beaconing.
• Verdict tampering: samples returned clean that other telemetry (EDR, mail logs) later contradicts — treat verdict/reality mismatches as a compromise signal, not a tuning problem.

5. Eradicate and verify. If you find any indicator, assume full appliance compromise. Command injection means arbitrary code ran as the service context. Rebuild the appliance from a known-good image rather than trusting an in-place upgrade, rotate every credential and API token the sandbox held or could reach across the fabric, review recent verdicts for anything an attacker may have flipped, and confirm the box is clean after patching — not before.

Where Zero Hunt fits

The recurring failure in this story is inventory-based assurance. "We patched FortiSandbox in April" is a statement about a change record, not about the box on the wire. The fleet that got hit almost certainly had the fix available — it just was not applied, and nobody was continuously checking the difference.

That gap is the reason Zero Hunt's AI generative pentest validates by evidence rather than by version banner. The 10-agent swarm — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report under an AI Controller — writes an exploitation attempt specific to your FortiSandbox with a local LLM, not a canned ExploitDB script, and runs it against the actual appliance inside an ephemeral gVisor-hardened container. The answer it returns is not "your CMDB says 4.4.9." It is "the crafted HTTP request either reached a shell on this box or it did not," backtested in the AI Gym before it ever touches production and ECDSA-signed as a finding you can hand an auditor. Its change-triggered campaigns are built for exactly the forgotten-appliance problem: a new or altered asset on the perimeter triggers a full campaign within the hour, so the sandbox nobody reboots does not quietly rot into a known-exploited 9.8.

And because an intruder who owns the oracle blinds the fabric's own telemetry, the AI Traffic Analysis engine watches the one surface the compromise cannot rewrite: the wire. Its deep-learning model runs four inference heads — suspicious traffic, malware classification, attack type, application fingerprint — at 2.7+ Gbit/s on the appliance GPU, locally, no cloud. It flags the crafted command-injection requests hitting the management UI and, more tellingly, the outbound sessions a detonation sandbox should never open — the beacon from the judge, while it is happening, not in tomorrow's SIEM digest. When the box that renders verdicts can no longer be trusted to report on itself, the network is the witness that still tells the truth.

For the broader argument that a validated finding beats an inventory estimate, see our note on exploit validation — evidence vs estimate.