If your organization runs Fortinet FortiSandbox, here is the short version: three critical, unauthenticated vulnerabilities in the product are being actively exploited right now, and one of them has no public fix timeline gap left to hide behind, since patches for all three have been available since June 9, 2026.
Here's why this matters even if you've never logged into FortiSandbox yourself. It's not a website or an email server; it's the system that other Fortinet products, firewalls, email gateways, endpoint agents, lean on to decide whether a file is safe. When a security tool can't tell on its own whether something is malicious, it hands that file to FortiSandbox, which detonates it in an isolated environment and reports back a verdict: clean, or malicious. Every other tool downstream trusts that verdict and acts on it automatically.
That's what makes this set of vulnerabilities different from a typical "patch this server" advisory. An attacker who compromises FortiSandbox doesn't just gain a foothold on one machine; they gain control over the judgment that an entire security stack relies on. A compromised sandbox can be made to clear malicious files as safe, effectively blinding everything connected to it. For executives, the operative question isn't "is this server important," it's "do we trust the verdicts our security tools have been acting on."
What's happening
Three separate vulnerabilities in Fortinet's FortiSandbox platform, all rated critical with CVSS scores in the 9.1 to 9.8 range depending on the scoring source, are under active exploitation according to multiple independent threat intelligence sources. Two of the three (CVE-2026-39808 and CVE-2026-39813) were disclosed and patched back in April 2026. The third (CVE-2026-25089) was disclosed and patched far more recently, on June 9, 2026. All three require no authentication and no user interaction to exploit.
Threat intelligence firm Defused was the first to report active exploitation, warning on June 15 that it had observed exploitation attempts against all three vulnerabilities within a 24-hour window. KEVIntel independently confirmed exploitation of CVE-2026-39808 on June 12. Notably, the exploit Defused observed for CVE-2026-25089 appears to be AI-generated and faulty; it didn't work correctly when first observed, even though it represents real attempted exploitation. Researchers have not yet seen a fully functional public exploit for that particular CVE, which is some reassurance, though not much, given that the other two vulnerabilities do have working exploits in circulation.
Fortinet has not, as of this writing, publicly confirmed that exploitation is occurring; the reporting comes from independent threat intelligence researchers monitoring honeypot infrastructure designed to look like real FortiSandbox deployments.
What is FortiSandbox?
FortiSandbox is Fortinet's threat detection and analysis platform. When a connected Fortinet product, a FortiGate firewall, FortiMail, FortiClient, encounters a file or URL it cannot classify as safe or malicious on its own, it forwards that object to FortiSandbox. FortiSandbox detonates the file in an isolated virtual environment, observes its behavior, and returns a verdict that the originating product then acts on: block, or allow.
This puts FortiSandbox in an unusually sensitive architectural position. It isn't customer-facing, and it doesn't typically sit on the edge of the network the way a firewall does. But the products that do sit on that edge depend on it to make correct decisions, and none of them have an independent way to verify that a FortiSandbox verdict hasn't been tampered with.
The three vulnerabilities
CVE-2026-39813: Path traversal in the JRPC API
This is a path traversal vulnerability (CWE-24) in FortiSandbox's JRPC API, tracked under Fortinet advisory FG-IR-26-112. It allows an unauthenticated attacker to bypass authentication entirely using specially crafted HTTP requests. Independent researchers have demonstrated that injecting traversal sequences into the API's session parameter can expose sensitive system data, including configuration backups, serial numbers, and version information, without any credentials at all.
Fortinet credits its own PSIRT analyst, Loic Pantano, with discovering this flaw internally. It carries a CVSS v3.1 score of 9.1 according to Fortinet's own advisory.
CVE-2026-39808: OS command injection
This is an OS command injection vulnerability (CWE-78), tracked under FG-IR-26-100. It allows an unauthenticated attacker to execute arbitrary commands via crafted HTTP requests, reportedly by weaponizing the jid GET parameter through pipe-chained Unix commands. A public proof-of-concept for this flaw has circulated since April 2026, and the exploitation activity researchers are now seeing is consistent with that published PoC. This is the vulnerability with the most mature, reliable exploit code of the three.
This one also carries a CVSS v3.1 score of 9.1 in Fortinet's advisory; some independent scanning vendors calculate a 9.8 using a slightly different vector, but the practical severity assessment is the same either way: critical, remotely exploitable, no authentication required.
CVE-2026-25089: OS command injection in the Web UI
This is the most recently disclosed of the three, published by Fortinet on June 9, 2026 under FG-IR-26-141. It's also an OS command injection flaw (CWE-78), this time in the FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS web user interface, specifically tied to the "start VNC" feature. Fortinet credits internal researcher Adham El Karn with the discovery. It also carries a CVSS v3.1 score of 9.1.
Unlike the other two, no working public exploit for this flaw has been confirmed as of this writing. The exploitation activity Defused observed against it appears to come from an AI-generated exploit attempt that didn't function correctly. That's a useful detail operationally, since it suggests attackers are scanning and probing faster than they're successfully weaponizing this particular flaw, but it is not a reason to delay patching. Faulty exploits get fixed.
Who is affected
| CVE | Component | Affected Versions | Fixed In |
|---|---|---|---|
| CVE-2026-39813 | JRPC API | FortiSandbox 4.4.0–4.4.8; 5.0.0–5.0.5 | 4.4.9+ / 5.0.6+ |
| CVE-2026-39808 | API (jid parameter) | FortiSandbox 4.4.0–4.4.8 | 4.4.9+ |
| CVE-2026-25089 | Web UI (start VNC) | FortiSandbox 4.4.0–4.4.8; 5.0.0–5.0.5; FortiSandbox Cloud 5.0.4–5.0.5; FortiSandbox PaaS 5.0.4–5.0.5 | 4.4.9+ / 5.0.6+ |
FortiSandbox 5.2 and FortiSandbox 4.2 are not affected by CVE-2026-39813 or CVE-2026-25089 according to Fortinet's advisories. If you're running a 4.4 or 5.0 branch deployment, you are in the affected range for at least one, and likely all three, of these flaws.
Why exploitation moved quickly
A few factors explain why attackers moved on these vulnerabilities as fast as they did.
No authentication barrier, anywhere. All three vulnerabilities require nothing more than the ability to send an HTTP request to the appliance. There's no credential to guess, no session to hijack, no user interaction to wait for. That's the lowest possible bar for exploitation, and it's the same combination of factors that made the NGINX, Apache, and Linux kernel vulnerabilities we've covered recently so attractive to opportunistic scanning.
A two-month gap between patch and active exploitation for the older flaws. CVE-2026-39808 and CVE-2026-39813 were patched in April. Organizations had roughly two months to apply that fix before exploitation attempts began in mid-June. That gap matters: it's a reminder that "we patched eventually" isn't the same as "we patched before it mattered," and that Fortinet products specifically tend to draw sustained attacker interest well past initial disclosure.
A six-day gap for the newest flaw. CVE-2026-25089 was disclosed on June 9. Exploitation attempts, however faulty, were observed within roughly a week. Whether or not the AI-generated exploit for this particular CVE matures into something reliable, the pattern itself, attackers attempting exploitation within days of disclosure rather than weeks, is the trend to plan around, not the exception.
AI-assisted exploit development is showing up in real attack telemetry. The fact that researchers can identify an exploit attempt as "vibecoded" is itself notable. It means the barrier to producing a working exploit attempt, even a flawed one, against a freshly disclosed vulnerability has dropped enough that opportunistic actors without deep technical skill are now in the mix alongside more capable adversaries. A faulty exploit today does not mean a faulty exploit next week.
What should you do?
1. Determine your version
Check your FortiSandbox version and compare it against the affected ranges above. If you are running anything in the 4.4.0–4.4.8 or 5.0.0–5.0.5 ranges, you need to act now.
2. Patch immediately
Upgrade to FortiSandbox 4.4.9 or above, or 5.0.6 or above, depending on your branch. These are the versions that resolve all three CVEs. Consult Fortinet's advisories directly for the full version matrix across FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS:
- FG-IR-26-100 (CVE-2026-39808)
- FG-IR-26-112 (CVE-2026-39813)
- FG-IR-26-141 (CVE-2026-25089)
3. Restrict network access to the management interface
If you cannot patch immediately, restrict access to the FortiSandbox management interface and API endpoints to trusted internal networks only. None of these vulnerabilities should be reachable from the public internet in a properly segmented deployment; if your FortiSandbox management interface is internet-facing today, treat that as an urgent finding on its own, independent of these specific CVEs.
4. Review logs for signs of exploitation
Look for unusual process spawning from FortiSandbox services, particularly shell processes such as /bin/sh or /bin/bash; unexpected outbound network connections originating from the appliance; command chaining operators or shell metacharacters appearing in request parameters in your web server or API logs; and unauthorized files in temporary directories. If your organization has SIEM coverage over FortiSandbox logs, prioritize review of activity since June 9, when the most recent of the three vulnerabilities was disclosed.
5. Don't treat a verdict as trustworthy until you've confirmed the appliance is patched
This is the detail that's easy to miss. If there's any possibility your FortiSandbox instance was exploited before you patched it, treat the verdicts it produced during that exposure window with suspicion. A compromised sandbox can return false "clean" results to every connected product. Re-scanning recently cleared files with a separate, trusted tool is a reasonable precaution if you have reason to believe your instance was targeted.
The broader pattern
This is not the first time Fortinet appliances have drawn fast, sustained attacker attention this year. In April, Fortinet pushed emergency out-of-band patches for a critical FortiClient EMS vulnerability (CVE-2026-35616) that was already being exploited at disclosure. Separately, security firm SOCRadar recently reported a large-scale credential harvesting campaign, dubbed FortiBleed, that has compromised more than 30,000 Fortinet firewalls and VPN gateways across more than 190 countries by systematically testing known passwords against internet-facing devices. CISA's Known Exploited Vulnerabilities catalog tracks 26 Fortinet vulnerabilities exploited in attacks in recent years, 13 of which have been abused specifically by ransomware operators.
None of that history is a reason to panic about these three specific CVEs in isolation. It is a reason to treat Fortinet infrastructure as a standing priority for patch cadence and exposure review rather than a "patch when convenient" category, since the pattern of attacker interest is well established and unlikely to change.
Summary
| CVEs | CVE-2026-39808, CVE-2026-39813, CVE-2026-25089 |
| Product | Fortinet FortiSandbox, FortiSandbox Cloud, FortiSandbox PaaS |
| CVSS Score | 9.1 (Critical, Fortinet v3.1) / up to 9.8 depending on scoring source |
| Type | OS command injection (x2), path traversal / authentication bypass (x1) |
| Attack vector | Network, unauthenticated, no user interaction required |
| Disclosed | CVE-2026-39808 and CVE-2026-39813: April 14, 2026; CVE-2026-25089: June 9, 2026 |
| Active exploitation confirmed? | Yes, reported by Defused and KEVIntel beginning June 12–15, 2026 |
| Public PoC available? | Yes, for CVE-2026-39808; not confirmed for the other two |
| Affected versions | FortiSandbox 4.4.0–4.4.8; 5.0.0–5.0.5 (varies slightly by CVE; see table above) |
| Fixed in | FortiSandbox 4.4.9+ or 5.0.6+ |
| Immediate mitigation | Restrict FortiSandbox management interface and API to trusted networks |
| Full fix | Upgrade to FortiSandbox 4.4.9 or 5.0.6, depending on branch |
If you need help determining whether your FortiSandbox deployments are affected, assessing whether verdicts produced during a possible exposure window can still be trusted, or reviewing your broader Fortinet patch posture given the sustained attacker interest in the platform, get in touch. A security tool that other security tools depend on is exactly the kind of single point of failure that deserves a second look.