Threat-intel vendor Defused and multiple security outlets confirmed in mid-June 2026 that attackers are actively exploiting three CVSS 9.1 flaws in FortiSandbox — CVE-2026-39813 (path traversal / auth bypass), CVE-2026-39808 (OS command injection), and CVE-2026-25089 (OS command injection, patched just last week). All three can be triggered without authentication via a single HTTP request. The most dangerous part: FortiSandbox isn't an edge device — it's the central brain other Fortinet products rely on to decide whether a file is good or bad. Once compromised, the verdict logic of your entire defense is in the attacker's hands.
The mechanism in plain words: CVE-2026-39813 is a ../filedir-style path traversal in FortiSandbox's JRPC API that lets an unauthenticated attacker bypass validation; then CVE-2026-39808/25089 are two OS command injections that let the attacker stuff commands into a crafted HTTP request, executed by the system at high privilege. Attack chain: unauthenticated → bypass validation → inject command → remote arbitrary code execution (root level). The whole chain is low-complexity, zero-interaction, no-auth. Notably, Defused observed that one public exploit for CVE-2026-25089 appears to be written using an AI model — and is buggy. That means attackers are also mass-producing exploits with AI; speed will only increase.
Affected scope: FortiSandbox 5.0.0–5.0.5, 4.4.0–4.4.8; CVE-2026-25089 also affects 4.2 all versions and the FortiSandbox Cloud / PaaS Web UI. Fortinet disclosed 39813 and 39808 back in April 2026, but active exploitation was confirmed in June — a textbook case of the "disclosure-to-weaponization" window compressing again.
Why is this worth acting on within 24 hours instead of the next patch window? Because it's no-auth, already exploited in the wild, and compromises the "referee" of your security architecture. Below: patch vs. mitigation table, IOCs, and what to do even if you don't use Fortinet.
Technical detail: vuln type + attack path
The three flaws fall into two classic weaknesses: path traversal (CWE-22) and OS command injection (CWE-78). The attacker needs no credentials — just reachability to FortiSandbox's management interface — to send commands via a crafted request. For PHP/Nginx backend engineers, it's a textbook reminder: any place you splice user input into a file path or system command is the same kind of hole. Here's the same class of mistake in PHP, dangerous vs. correct:
// ❌ Dangerous: user input spliced straight into a path (traversal)
$file = '/var/data/' . $_GET['name'];
readfile($file); // ?name=../../etc/passwd
// ✅ Correct: basename + allowlist + realpath boundary check
$base = '/var/data/';
$path = realpath($base . basename($_GET['name']));
if ($path === false || !str_starts_with($path, $base)) {
http_response_code(400); exit;
}
readfile($path);
// ❌ Dangerous: user input spliced into a system command (injection)
exec("convert {$_GET['f']} out.png");
// ✅ Correct: escapeshellarg, or use a native library
exec('convert ' . escapeshellarg($input) . ' out.png');
Immediate actions for three readers
- Sysadmins: upgrade FortiSandbox immediately to the version specified in Fortinet's advisory (off 5.0.5-and-below, 4.4.8-and-below, all of 4.2); before upgrading, take the FortiSandbox management/JRPC interface off the public internet, allow only LAN or VPN sources, and block external access to its management ports at the firewall.
- Developers: inventory every "user input → file path" and "user input → system command" spot in your own systems, apply
basename+realpathboundary checks andescapeshellarg; at the Nginx layer add alocationrule to block requests containing../. - Agencies / consultants: send a client advisory today — three yes/no questions: "Do you use FortiSandbox? Which version? Is it exposed to the internet?" with an upgrade link. The email itself demonstrates a care service.
Patch vs. mitigation table
| Scenario | Immediate patch | Mitigation if you can't patch now |
|---|---|---|
| FortiSandbox exposed to internet | Upgrade to advisory version | Take management/JRPC interface offline, restrict to LAN/VPN |
| Internal but broadly reachable | Upgrade | Firewall ACL allowing only a bastion host IP |
| Cloud / PaaS deployment | Confirm provider patched | Enable source-IP allowlist, review access logs |
| Can't take downtime | Schedule emergency maintenance window | WAF/IDS block requests with ../ and suspicious command chars |
IOCs and threat intel
- Watch for anomalous HTTP requests to the FortiSandbox JRPC API (management port) containing
../orfiledirstrings. - Monitor whether the FortiSandbox host suddenly connects out to unknown C2 IPs, or spawns unexpected shell child processes (
sh -c,curl,wgetin the process tree). - Cross-check affected versions and patch numbers against Fortinet's official PSIRT advisory (FG-IR).
- Check management-interface access logs for unauthenticated requests from unexpected countries/IPs.
What they won't tell you
First, the vendor advisory's focus is "upgrade," but many orgs' FortiSandbox is auto-relied-upon by other Fortinet products; a hasty upgrade can disrupt the whole linked verdict flow — verify version compatibility first, or you'll patch one hole and break the whole defense. Second, "one exploit appears AI-generated and buggy" sounds like good news (unstable attacks), but conversely, attackers fixing that bug is only a matter of time; AI is compressing exploit development from weeks to days — your patch window is shorter than it looks.
The bigger trend this represents
Security appliances themselves are becoming the top targets: VPN gateways, firewalls, sandboxes — these "gatekeepers," with high privilege, frequent edge exposure, and hard-to-take-down updates, are the sweetest targets. When "disclosure → weaponization" gets compressed to days by AI, the traditional "monthly patch window" cadence can't keep up; enterprises need a "24-hour response window" and a mindset that "security appliances must also be in zero trust."
FAQ
We don't use FortiSandbox — is this relevant to me?
Yes. One, the technique (unauthenticated path traversal + command injection) is universal; any "user input spliced into a path/command" in your own system is the same class of hole. Two, it reminds everyone to take "security devices and admin interfaces" off the public internet — the same principle applies to your phpMyAdmin, admin panels, and CI interfaces.
Will upgrading FortiSandbox affect linkage with other Fortinet gear?
Possibly. FortiSandbox provides threat verdicts to other products; check Fortinet's compatibility matrix before upgrading and do it within a maintenance window. If you can't upgrade immediately, prioritize network-layer isolation (take the management interface offline) as mitigation.
The exploit is "AI-written and buggy" — does that mean low risk?
Don't read it that way. Buggy only means "this version of the attack is currently unstable"; attackers iterate fixes with AI extremely fast. Treat it as a warning that "you have very little time," not a reason to take it slow.
What's the single most important action?
Take FortiSandbox's management/JRPC interface off the public internet, allowing only VPN or LAN bastion access. Even before you schedule the upgrade, this drastically shrinks the "no-auth, single-request" attack surface.
My take
The mainstream says "just patch fast." My judgment: the patch is only the last step; the real disease is "security devices on the public internet, updated on a monthly cadence." When exploits can be mass-produced with AI in days, the "Patch Tuesday mental model" is dead; what survives is the org with "asset inventory + 24-hour response + admin interfaces private by default." Care opportunity for ScriptWalker: turn "exposure audit of edge devices and admin interfaces" into a quarterly fixed service — from a Shodan/Censys viewpoint, help clients see which admin interfaces (FortiSandbox, phpMyAdmin, admin panels, CI) are exposed to the internet, list them, and close them. For SMBs with no dedicated security staff, it's a high-value, standardizable, recurring-revenue care item.
Sources
- Help Net Security — Attackers are exploiting FortiSandbox vulnerabilities (first-party reporting)
- BleepingComputer — Critical Fortinet FortiSandbox flaws now exploited in attacks (first-party reporting)
- NVD — CVE-2026-39813 (first-party)
- Fortinet PSIRT Advisories (first-party vendor advisory)
- The Hacker News — Attackers Exploit Three Fortinet FortiSandbox Flaws (third-party)
- SecurityWeek — 3 Recently Patched Fortinet FortiSandbox Vulnerabilities in Hacker Crosshairs (third-party)