Attackers are targeting three critical Fortinet FortiSandbox vulnerabilities, turning a set of already-patched appliance bugs into an active exposure problem for security teams that use FortiSandbox to analyze suspicious files and URLs.
The activity centers on CVE-2026-39813, CVE-2026-39808, and CVE-2026-25089. Fortinet’s own advisories list all three as critical, unauthenticated flaws with CVSS 9.1 scores. Two were published in April, while the newest advisory arrived on June 9. Independent exploit-intelligence reporting this week says attackers have been probing all three in the wild, which means FortiSandbox owners should treat the fixes as urgent even though Fortinet’s advisory pages still list the bugs as not known exploited.
What is being targeted
FortiSandbox is a malware-analysis system used to detonate suspicious files, URLs, and other content before they reach users or production systems. That role makes it a valuable security-control plane: it often sits close to email, web, endpoint, and network-defense workflows, and it may process hostile samples by design. A remotely reachable FortiSandbox management or web interface is not just another appliance console; it can become a route into the systems built to inspect threats.
CVE-2026-39813 is a path-traversal flaw in the FortiSandbox JRPC API. Fortinet’s advisory says a specially crafted HTTP request can let an unauthenticated attacker bypass authentication. The affected releases are FortiSandbox 5.0.0 through 5.0.5 and FortiSandbox 4.4.0 through 4.4.8; the fixed versions are 5.0.6 and 4.4.9 or later.
CVE-2026-39808 is an unauthenticated OS command-injection flaw in a FortiSandbox API endpoint. Fortinet says it can allow unauthorized code or command execution through crafted HTTP requests. FortiSandbox 4.4.0 through 4.4.8 is affected, and administrators should move to 4.4.9 or later. FortiSandbox 5.0 is listed as not affected for this specific issue.
CVE-2026-25089 is the newer bug and affects the FortiSandbox web UI’s start-VNC feature. Fortinet describes it as a second-order OS command-injection issue that can let an unauthenticated attacker execute commands through crafted HTTP requests. FortiSandbox 5.0.0 through 5.0.5 and 4.4.0 through 4.4.8 need upgrades, as do FortiSandbox Cloud 5.0.4 through 5.0.5 and FortiSandbox PaaS 5.0.4 through 5.0.5. Fortinet lists 5.0.6 and 4.4.9 as the relevant fixed branches for affected deployments.
Why this is more than a routine patch
The strongest reason to move quickly is that exploitation attempts are no longer theoretical. The Hacker News reported that Defused Cyber observed exploitation of all three CVEs over a 24-hour period. SecurityWeek reported that Defused honeypots saw attempts against the same three vulnerabilities, and that KEVIntel independently observed CVE-2026-39808 exploitation on June 12 and activity targeting CVE-2026-39813 on June 15.
The nuance matters: Fortinet’s PSIRT pages still mark the issues as “Known Exploited: No,” while outside exploit-intelligence firms are reporting attempts against vulnerable systems. That gap can happen when vendor advisory fields lag threat activity, when activity is observed in honeypots rather than confirmed customer intrusions, or when a vendor has not finished validating outside claims. For defenders, the practical answer is the same: if a vulnerable FortiSandbox instance is reachable from untrusted networks, assume it is being scanned.
The reported activity also shows how fast exploitation follows patch publication. CVE-2026-39808 and CVE-2026-39813 were fixed in April, but scanning and exploit attempts are still useful to attackers because many appliances remain unpatched or exposed. CVE-2026-25089 was patched much more recently, in Fortinet’s June security updates, and researchers reported that one observed exploit appeared to have been generated with help from an AI model but did not work at the time it was seen. Security teams should not take a broken early exploit as reassurance; it usually means working attempts may follow.
What administrators should check now
- Inventory every FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS deployment, including lab, regional, and disaster-recovery systems that may not sit in the main asset list.
- Move affected FortiSandbox 5.0 deployments to 5.0.6 or later and affected 4.4 deployments to 4.4.9 or later. For CVE-2026-25089, also verify FortiSandbox Cloud and PaaS versions where applicable.
- Restrict management and web UI access to trusted administrative networks. A malware-analysis appliance should not expose its administrative surface broadly to the internet.
- Review web, API, reverse-proxy, VPN, and SIEM logs for suspicious requests to FortiSandbox interfaces around June 12 onward, especially if an appliance was still on an affected version.
- Treat unexplained configuration changes, new files, unexpected service behavior, or unusual outbound traffic from the appliance as possible compromise signals, not ordinary appliance noise.
- Rotate credentials and API secrets connected to FortiSandbox workflows if there is any sign the appliance was reached by exploit traffic before patching.
Qualys also published detection guidance for its customers, listing QIDs 733996, 734396, 733994, and 734082 for identifying vulnerable assets. Organizations using other exposure-management or vulnerability-scanning tools should check whether their vendor has coverage for all three CVEs rather than assuming a generic Fortinet check is enough.
The broader Fortinet risk
The FortiSandbox activity is landing at a difficult moment for Fortinet customers. Separate reporting this week described a large Fortinet credential-harvesting campaign involving FortiGate firewalls and VPN gateways. Fortinet told The Hacker News that the credential data appeared to come from previous incidents and brute-force activity rather than a new Fortinet breach or a current advisory. That distinction is important, but it does not make appliance exposure less urgent.
Network-security appliances are high-leverage targets because they often sit at trust boundaries and hold useful configuration, routing, VPN, inspection, or security-workflow context. Once attackers find a working exploit or a valid administrative credential, they may be able to pivot from the edge into internal systems, watch traffic, tamper with detection paths, or quietly collect secrets.
For FortiSandbox specifically, the immediate priority is straightforward: patch first, reduce exposure second, then investigate whether the appliance saw suspicious traffic while it was vulnerable. The uncomfortable part is that security teams cannot treat dedicated security products as outside the normal vulnerability-management queue. They are now among the first systems attackers check.
