FortiSandbox: CVE-2026-39808 and 25089 under active attack

There’s a particular irony in a device bought to detect malware becoming the way into the network. That’s exactly what is happening with FortiSandbox — Fortinet’s solution for analysing suspicious files in an isolated environment. Two vulnerabilities, CVE-2026-39808 and CVE-2026-25089, both rated CVSS 9.1, allow an unauthenticated attacker to execute operating-system commands on the appliance. The US agency CISA confirmed active exploitation and added both to its KEV (Known Exploited Vulnerabilities) catalogue, setting a federal remediation deadline of 19 July 2026.

The patches have existed for a while — Fortinet fixed CVE-2026-39808 in April and CVE-2026-25089 in June 2026. Which means the problem isn’t a missing patch, but how long unpatched appliances sit exposed. Below we break it down: what exactly is vulnerable, why a sandbox is such a valuable target, how the attack works, how to spot compromise, and what to do in an order that makes sense.

What FortiSandbox actually is, and what’s inside it

Before assessing the risk, it’s worth understanding the appliance’s function, because the blast radius follows from it.

FortiSandbox is a sandbox / detonation chamber. Its job is to accept files and URLs that other security components can’t classify with confidence, run them in a controlled, isolated environment (usually virtual machines with various OS and application versions) and observe what they try to do. If a file encrypts documents, modifies registry keys, injects code into other processes or contacts a command server — the sandbox sees it and issues a verdict.

Four properties follow from that function, and together they make it an unusually attractive target:

First, a sandbox sits in a privileged network position. To receive samples it must be reachable by the mail gateway, the firewall, the web proxy and endpoints. That means broad internal connectivity — the opposite of the isolation you’d demand of a system that processes malicious files.

Second, it holds credentials to other systems. Integration with FortiGate, FortiMail, FortiWeb or FortiClient requires API keys and service accounts. Whoever takes the sandbox gets a bundle of credentials to the security infrastructure as a bonus.

Third, company content flows through it. Email attachments, files downloaded by employees, documents submitted through forms. In practice the sandbox sees a meaningful share of everything entering the organisation — including sensitive documents submitted for analysis “just in case”.

Fourth, it is trusted and poorly monitored. Outbound traffic from a sandbox to the internet is normal (it must fetch signature updates, and analysts often let samples “phone home” to observe behaviour). An alert on an unusual connection from this device simply won’t fire — because unusual connections are its daily routine.

Put that together: a device with broad internal access, keys to other security systems, visibility into company content and naturally “noisy” network traffic. It’s hard to imagine a better foothold.

Mechanics: operating-system command injection

Both flaws belong to the OS command injection class, catalogued as CWE-78. The mechanism is easy to understand and, unfortunately, just as easy to introduce in code.

The appliance’s web application accepts user-supplied data (a parameter in an HTTP request) and then — instead of using a safe system call with separated arguments — concatenates it into a string and passes it to a shell interpreter. The interpreter doesn’t distinguish “data” from “commands”: it sees only text to execute. If the data contains characters that are special to the shell — a semicolon, a pipe, &&, a backtick, $(...) — they terminate the intended command and start a new one written by the attacker.

A simplified illustration of the pattern (deliberately without details matching any specific product):

# Vulnerable code — the parameter goes straight to the shell
cmd = "ping -c 1 " + user_input
system(cmd)

# user_input = "8.8.8.8; id"
# the shell executes: ping -c 1 8.8.8.8 ; id

For FortiSandbox two risk amplifiers matter. First, the attacks are delivered via specially crafted HTTP requests — the same channel the appliance normally communicates on. Second, and this is the crux, the flaws are unauthenticated. The attacker needs no account, no password, no valid session. It’s enough to reach the appliance’s interface over the network.

Command execution happens in the context of the process serving the web application. Even if that isn’t immediately root, the attacker gains a code-execution foothold inside a security appliance, from which they can map the network, read configuration files, steal integration keys and establish persistence.

Why CVSS 9.1 rather than 10.0

A 9.1 instead of the maximum usually reflects that the vector doesn’t produce the full set of impacts in the CVSS model (for instance availability impact scored lower than confidentiality and integrity). For a defender that distinction is meaningless in practice. What counts is the combination: remote, unauthenticated, command execution, confirmed exploitation in real attacks. That set puts a vulnerability at the top of the queue regardless of the second decimal — as we discuss in how to prioritise critical vulnerabilities.

What’s affected and where the fixes are

Item	Status
Products	FortiSandbox, FortiSandbox Cloud, FortiSandbox PaaS
Bug class	OS command injection (CWE-78)
Authentication	not required
Rating	CVSS 9.1 (both flaws)
CVE-2026-39808	fix released April 2026
CVE-2026-25089	fix released June 2026
Status	active exploitation, both in CISA KEV
US agency deadline	19 July 2026

Note that research published in the same period also discusses CVE-2026-39813 alongside these two. So when planning work, don’t treat this as “two isolated CVEs” — check the full set of Fortinet advisories for your version and bring the appliance to the current release rather than patching selectively.

A note on the cloud variants: the presence of FortiSandbox Cloud and PaaS on the list doesn’t excuse inaction. Establish with your provider who is responsible for updating the instance and ask for written confirmation of the version and the date the fix was applied. That’s a standard part of third-party risk management that’s easy to forget with managed services.

Security edge appliances — the recurring pattern of 2026

This story isn’t isolated, and that’s precisely why it matters. Over recent months the same pattern has repeated: a critical, unauthenticated flaw in a security or access appliance, quickly moving into real-world attacks. We covered SonicWall SMA1000, FortiClient EMS and FortiCloud SSO.

Why this category? Because it combines four properties attackers look for:

