Two 9.1 command-injection bugs turn Fortinet's malware sandbox into an entry point
Cybersecurity

Two 9.1 command-injection bugs turn Fortinet's malware sandbox into an entry point

CVE-2026-25089 and CVE-2026-39808 let unauthenticated attackers run commands on FortiSandbox appliances, and CISA added both to its exploited-vulnerabilities catalog with a July 19 deadline.

PublishedJuly 27, 2026
Read time6 min read
Share

What the flaws do

FortiSandbox is Fortinet's malware-detonation platform, the appliance an enterprise points suspicious files at so they explode in a controlled environment rather than on a laptop. Two vulnerabilities now let attackers turn that defensive tool against its owner. CVE-2026-25089 and CVE-2026-39808 are OS command-injection flaws, both rated CVSS 9.1, both exploitable by an unauthenticated attacker sending crafted HTTP requests. Neither requires user interaction or valid credentials. Successful exploitation runs arbitrary operating-system commands on the appliance, which is a full compromise of a device that already holds broad visibility into the files and traffic an organization considers risky. Fortinet classified both under CWE-78, command injection.

The two bugs differ in blast radius. CVE-2026-39808 affects the FortiSandbox appliance directly. CVE-2026-25089 reaches further, hitting FortiSandbox alongside FortiSandbox Cloud and FortiSandbox PaaS deployments, which pulls managed and cloud-hosted customers into scope rather than just on-premises operators. Threat intelligence firm Defused reported active exploitation beginning in mid-June, weeks before the flaws drew federal attention. That gap between exploitation and public alarm is the familiar shape of an edge-appliance campaign, where attackers work quietly against a device most defenders rarely inspect from the inside. The appliance logs the network, and few teams log the appliance.

The irony of a compromised sandbox

A malware sandbox is an unusually valuable thing to own. It receives a steady stream of the files an organization already suspects, it holds the detonation results and detection signatures, and it sits with enough network reach to fetch samples and report verdicts. An attacker who executes commands on that box inherits a vantage point at the center of the security stack. They can watch what defenders are looking at, potentially suppress or alter verdicts, and pivot from a trusted internal system that other tools are inclined to believe. The device built to study attackers becomes a comfortable place for one to live.

This is the recurring problem with security appliances as a category. They are deployed at network edges, granted deep internal trust, and then treated as sealed boxes that receive occasional firmware updates and little scrutiny. The same properties that make them useful, privileged placement and broad visibility, make them prizes when they fall. FortiSandbox joins a long list of Fortinet, Ivanti, Citrix, and SonicWall devices that attackers have turned from guardrail into gateway over the past two years. The lesson applies well beyond any one vendor. Appliances need the same patch urgency and monitoring that operators reserve for their most exposed servers.

Fixes existed, exploitation happened anyway

Fortinet released the fix for CVE-2026-39808 on April 14 and for CVE-2026-25089 on June 9. Exploitation was observed from mid-June, and CISA added both flaws to its Known Exploited Vulnerabilities catalog in mid-July, with reporting citing July 15 and July 16, alongside a July 19 federal patch deadline under Binding Operational Directive 26-04. The available patches did not prevent the campaign, because appliance firmware updates lag badly in most environments. Upgrading a FortiSandbox is a maintenance event that touches a live security control, so teams defer it, and attackers exploit the deferral. The fix was available for months and still arrived late.

Appliance patch latency has a structural cause. The device is doing important work, taking it offline briefly feels like lowering the drawbridge, and the update process can carry its own risk of breaking detection pipelines. So the sandbox keeps running last quarter's firmware while a public advisory names a 9.1 command-injection flaw against it. CISA's short deadline reflects a judgment that this specific risk outweighs the inconvenience of an out-of-cycle update. Private operators without a mandate should still treat it that way. An unpatched, internet-reachable security appliance with a known unauthenticated exploit is one of the cleaner ways an enterprise hands an attacker a foothold.

Cloud and PaaS widen the target list

The inclusion of FortiSandbox Cloud and PaaS in CVE-2026-25089 changes who has to act. On-premises operators can reason about their own network exposure and patch on their own schedule. Customers of the cloud and PaaS offerings depend on Fortinet's remediation timeline and on their own understanding of what the service touches inside their environment. Managed and hosted security services carry an implicit assumption that the provider handles this class of problem, and mostly that assumption holds. A critical unauthenticated flaw in the hosted control plane tests it directly, because the customer inherits the risk while controlling few of the levers to fix it.

This is the shared-responsibility seam that trips up a lot of security programs. A hosted sandbox feels like a service you consume, yet it still integrates with your network, ingests your files, and holds connectors into your environment. When the hosted component is the vulnerable one, the questions shift to what the provider has patched, when, and how they would notify you of compromise. Enterprises using FortiSandbox Cloud or PaaS should be asking Fortinet those questions now and documenting the answers. The exposure did not disappear because the box lives in someone else's data center. It moved, and the accountability for understanding it did not.

What to do now

Patch first. Apply the fixed FortiSandbox releases across on-premises, Cloud, and PaaS deployments, and confirm the versions rather than assuming the update landed. Any management interface reachable from the internet should be pulled behind access controls immediately, because unauthenticated HTTP exploitation depends on reachability. Where a patch cannot happen this week, restrict the appliance's inbound HTTP exposure to known administrative sources and watch for anomalous command execution and unexpected outbound connections from the device. The compromise indicators here are visible once you look, and they require actually logging and inspecting a box most teams treat as furniture.

The broader move is to fold security appliances into the same vulnerability-management discipline as everything else. Inventory every Fortinet device and its firmware version, subscribe to the vendor's advisories, and set an internal SLA for KEV-listed appliance flaws that matches the urgency you would give an exposed web server. Edge devices earned their reputation as an attacker favorite by being privileged, trusted, and under-monitored, and that reputation will hold until operators stop treating them as exceptions. This advisory is a specific reason to check one class of device today, and a general reminder that the tools guarding the perimeter are part of it.

Tagged#news#security#cybersecurity#breach#cisa#ransomware#zero-day#supply-chain#ai-security#fortinet#fortisandbox#cve-2026-25089#cve-2026-39808#command-injection#kev#edge-appliance#unauthenticated-rce#patch-management