When the Sandbox That Judges Your Files Gets Taken Over: CVE-2026-39808 and CVE-2026-25089

CISA added two Fortinet FortiSandbox command injection flaws to its Known Exploited Vulnerabilities catalog on July 16, 2026. Both let an unauthenticated attacker run commands as root on the very appliance a network trusts to decide which files are safe. The flaws were disclosed and patched between April and June; public proof-of-concept code and scanner templates followed, and exploitation has been observed in the wild since mid-June 2026. Here is how the flaws work, why a security appliance is a high-value target rather than a safe internal host, and what to do about it.

What the vulnerabilities are

FortiSandbox is Fortinet's advanced threat-analysis appliance. Its job is to take suspicious files, URLs, and network flows, run them in an isolated environment, and return a verdict of malicious or benign before that content is allowed near production systems. In a Fortinet Security Fabric deployment it becomes the arbiter of trust: FortiGate firewalls and FortiMail gateways query the sandbox for a verdict and act on the answer in real time. That gives the appliance an unusual amount of authority inside a network, and it is exactly that authority that makes a compromise so damaging.

CVE-2026-39808 is an OS command injection flaw in the FortiSandbox API, classified as CWE-78. An unauthenticated attacker sends a crafted HTTP request and executes arbitrary system commands on the appliance, with no user interaction required. Public analysis places the flaw in a job-detail API endpoint where an attacker-controlled parameter is passed to an underlying operating system process without proper sanitization, so shell metacharacters in that parameter become commands the appliance runs on the attacker's behalf. It affects FortiSandbox versions 4.4.0 through 4.4.8 and was patched by Fortinet in advisory FG-IR-26-100.

CVE-2026-25089 is a second OS command injection flaw, this one in the FortiSandbox Web UI, and it reaches further: it affects FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS across on-premises, cloud, and platform-as-a-service deployments, versions 4.4.0 through 4.4.8 and 5.0.0 through 5.0.5. It follows the same unauthenticated remote code execution pattern and was patched only on June 9, 2026 in advisory FG-IR-26-141, leaving defenders a very short runway before exploitation was observed. Notably, threat intelligence analysis reported that the exploit code for CVE-2026-25089 showed signs of having been written with the help of an AI model, though the same reporting noted the code contained implementation errors.

A third flaw from the same wave, CVE-2026-39813, is a path traversal and authentication bypass in the FortiSandbox JRPC API (FG-IR-26-112). It was not part of the July 16 KEV batch, which paired the two FortiSandbox command injection bugs with an unrelated Microsoft SharePoint flaw, but it matters here because an attacker can chain its authentication bypass with either command injection bug to reach root more reliably. We mention it for completeness; the two KEV additions are the reason this post exists.

How the exploit works

All of these flaws share a blunt, low-effort attack profile: no authentication, no user interaction, and low attack complexity. For CVE-2026-39808 in particular, public write-ups describe the whole thing collapsing into a single crafted HTTP request. The attacker injects shell metacharacters into a parameter the appliance hands to an operating system command, the appliance runs the injected command as root, and the output can be redirected to a file inside the web root that the attacker then simply retrieves with a browser. There is no memory-corruption gymnastics, no exploit chain to tune. It is command injection in its most direct form, which is why a public proof of concept and off-the-shelf scanner templates appeared within weeks of disclosure and mass scanning followed quickly.

The security feature becomes the pivot. The box you bought to judge whether files are dangerous is now the one running the attacker's commands, as root, and every downstream control still trusts its verdicts.

The reach is wider than it first appears. Many teams assume the sandbox is tucked safely away from the internet, and some genuinely segment it. But FortiSandbox routinely accepts connections from internal segments, mail infrastructure, and remote FortiGate peers, so an attacker with any initial foothold inside the network, or a peered cloud workload, can often reach the appliance and pivot straight to it. The Cloud Security Alliance, writing about this exact campaign, put the compound risk plainly: a compromised sandbox effectively subverts the judgments every downstream control relies on. An attacker who can quietly flip verdicts can wave malicious files past the firewalls and mail gateways that are waiting on the sandbox to tell them what is safe, without tripping the obvious alarms.