It’s network-exposed — by definition, since it handles inbound traffic or remote access.
You can’t install an EDR on it. It’s a closed system; host-based detection tools have no way in, so the attacker operates in a blind spot.
It has high privilege and trust. It terminates VPNs, sees traffic, holds credentials, integrates with the rest of the infrastructure.
It’s rarely in the patch cycle. Servers get updated monthly; appliances tend to be treated like network gear — “it works, don’t touch it” — and sit for years on the version they shipped with.

The strategic conclusion is uncomfortable: security appliances must be patched faster than servers, not slower. In practice it’s usually the reverse.

How to check whether you’re already too late

With a vulnerability confirmed in active attacks, applying the patch doesn’t answer whether someone got in earlier. Since you can’t deploy an EDR agent on the appliance, detection relies on what’s visible from outside and in the logs.

Web interface access logs. Look for requests to administrative endpoints from addresses outside the admin range, bursts of unusual requests in a short window, and parameters containing shell metacharacters (;, |, &&, `, $(). Their presence in fields that should hold a filename or an IP address is an unambiguous signal.

Outbound traffic from the appliance. This is the most valuable source, despite the noise mentioned earlier. Build a baseline of what’s normal (vendor update servers, reputation services) and surface the rest: connections to newly registered domains, long-held sessions, regular “beacons” at even intervals (characteristic of a C2 channel), transfers with atypical volume.

Traffic from the appliance into the network. A sandbox should talk to a specific set of systems. Authentication attempts against a domain controller, scanning of address ranges or SMB connections to workstations are behaviour that has no business appearing in this profile — and make an excellent detection rule to own regardless of this specific flaw. We cover building such rules in security monitoring.

Configuration and account integrity. Compare the current configuration against the last known-good copy. Watch for new administrative accounts, added SSH keys, changed remote-access settings and new scheduled tasks.

Vendor support. If you suspect compromise, preserve a state dump and contact Fortinet before you start “cleaning up”. Limited operating-system access means part of the forensic analysis is only feasible on the vendor’s side — and a premature factory reset destroys the evidence.

A remediation plan in an order that makes sense

Step 1: Establish what you have and what’s visible. Inventory every FortiSandbox instance — physical, virtual, cloud and the ones in forgotten locations. Then check which of them are reachable from the internet. That’s the role of external attack surface management (EASM); if you have no tooling, start with a simple scan of your own address ranges.

Step 2: Take the management interface off the internet. This is the action with the biggest effect in the shortest time. A security appliance’s admin panel has no reason to be publicly reachable. Restrict access to a dedicated management network or VPN, ideally with an allowlist.

Step 3: Update to a release containing the full set of fixes. Not just the one removing a single CVE — to the current release of a supported branch. Check the vendor advisories to see whether your version is also affected by other flaws in the series.

Step 4: Rotate secrets. If the appliance was exposed and unpatched during the window, assume its secrets may have leaked: integration API keys, service account passwords, certificates, credentials to systems it connects to. A patch doesn’t invalidate stolen keys — a principle we repeat with every serious incident.

Step 5: Reduce the appliance’s network trust. Ask the design question: why can the sandbox initiate connections to any host on the internal network? Define an allowlist of directions and block the rest. The same mechanism that limits the impact of a sandbox compromise limits the impact of any other system’s compromise — a practical application of internal network segmentation.

Step 6: Put appliances into the process. Get to a state where security appliances have an assigned owner, a subscription to vendor advisories and a defined response time for critical CVEs — measured in days, not quarters. That’s part of a mature vulnerability management process.

Frequently asked questions (FAQ)

Our FortiSandbox isn’t internet-facing. Can we deprioritise this? Don’t skip it, but you can consciously lower the priority. No public exposure substantially reduces risk; the flaw remains exploitable by someone who already has internal network access — the scenario after a phishing hit or a compromised workstation. Since a sandbox is by design reachable from many internal systems, it makes a convenient second-step target.

Fortinet shipped fixes in April and June. Why active exploitation in July? That’s the classic “n-day” phenomenon. Attackers analyse published patches, reconstruct the bug details from them and scan the internet for un-updated devices. The window between a patch’s release and its deployment is, in practice, the attack window — and with edge appliances it’s often measured in months.

Is a WAF in front of the appliance enough? Treat it as temporary. A rule blocking known injection patterns raises the bar, but payloads can be modified and a virtual patch doesn’t remove the root cause. Use it to buy time for a maintenance window — not instead of the update.

We’ve updated the appliance. Anything else to do? Yes, two things. First, review logs and traffic retrospectively for the period when the appliance was vulnerable and exposed. Second, if you find anything unusual, rotate integration credentials and treat it as an incident per your response plan.

How do we even find out how many such appliances we have and whether they’re current? Start with an inventory: device list, software versions, owners, network exposure. In practice the biggest findings come from comparing what “should be there” with what actually answers a scan. Get in touch if you’d like us to run that external reconnaissance for you.

Summary

CVE-2026-39808 and CVE-2026-25089 are a case where everything needed for defence was available for months — the fixes shipped in April and June — and yet appliances were being attacked in July. The problem isn’t knowledge or technology, it’s process: security appliances fall out of the patch cycle because they “work”, and their compromise is unusually hard to notice because you can’t run conventional detection on them.

The practical list is short: inventory your instances, take management panels off the internet, bring firmware to the current release, rotate secrets if you were in the exposure window, and limit what the appliance may talk to on the network. If you want to know how many such systems are visible from outside your organisation and how fast you close critical windows — let’s verify it with a controlled test.

Sources and further reading: Fortinet PSIRT Advisories, CISA KEV, The Register, Help Net Security, CWE-78.