The appliance vetting your traffic is now handing out shells
The thing that stuck with me reading this Fortinet advisory is how quietly bad it is. FortiSandbox is the box FortiGate, FortiMail, FortiClient, and FortiEDR all call to ask whether a file is malicious before they let it through. So when a single GET request to the FortiSandbox web service hands an attacker root on that appliance, the rest of the Fortinet stack is taking blocking decisions from a machine an outsider now owns. Defused Cyber's honeypots have been catching that exact request, on port 443, against decoy FortiSandbox instances since June 15, 2026, and the requests have not stopped (Help Net Security). The bug they are throwing is CVE-2026-39808, and there are two siblings in the bundle.
A pipe character in one parameter
CVE-2026-39808 is unauthenticated and network reachable. The vulnerable endpoint is /fortisandbox/job-detail/tracer-behavior, the job identifier in the jid GET parameter is concatenated straight into a shell command without filtering, and the pipe character splits commands on every Unix shell on earth. FortiSandbox accepts it unchanged. The public proof of concept is a single curl line that drops the output of id into a file the web service later serves back over HTTP, roughly the shortest possible "I am root on your appliance" demonstration: curl -s -k --get "https://target/fortisandbox/job-detail/tracer-behavior" --data-urlencode "jid=|(id > /web/ng/out.txt)|" (PoC repository, Cyber Security News). Fortinet rated it critical at CVSS 9.8 in PSIRT advisory FG-IR-26-112, published April 14, 2026, and a Nuclei detection template has been public since the same week. Two months later, Defused's sensors caught the first scan, and the traffic has not stopped.
The path traversal that does not need a session
The companion bug is CVE-2026-39813, a path traversal in the same JRPC API that bypasses authentication. The session string that is supposed to identify an already authorised caller gets read as a filesystem path, and the validator quietly allows ../ segments inside it. Walk out of the directory the validator expects, land on a file it already trusts as proof of a live session, and the request is processed as authenticated when it never was (GitHub Advisory GHSA-5f64-p6cf-vvqg). CVSS 9.8. The obvious chain is 39813 to bypass the JRPC auth layer, then 39808 to reach the shell, or 39808 on its own when the tracer endpoint is reachable. The honeypot data shows POSTs to /jsonrpc/ on port 443, the path 39813 chains through, with most traffic so far from a single ASN (SecurityWeek).
The third bug, vibecoded and still landing
The newest of the three is CVE-2026-25089, an OS command injection in the web UI's start VNC feature, disclosed in Fortinet's June 9, 2026 advisory FG-IR-26-141 and rated 9.1. The live exploit attempts against this one look unusual: the payload shape suggests a model generated it rather than a human, and the logic is faulty in ways a careful attacker would not ship. It is landing anyway. Reports describe it as the first widely observed "vibecoded" exploit against a real appliance (Help Net Security). A faulty exploit still works on an unpatched appliance often enough to matter, and Cloud and PaaS are in scope alongside on-premises 4.4.0 through 4.4.8 and 5.0.0 through 5.0.5.
Why a CVSS queue lands this further down than it should
The headline numbers are not the problem. All three are rated critical or near it. The reason this set has sat unpatched on real networks for two months, long enough for Defused to start picking up live scans, is that FortiSandbox is the kind of appliance most teams put on the second page of their fleet inventory. It is internal, it talks to other Fortinet products, and the team that runs it is usually the SOC, not the network engineering group that owns the FortiGate cluster. A CVSS-first patch list sorts by score, not by what the box does for a living, and the advisory landed inside a quarterly batch that included a dozen other items. By the time the public PoC and Nuclei template arrived a week later, most teams had already cleared the inbox.
What a normal scanner cannot tell you is whether your FortiSandbox JRPC API and web UI are reachable from anything you do not control. That is the byte that flips this from a high finding to top of queue.
How TRIS scores it
This is the gap I built TRIS into CVEasy AI to close. CVSS rates the bug. TRIS, the Threat and Risk Intelligence Scoring engine inside the platform, scores the bug against where the affected appliance actually sits in your environment. Three layers move this finding.
Active exploitation. Defused Cyber confirmed inbound traffic against decoy FortiSandbox instances starting June 15, 2026, with POST requests to /jsonrpc/ over port 443 continuing through this week. A honeypot hit is not the same as a confirmed in-the-wild breach, and TRIS treats it that way: weight raised, not pinned to the top, until the data shows actual compromised production instances.
Blast radius. Every Fortinet deployment that uses FortiSandbox to deliver verdicts inherits the exposure. FortiGate firewall policies, FortiMail attachment scanning, FortiClient EDR decisions, and FortiEDR response actions all consume what the sandbox tells them. Root on the sandbox is a position upstream of the rest of the stack, and the stack has no way to know its source of truth is lying.
Real exposure. The same CVE is not the same risk on every box. A FortiSandbox whose JRPC API and web UI are only reachable from the management VLAN is a worry but not a fire. A FortiSandbox whose web UI is reachable from anything an unauthenticated outsider can touch, including a forgotten DMZ rule or a misconfigured load balancer, is a pre-authentication shell waiting to be claimed. CVSS gives both the same 9.8. TRIS gives the exposed one ACT, the top band you handle today, and parks the segmented one well down the queue where the patch can land on a normal change window. One CVE, two scores, because the only honest answer depends on the network around the box.
What to patch and what to hunt for
The fix is short. Upgrade FortiSandbox 4.4 deployments to 4.4.9 or later, and 5.0 deployments to 5.0.6 or later per FG-IR-26-112. Cloud and PaaS tenants were updated by the vendor under FG-IR-26-141; confirm yours is on the patched build. If you cannot patch this week, restrict the JRPC API on port 443 and the web management UI to a trusted management VLAN, since the surface area for all three bugs is those same two interfaces.
While you are there, hunt your access logs for POST requests to /jsonrpc/ and any GET against /fortisandbox/job-detail/tracer-behavior whose jid parameter contains a pipe, semicolon, backtick, or $( sequence. Defused's published telemetry lists one origin IP, 141.11.43.175 in ASN 136510, but the public PoC is short enough that any number of operators have it. Look in /web/ng/ for files written by the web user that should not exist; that is where the PoC drops its output. If you find a hit, treat the box as compromised: rebuild rather than clean, rotate the management credentials it had, and walk back through the verdicts it returned during the exposure window.
How CVEasy AI surfaces this
When a Fortinet appliance bug of this shape lands, CVEasy AI, the number one local-first CTEM platform, ingests the PSIRT advisory, the public PoC, the Defused telemetry, and the downstream Fortinet integration documents that show where each sandbox sits in a fleet, then runs the combined picture through TRIS against the asset inventory that lives entirely on your hardware.
From there it answers the questions that actually decide your week: which of your FortiSandbox instances are on a vulnerable 4.4 or 5.0 build, which expose /jsonrpc/ or the web UI outside the management VLAN, and which downstream FortiGate, FortiMail, FortiClient, and FortiEDR clusters lean on those sandboxes for verdicts so a sandbox exposure becomes a policy exposure. The internet-reachable sandbox rises to ACT, the segmented one settles where it belongs, and the dependency map keeps the SOC honest about which verdicts to retroactively trust. Local-first matters here for a reason specific to Fortinet fleets: your verdict history, management VLAN topology, and integration map never leave your network, because TRIS runs the analysis where the data already lives.