CRITICAL: Three FortiSandbox Flaws Under Active Exploitation as Defenders Race to Patch

If you needed proof that patch windows are getting shorter and attackers are reading vendor advisories faster than your change control meeting can convene, look no further than what just happened to Fortinet's sandbox appliance. Defused Cyber reported active exploitation of three FortiSandbox vulnerabilities inside a 24-hour window, and one of the three only got a patch last week. The other two have been available since April. Apparently that was plenty of time for someone to weaponize them and start scanning the internet.

The three flaws all carry a CVSS score of 9.1, which puts them firmly in the drop everything and patch this now tier. CVE-2026-39813 is a path traversal vulnerability in the FortiSandbox JRPC API that lets an unauthenticated attacker bypass authentication by sending specially crafted HTTP requests. CVE-2026-39808 is an operating system command injection bug that allows unauthenticated code execution through equally crafted HTTP requests. Both of these were addressed in Fortinet's April 16, 2026 security advisory after researchers Loic Pantano of the Fortinet PSIRT and Samuel de Lucas Maroto of KPMG Spain reported them. CVE-2026-25089 rounds out the trio. This one is another command injection flaw, but in the web UI rather than the API, and Fortinet only published the fix on June 9. That gave defenders roughly a week of grace period before attackers started knocking.

To understand why this matters more than the average critical CVE, you need to know what FortiSandbox actually does on an enterprise network. It is the box that other Fortinet gear trusts when it needs a second opinion. When FortiGate, FortiMail, or FortiWeb see a suspicious file or URL, they hand it off to FortiSandbox to detonate the sample in an isolated environment and return a verdict. That verdict drives blocking decisions and triggers alerts elsewhere in the stack. If an attacker controls the sandbox, they control the truth. Suddenly the malware everyone thought was being neutered in a safe environment can be marked clean and waved through to whoever the attacker actually wants to compromise. It also means the appliance itself becomes a privileged foothold deep inside the perimeter, well past the public facing gateways. From there, lateral movement is the natural next step.

The affected versions read like a complete enumeration of recent FortiSandbox releases. CVE-2026-39813 hits versions 5.0.0 through 5.0.5 and 4.4.0 through 4.4.8, with fixes landing in 5.0.6 and 4.4.9. CVE-2026-39808 hits versions 4.4.0 through 4.4.8, also fixed in 4.4.9. CVE-2026-25089 has the broadest blast radius of the three. It covers 5.0.0 through 5.0.5, 4.4.0 through 4.4.8, every version on the 4.2 branch, FortiSandbox Cloud 5.0.4 through 5.0.5, and FortiSandbox PaaS 5.0.4 through 5.0.5. The 4.2 branch is particularly painful because Fortinet's guidance recommends migrating to a supported release rather than patching, which means anyone who has been kicking that upgrade down the road is now in a real corner.

The exploitation pattern Defused Cyber observed is exactly what you would expect from a competent operator. Once the April advisories went public, the patch diffs themselves became a treasure map. Path traversal and command injection bugs in a network appliance are reliable, easy to weaponize, and rarely require much by way of exploit engineering. They also do not need credentials, which is the worst combination for a defender. The fact that all three were being exploited within twenty four hours of being grouped together suggests the actors involved had already developed working exploits for the April flaws and were simply waiting to bundle them with the June one for a full attack chain. That is not the kind of activity associated with random commodity botnets. That is targeted opportunism.

What you do about this depends on how exposed your appliance is. The first action is the obvious one. If you are running FortiSandbox 5.x, get to 5.0.6 or later. If you are on the 4.4 branch, get to 4.4.9. If you are still on 4.2, you need to plan a real migration, because that train has left the station. FortiSandbox Cloud and PaaS customers should verify with Fortinet that their tenancy has been rolled to the patched build, which is a question worth raising in writing rather than assuming. Beyond patching, the JRPC API and the management web UI should never be exposed to the internet under any circumstance, and if they currently are, that is your second emergency action item. Restrict access to a management network or a VPN, and audit your firewall rules in front of the appliance to confirm what you actually intended.

For detection, the unfortunate reality is that there are no widely published indicators of compromise tied to these exploitation campaigns yet, which means you are looking for the after effects rather than the initial intrusion. Pay close attention to outbound connections from the sandbox itself to unexpected destinations, particularly any traffic that looks like a reverse shell, a Cobalt Strike beacon, or a DNS tunnel. Anything that looks like the appliance is running commands a sandbox has no reason to run is worth chasing. Compare your appliance's verdicts on known bad samples against an independent source. If FortiSandbox is suddenly saying things are clean that other tools call malicious, somebody may have tipped the scales. Snapshots of the appliance's file system before and after suspicious activity can also help confirm whether the path traversal flaw was used to drop or modify files outside the intended sandbox paths. Forensic teams should preserve memory and logs before reinstalling, because a fresh image will erase whatever evidence of the intrusion still lives on the box.

There is an MSP angle here that is worth raising with clients before the news cycle moves on. Any business that has built a security stack around the Fortinet ecosystem has an attack surface that goes far beyond the perimeter firewall. The sandbox is exactly the kind of forgotten appliance that gets stood up during a project, signed off as working, and then never touched until something breaks. Use this as the conversation starter for a managed appliance patching service, or a quarterly Fortinet posture review, or simply a one time audit engagement to verify every Fortinet box is on a supported branch and that none of the management interfaces are exposed in ways nobody remembers approving. The price of that work pays for itself the first time a sandbox compromise gets caught at the proposal stage rather than during an incident response retainer call at three in the morning.

The deeper lesson from this incident is one that defenders have been internalizing for a while now but executives still tend to underestimate. Patch advisories are not a starting line. They are a starting gun. The window between disclosure and weaponization has shrunk to days for serious flaws in network appliances, and in this case the window has effectively collapsed for the older bugs because attackers waited for the trio to align before kicking off their campaign. Treat any unauthenticated, internet reachable code execution flaw in a perimeter or near perimeter device as already exploited and work backwards from there. Your incident response plan, your patch schedule, and your detection coverage all need to assume the worst at the moment the CVE drops, not the moment your scanner catches up two weeks later.