Start VNC, Start a Shell: Inside CVE-2026-25089 on FortiSandbox
Fortinet has shipped three CVSS 9.8 advisories against FortiSandbox this year. Two of them, disclosed two months apart, are both unauthenticated code execution, and both were confirmed under active exploitation within weeks of going public. This post is about the more recent one: CVE-2026-25089, an OS command injection in the FortiSandbox Web UI that needs nothing from an attacker but a crafted HTTP request.
What FortiSandbox is doing on your network
FortiSandbox is Fortinet’s detonation appliance. Files that a FortiGate, FortiMail, or FortiWeb device flags as suspicious get forwarded to it, opened in an isolated environment, and scored for malicious behavior before a verdict comes back to the device that submitted them. If you’ve read the NSE4 security profiles post on this site, this is the FortiSandbox integration mentioned there in one line: FortiGate holds traffic pending a verdict if you’ve configured it to.
That job puts FortiSandbox in an unusual position for a security appliance. It has to reach out and ingest genuinely malicious content as its normal, everyday function, and depending on deployment it often sits with a wider network reach than a typical branch firewall, since it needs visibility into whatever’s forwarding samples to it. An unauthenticated command execution bug on a box built to open malware for a living is about as bad a combination as this category of hardware gets.
The vulnerability
CVE-2026-25089 (Fortinet’s own tracking ID FG-IR-26-141) is CWE-78, improper neutralization of special elements used in an OS command, in the FortiSandbox Web UI. Fortinet’s own CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, a 9.8, meaning network-reachable, low attack complexity, no privileges required, no user interaction, and full compromise of confidentiality, integrity, and availability if it lands.
The reported mechanism is a JSON payload sent to the Web UI’s “start VNC” endpoint, where shell metacharacters in a request parameter reach an OS command without being neutralized first. I’m not reproducing the exact payload shape here. The mechanism is public in third-party writeups already, but this site’s standing rule for actively-exploited CVEs with a live public trail is to describe what’s wrong, not hand over working steps, the same line this site held for CVE-2026-45504’s SSRF chain and for CVE-2026-20245’s crafted-CSV privilege escalation.
Affected and fixed versions
| Product | Affected | Fixed |
|---|---|---|
| FortiSandbox | 5.0.0 – 5.0.5 | 5.0.6 or later |
| FortiSandbox | 4.4.0 – 4.4.8 | 4.4.9 or later |
| FortiSandbox | 4.2, all versions | Contact Fortinet support for a 4.2 fix build |
| FortiSandbox Cloud | 5.0.4 – 5.0.5 | 5.0.6 or later |
| FortiSandbox PaaS | 5.0.4 – 5.0.5 | 5.0.6 or later |
If you can’t patch immediately, Fortinet’s stated workaround is to restrict HTTP access to the FortiSandbox management interface to authorized IP addresses only. That’s a real mitigation here, not a formality, since the bug requires nothing but network reach to the Web UI.
A second CVSS 9.8 in the same product, two months earlier
CVE-2026-25089 isn’t FortiSandbox’s only maximum-severity bug this year. CVE-2026-26083 (FG-IR-26-136), disclosed 12 May 2026, is a missing authorization vulnerability, also CVSS 9.8, also unauthenticated, also reachable via crafted HTTP requests, and also confirmed under active exploitation by early July. Different root cause (CWE for missing authorization rather than command injection), same outcome, same product, roughly two months apart. If you run FortiSandbox and only patched for one of these, check which one.
Timeline
FortiSandbox 5.0.0 shipped exposed to this bug from the start. Fortinet disclosed CVE-2026-25089 on 9 June 2026. Singapore’s CSA issued an alert on 12 June. CISA’s own tracking shows exploitation activity confirmed as active by mid-June, and the CVE landed on the Known Exploited Vulnerabilities catalog on 16 July 2026 with a near-immediate federal remediation deadline under BOD 26-04. By the time most organizations outside the federal patching mandate heard about this, it had already been a working exploit in the wild for a month.
Where this fits
This site has covered a run of unauthenticated Fortinet bypasses this year: the FortiManager FGFM certificate-trust bypass and the FortiWeb RADIUS wildcard admin bypass both landed the same week in August, and neither needed a stolen credential to matter. CVE-2026-25089 is a step past both of those: not a bypass into an authenticated context, straight to arbitrary command execution, on a device whose entire job is opening things nobody else on the network is willing to open.
It’s also a reminder of what tends to come after initial access on Fortinet gear once someone’s in: the Gunra ransomware advisory covered on this site last month documented attackers creating a persistent local super-admin account named to blend in with legitimate FortiCloud services, precisely the kind of follow-on step an unauthenticated RCE like this one buys time for. And if you’re the one deciding how aggressively to tune IPS signatures and outbreak protection around appliances like this, the FortiGuard tuning post covers the delivery-channel side of that decision.
If you run FortiSandbox anywhere on your network, this isn’t a “patch it this quarter” bug. It’s a “check right now whether the management interface is reachable from anywhere it shouldn’t be, then patch” bug.
Sources: Fortinet PSIRT FG-IR-26-141 · NVD CVE-2026-25089 · CISA Known Exploited Vulnerabilities Catalog · Singapore CSA Alert AL-2026-073