The Security Appliance Becomes the Target
There is a grim irony in the latest Fortinet disclosures. FortiSandbox is a malware-analysis appliance, a piece of defensive infrastructure that organizations deploy specifically to detonate and inspect suspicious files in isolation. On June 16, threat-intelligence firm Defused reported that attackers had begun exploiting three critical FortiSandbox vulnerabilities within the previous 24 hours. The tool meant to catch threats has itself become the entry point.
We keep returning to this theme because it keeps recurring: the security stack is now one of the most attractive targets in the enterprise. Appliances like FortiSandbox are deeply trusted, broadly connected, and frequently exposed to inspect inbound content. That combination of privilege and exposure is exactly what an attacker wants. Compromising the analysis appliance does not just breach a host; it potentially blinds the defender and provides a foothold with elevated trust inside the network.
Three Flaws, One Severity Rating
The technical specifics are unforgiving. CVE-2026-39813 is a path-traversal and authentication-bypass bug in the FortiSandbox JRPC API. CVE-2026-39808 is an OS command injection flaw enabling unauthenticated remote code execution. CVE-2026-25089 is a separate OS command injection vulnerability in the FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS web interface. Each one carries a CVSS score of 9.1, and each allows an unauthenticated attacker to execute commands via specially crafted HTTP requests.
What unsettles us is the breadth. This is not a single bug an organization can quickly triage and contain. It is three independent critical flaws in the same product family, any of which could yield unauthenticated code execution. For defenders, that means a layered patching effort rather than a one-line fix, and it means assuming that an exposed appliance which has not been updated should be treated as potentially already compromised rather than merely vulnerable.
Patched Does Not Mean Protected
The timeline punctures a comfortable assumption. Fortinet patched CVE-2026-39813 and CVE-2026-39808 in April, and shipped the fix for CVE-2026-25089 only the prior week. In other words, fixes existed, yet exploitation is happening now. The gap between a patch being published and a patch being applied is where these campaigns live, and that gap remains stubbornly wide across the industry.
Defused noted that CVE-2026-39813 had "no previous recorded exploitation," signaling fresh attacker interest in a flaw that had been quietly sitting unexploited since its disclosure. That pattern is instructive. Attackers routinely revisit older advisories, reverse-engineer the patch to understand the vulnerability, and build working exploits weeks or months later, betting that a meaningful share of deployments will still be unpatched. The existence of a fix is the starting gun for exploitation, not the finish line.
Public Exploits Raise the Stakes
The risk is not uniform across the three flaws, and the differences matter for prioritization. A public proof-of-concept is already available for CVE-2026-39808, which sharply increases the practical danger because it lowers the skill required to weaponize the bug. Once working exploit code circulates, the population of potential attackers expands from sophisticated actors to anyone who can run a script.
By contrast, the exploit circulating for CVE-2026-25089 appears to be AI-generated and currently faulty, with no reliable working public exploit yet observed. That nuance is worth dwelling on. We are entering a period where attackers use AI to draft exploit code quickly, producing a flood of attempts of varying quality. Some will fail, as this one apparently does for now, but the volume and speed of generation mean defenders cannot count on attacker error. A faulty exploit today is often a working one tomorrow.
What Defenders Should Do Now
Fortinet's guidance is blunt: upgrade affected deployments to the latest released versions immediately. We would add that organizations should treat any internet-facing FortiSandbox instance that has lagged on patches as a priority for investigation, not just remediation. Given that exploitation is active and at least one reliable public exploit exists, the prudent posture is to assume exposure until logs and integrity checks prove otherwise.
Beyond patching, this is a moment to revisit the exposure of security appliances generally. Management interfaces and analysis APIs should not be reachable from the open internet without strong justification and compensating controls. The FortiSandbox episode is a reminder that the devices defenders rely on most are subject to the same vulnerability lifecycle as everything else, and that their privileged position makes a successful compromise unusually damaging. The security stack deserves at least the same patch discipline as the assets it protects.
