Skip to content

Fortinet patches unauth command injection in FortiSandbox (CVE-2026-25089)

Crafted HTTP requests against the FortiSandbox web UI yield OS command execution. CVSS 9.1. No active exploitation reported. Fixed in 5.0.6 and 4.4.9.

Published 4 min read

Fortinet published patches on June 9, 2026 for CVE-2026-25089, an unauthenticated OS command injection in the FortiSandbox web UI. The vendor scored it 9.1 (CVSS v3). The Fortinet PSIRT advisory ships from the FortiGuard portal; the flaw is reachable over the network without credentials by sending specifically crafted HTTP requests to an exposed management interface.

As of the advisory's publication, Fortinet reports no known in-the-wild exploitation. Coverage by SecurityWeek, The Hacker News and Security Affairs repeats the same vendor framing.

Affected versions

  • FortiSandbox 5.0.0 through 5.0.5
  • FortiSandbox 4.4.0 through 4.4.8
  • FortiSandbox 4.2all versions (no further updates planned for this train)
  • FortiSandbox Cloud 5.0.4 through 5.0.5
  • FortiSandbox PaaS 5.0.4 through 5.0.5

Fixed in 5.0.6, 4.4.9, and the matching Cloud and PaaS 5.0.6 builds. The 4.2 train is out of support — the only viable upgrade path is jumping to a 4.4.x or 5.0.x branch.

What the bug does

The classification is CWE-78, Improper Neutralization of Special Elements used in an OS Command. The flaw lives in the GUI's request-handling layer: parameters carried in an HTTP request are passed to a downstream shell invocation without sufficient sanitisation, and an attacker who can reach the management interface can break out of the intended command string to run arbitrary OS commands as the web service account.

There is no authentication requirement and the attack complexity is low. Successful exploitation gives full compromise of confidentiality, integrity and availability on the appliance.

The architectural detail worth flagging: a FortiSandbox is, by design, a high-value pivot. It receives suspected malware samples from FortiGate, FortiMail and FortiClient deployments, runs them in instrumented VMs, and ships verdicts back into the policy fabric. Whatever else lives on the same management network — and whatever signing or update keys the appliance holds — is the post-compromise blast radius.

Exploitation status

Per Fortinet's own statement at disclosure: no observed exploitation. No public PoC at time of writing. There is no GreyNoise tag or CISA KEV add on the CVE as of June 13.

This is the window. Fortinet appliance CVEs historically pivot from advisory to mass exploitation in days, not weeks — see the FortiOS pre-auth chain CVE-2024-21762 (mass-exploited within a fortnight of patch) or the FortiClient EMS arc covered in our CVE-2026-35616 post. Patch on the same emergency change cadence you reserve for the perimeter firewalls, not the next monthly window.

Action checklist

  1. Upgrade affected appliances to FortiSandbox 5.0.6 or 4.4.9 (and Cloud/PaaS 5.0.6) before the weekend. The advisory ships no workaround patch, no configuration toggle that takes the vulnerable code path out of the line of fire — the point release is the only remediation.
  2. If you are on FortiSandbox 4.2, plan the train migration now. The 4.2 line will not receive a fix for this CVE or any future one. Treat the appliance as end-of-life from a security standpoint.
  3. Close the management interface to the public internet. A FortiSandbox web UI exposed to anything beyond a known administrative network is a configuration error independent of this CVE. If a Shodan or Censys scan against http.html_hash or http.title for FortiSandbox returns hits in your address space, that is the higher-priority finding.
  4. Audit upstream trust paths. Every FortiGate, FortiMail, FortiClient EMS and FortiAnalyzer that submits files to a vulnerable FortiSandbox is a potential downstream victim of a tampered verdict. Until the appliance is on a fixed build, treat its outputs as untrusted.
  5. Pull web-server access logs going back to mid-May. Look for unexpected POST requests to GUI endpoints from non-administrative source IPs. The CVE is unauthenticated; you will not see a login event upstream of a successful exploit.
  6. Rotate any shared secrets the appliance held — proxy credentials to upstream sandbox-cloud services, SMTP relay creds, syslog forwarder tokens — once the patch is in place. Assume the worst case for the window between mid-May and your patch timestamp.

Context

This is the second high-severity FortiSandbox issue patched inside twelve months. The product line sits next to FortiManager, FortiAnalyzer and FortiClient EMS as management-plane appliances whose compromise sidesteps the perimeter entirely — the same category the Cloud Security Alliance has been flagging since the Ivanti EPM and Connect Secure chains in 2024.

The pattern across the broader security-appliance category is now stable enough to plan around: the management interface is the soft target, not the data plane. Fortinet, Ivanti, Cisco, Palo Alto and SonicWall have each shipped at least one unauthenticated-RCE-on-management-port advisory in the last two years. The right operational posture is to treat every vendor management UI as a tier-0 asset on a private network only, regardless of how the deployment guide draws the topology.

Related stories