Why this hits OT and critical infrastructure

We want to be careful and honest about the operational-technology angle here, because FortiSandbox is not itself a PLC, an RTU, or a building controller. It is a security appliance. The reason it belongs on an OT and critical-infrastructure watch is placement and trust, not the device category. Fortinet appliances are among the most common network and edge devices bridging into industrial and critical-infrastructure environments, and a sandbox that sits at the verdict layer of that fabric is guarding, and connected to, the segments that protect OT. When the trust authority for a Security Fabric is compromised, every control downstream of it, including the ones separating enterprise IT from plant and utility networks, is operating on judgments an attacker can influence.

This also fits a pattern defenders have been living with for several years. Coalition's 2025 Cyber Threat Index attributed a majority of ransomware claims to threat actors compromising perimeter security appliances such as VPNs and firewalls, and CISA's own directives have singled out network security appliances as the preferred initial-access vector for both nation-state and ransomware actors. A FortiSandbox with unauthenticated root exposure is precisely the kind of appliance that has been turning into an entry point rather than a safeguard. The KEV entry lists ransomware association as unknown, and we will not overstate it, but the category history is not reassuring.

What we see from our sensors

We run a fleet of honeypots and edge decoys, so we checked our own data, and we want to be precise about what we can and cannot claim.

We did not capture exploitation of these specific FortiSandbox CVEs. We do not currently stand up a FortiSandbox-flavored decoy that exposes the vulnerable API or Web UI endpoints, so an attacker aiming a FortiSandbox exploit would not find a matching surface on our sensors, and we are not going to pretend otherwise.

What we do see, constantly, is the reconnaissance that precedes appliance exploitation: internet-wide scanning for Fortinet management interfaces and login surfaces, opportunistic probing of edge and security appliances, and follow-on attempts against freshly disclosed CVEs within days of a patch landing. Fortinet's own product line has drawn sustained attention from scanners on our decoys, and the pattern with these boxes is reliable: a critical, unauthenticated appliance bug with a public proof of concept gets folded into mass scanning quickly. A FortiSandbox-flavored decoy that speaks enough of the API and Web UI to log connection and injection attempts would convert that inference into captured sessions, and it is now on our short list.

What to do

• Patch now, and treat it as an emergency. Upgrade affected FortiSandbox deployments to 4.4.9 or 5.0.6. These releases close all three related CVEs across both the 4.4.x and 5.0.x branches. Short of taking the appliance offline, patching is the only durable fix.
• Confirm cloud and PaaS coverage. For FortiSandbox Cloud and PaaS, verify with the provider that the June 9 patch for FG-IR-26-141 (CVE-2026-25089) has been applied, since the cloud variants are in scope for that flaw.
• Get the management interface and API off the internet. Audit firewall rules and segmentation to confirm the FortiSandbox JRPC API port and Web UI are not exposed to untrusted segments or the open internet. Where exposure exists, restrict access to known administrative source addresses immediately as a stopgap.
• Treat a potentially exposed appliance as suspect. If the box was reachable during the exploitation window, assume it may be compromised. Review stored analysis logs and system state, and run verdict-integrity checks to catch signs that analysis results were manipulated.
• Watch the appliance like an endpoint. Tune SIEM and network monitoring to flag anomalous command execution or unexpected outbound connections originating from the FortiSandbox itself. A security appliance reaching out to somewhere new is a signal, not noise.
• Reclassify security appliances as top-tier patch targets. The gap between the April and June patches and mid-June exploitation shows that some environments did not escalate these advisories. Put sandboxes, scanners, and SIEM collectors in the same highest-priority patch tier as internet-facing servers.

Indicators and references