SURIQ
The worst appliance to hand an attacker is the one whose entire job is to catch them. FortiSandbox detonates suspicious files in isolation so your team learns what a sample does before it lands on a production host. As of mid-June 2026, attackers are turning that same box into a foothold.
Threat intelligence firm Defused reported active exploitation of three critical FortiSandbox flaws within a single 24-hour window. Two of them need no credentials. One was patched only about a week before the attacks started. This is not a theoretical advisory waiting for a proof of concept. It is exploitation happening now against an appliance that, by design, sits in the path of your most sensitive file analysis.
What is actually being exploited?
Three vulnerabilities are in play. The most severe is CVE-2026-39808, alongside CVE-2026-25089 and the path-traversal bug CVE-2026-39813. Two of the three let an unauthenticated attacker reach FortiSandbox over the network and run commands. The third is the same class of bug on a wider set of FortiSandbox deployments. None of them require a user to click anything.
CVE-2026-39808 is the one to watch first. It is an OS command injection flaw in the FortiSandbox JRPC API, rated CVSS 9.8, and it gives an unauthenticated attacker code execution through a crafted HTTP request. CVE-2026-39813, rated 9.1, is a path traversal in the same JRPC API that lets an attacker bypass authentication. CVE-2026-25089 is another unauthenticated command injection, and it reaches FortiSandbox, FortiSandbox Cloud, and the FortiSandbox PaaS web interface.
Notice the pattern. Two of the three bugs live on the same internal API. That API was never meant to face anyone but the appliance itself, and yet a crafted request from the network walks straight onto it. When one management surface carries multiple unauthenticated bugs, the surface is the problem, not the individual CVE.
The patch window did not close. It collapsed.
Fortinet shipped fixes for CVE-2026-39808 and CVE-2026-39813 back in April 2026. CVE-2026-25089 was patched roughly a week before Defused saw it being exploited. Read that again: defenders had days, not weeks, between the fix landing and attackers using it.
That timing is the real story. Security teams plan appliance patching on a cadence built for a slower threat. A firewall or a sandbox gets folded into the next maintenance window because rebooting it is disruptive and the box is supposed to be one of the safe ones. Attackers know that, and they reverse engineer vendor patches to find what changed. A week-old fix is a roadmap, and exploitation arriving within a week of the patch means the maintenance-window model has stopped working for internet-reachable security gear.
We saw the same shape with Ivanti Sentry, where a patched appliance was still breached because the fix went out faster than most teams could apply it. Edge and security appliances now sit at the front of the exploitation queue, not the back.
Why losing a detonation sandbox is worse than losing a web server
A compromised web server is a bad day. A compromised malware sandbox is a blind SOC.
FortiSandbox exists to detonate the files your other controls are unsure about and tell you what they do. An attacker who owns that box does not just get another host on your network. They get to sit inside the one system that is supposed to recognize their own tooling. They can read the samples your team is analyzing, learn which of their payloads you have already caught, and potentially shape what the appliance reports back. The control you trusted to surface malware becomes the control that hides it.
There is a second problem. These appliances rarely run an endpoint agent. You cannot drop EDR on a FortiSandbox the way you would on a Linux server, so the usual on-host detection you depend on simply is not there. The sandbox is a black box that you trust because the vendor built it, which is exactly why a foothold there is so quiet.
What to do this week
Treat this as today's work, not this sprint's. The order that matters:
- Patch now, and verify the build. Check your installed FortiSandbox, FortiSandbox Cloud, and PaaS versions against Fortinet's April and June advisories, and confirm you are on a fixed release rather than assuming the last update covered it.
- Take the management plane off the public internet. The JRPC API and the web interface should be reachable only from an administrative network or through a VPN. If a FortiSandbox management surface answers from the open internet, that is the finding to fix before anything else.
- Watch the network, since you cannot watch the host. Alert on inbound connections to the FortiSandbox management API from anything outside your admin range, and on unexpected outbound traffic from the appliance itself. A detonation sandbox calling out to an address that is not a known update or telemetry endpoint is worth a page.
- Assume reachability is exposure. If your FortiSandbox has been internet-reachable on a vulnerable build, patching is not the end. Review its recent connections and treat it as a host that may already have been touched.
The lesson outlives this advisory. The appliances we install to watch for attackers are themselves software, and increasingly they are the software attackers reach first. A malware sandbox, an edge gateway, an identity broker: each one is a high-value target precisely because it is trusted and rarely inspected. Patch them like they are exposed, because they are, and put detection around them as if the vendor's assurance were the start of the conversation, not the end of it.