FortiSandbox command injection flaws move from patch queue to exploited risk

CISA has added two Fortinet FortiSandbox vulnerabilities to its Known Exploited Vulnerabilities catalog after evidence of active exploitation. Both issues are command injection flaws, both can be reached without authentication, and both carry the kind of impact that turns a security appliance into a possible attacker foothold.

The vulnerabilities are CVE-2026-39808 and CVE-2026-25089. Fortinet had already published fixes in April and June 2026, but CISA's July 16 KEV update changes the operational priority: this is no longer only a vendor patch notice. It is now a confirmed exploitation signal with a July 19, 2026 federal remediation deadline.

For defenders, the core issue is simple. FortiSandbox is supposed to detonate suspicious files and support security analysis. If that appliance or service is reachable and vulnerable, exploitation may give an unauthenticated attacker command execution on infrastructure that often sits near malware samples, analysis workflows, security tooling, and trusted internal integrations.

What CISA added

CISA's KEV catalog now lists:

• CVE-2026-39808 - Fortinet FortiSandbox OS command injection vulnerability
• CVE-2026-25089 - Fortinet FortiSandbox OS command injection vulnerability

CISA says both entries were added on July 16, 2026, with required action by July 19, 2026 for affected U.S. federal civilian executive branch systems. The required action is to apply vendor mitigations in line with BOD 26-04, follow CISA's forensics triage guidance where applicable, or discontinue use if mitigations are unavailable.

That timeline is aggressive for a reason. KEV inclusion means defenders should treat these as exploited vulnerabilities, not theoretical exposure. If a FortiSandbox system was internet-facing, reachable from broad internal networks, or connected to sensitive security operations workflows before patching, the task is both patching and incident response.

CVE-2026-39808: API command injection in FortiSandbox 4.4

Fortinet advisory FG-IR-26-100 describes CVE-2026-39808 as an OS command injection flaw through an API endpoint. Fortinet rates it critical, assigns CVSS 9.1, and says exploitation can allow an unauthenticated attacker to execute unauthorized code or commands through crafted HTTP requests.

Affected versions listed by Fortinet are FortiSandbox 4.4.0 through 4.4.8. The fixed path is to upgrade to FortiSandbox 4.4.9 or later. FortiSandbox 5.0 is listed as not affected for this specific issue.

NVD also records the CVE with a Fortinet CNA score of 9.8 critical and the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which means network reachable, low complexity, no privileges required, no user interaction, and high confidentiality, integrity, and availability impact.

CVE-2026-25089: Web UI command injection across FortiSandbox variants

Fortinet advisory FG-IR-26-141 covers CVE-2026-25089, a second-order OS command injection issue through JSON input in the start VNC feature. Fortinet says the flaw affects the FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS web UI and can allow an unauthenticated attacker to execute unauthorized commands via specifically crafted HTTP requests.

The affected matrix is broader than CVE-2026-39808:

• FortiSandbox 5.0.0 through 5.0.5 should be upgraded to 5.0.6 or later
• FortiSandbox 4.4.0 through 4.4.8 should be upgraded to 4.4.9 or later
• FortiSandbox 4.2 is listed by NVD as affected
• FortiSandbox Cloud 5.0.4 through 5.0.5 should be upgraded to 5.0.6 or later
• FortiSandbox PaaS 5.0.4 through 5.0.5 should be upgraded to 5.0.6 or later

NVD records a Fortinet CNA score of 9.8 critical for CVE-2026-25089, with the same network-reachable, low-complexity, no-authentication, no-user-interaction profile. That is the exact shape defenders do not want on a security appliance.

Why this is more serious than a normal appliance patch

Security appliances are attractive targets because they often occupy trusted positions. They may receive files from email gateways, endpoint tools, web filters, analysts, or automated submission pipelines. They may also have management interfaces, service accounts, outbound access, storage, logs, and integrations that ordinary servers do not.

That makes command execution on FortiSandbox strategically useful. An attacker may not need the appliance as the final objective. It can become a staging point for reconnaissance, persistence, sample tampering, credential access, or lateral movement into adjacent systems if segmentation and access controls are weak.

There is also a detection irony. If a sandbox platform is compromised, defenders must ask whether the system used to analyze suspicious content can still be trusted. That does not mean every vulnerable instance was compromised. It does mean incident handling should include integrity checks, log review, configuration validation, and integration review.

Exposure questions defenders should answer today

The first step is asset clarity. Security teams should identify every FortiSandbox deployment, including physical appliances, virtual appliances, cloud instances, lab systems, managed service environments, and forgotten proof-of-concept installations.

Then answer these questions:

• Which versions are running?
• Are any management or web interfaces reachable from the internet?
• Are any instances reachable from broad user networks, partner networks, or untrusted VLANs?
• Which systems submit samples or data into FortiSandbox?
• Which service accounts, API keys, credentials, or integrations does the platform use?
• Are outbound connections restricted and logged?
• Do logs show suspicious HTTP requests, unexpected commands, new files, configuration changes, or strange outbound traffic?

This is not busywork. A command injection exploit against a security appliance may not look like a conventional endpoint infection. The evidence may sit in web access logs, appliance task history, failed command traces, temporary files, service restarts, unexpected network connections, or downstream alerts from systems the appliance can reach.

Patch and containment priorities

For CVE-2026-39808, upgrade FortiSandbox 4.4.0 through 4.4.8 to 4.4.9 or later. For CVE-2026-25089, upgrade affected FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS versions to the fixed releases identified in Fortinet's advisory.

If immediate upgrade is not possible, reduce exposure first:

• remove public access to management and web UI surfaces
• restrict access to a tightly controlled administrative network
• block unnecessary inbound paths at firewalls and security groups
• restrict outbound access from the appliance to only required destinations
• rotate credentials and API tokens used by the platform after patching if compromise is suspected
• preserve logs before rebooting or rebuilding systems

Do not treat network isolation as a permanent replacement for patching. It is a short-term control to reduce reachable attack surface while the upgrade is completed.

Hunt guidance

For any exposed FortiSandbox instance that was vulnerable during the exploitation window, treat the system as an investigation lead.

Useful checks include:

• web and API request logs around unusual endpoints or crafted payloads
• process execution traces, shell invocation, or unexpected child processes
• newly created files, scripts, scheduled tasks, or persistence mechanisms
• configuration changes, new users, modified credentials, or altered integrations
• unusual outbound traffic from the appliance to unfamiliar destinations
• signs that analysis workflows, submitted samples, or reports were modified
• downstream alerts from systems that trust FortiSandbox outputs or integrations

CISA's KEV entry also points defenders toward forensics triage expectations under BOD 26-04. Even outside U.S. federal scope, the principle is useful: exploited infrastructure should be reviewed for evidence of access, not merely patched and forgotten.

Strategic takeaway

The lesson is not that Fortinet is uniquely risky. The lesson is that security infrastructure is infrastructure. Sandboxes, VPNs, EDR consoles, identity systems, vulnerability scanners, and remote management tools deserve the same hardening, exposure management, monitoring, and fast patch management expected of critical production systems.

With CVE-2026-39808 and CVE-2026-25089 now in CISA KEV, vulnerable FortiSandbox deployments should move to the front of the queue. Patch quickly, reduce exposure immediately, and investigate any instance that was reachable before the fix.

Which Fortinet vulnerabilities did CISA add to KEV?

CISA added CVE-2026-39808 and CVE-2026-25089, both OS command injection vulnerabilities affecting Fortinet FortiSandbox products.

Are the flaws being exploited?

Yes. CISA added both vulnerabilities to KEV based on evidence of active exploitation. BleepingComputer also reported that threat intelligence company Defused had observed exploitation activity in June.

What versions should be patched?

For CVE-2026-39808, FortiSandbox 4.4.0 through 4.4.8 should be upgraded to 4.4.9 or later. For CVE-2026-25089, Fortinet lists affected FortiSandbox 5.0.0 through 5.0.5, FortiSandbox 4.4.0 through 4.4.8, FortiSandbox Cloud 5.0.4 through 5.0.5, and FortiSandbox PaaS 5.0.4 through 5.0.5, with upgrades to fixed branches required.

Why does FortiSandbox exposure matter?

FortiSandbox may sit close to malware analysis workflows, sample submissions, security integrations, logs, and trusted internal systems. Command execution there can become a broader security operations compromise path.

What is the highest-priority action?

Find all FortiSandbox deployments, verify versions, remove broad network exposure, upgrade to fixed versions, and review exposed vulnerable instances for signs of compromise.

References

1. CISA Known Exploited Vulnerabilities Catalog
2. OS Command Injection through API endpoint
3. Second-Order OS Command Injection via JSON Input on start vnc feature
4. CVE-2026-39808 Detail
5. CVE-2026-25089 Detail
6. CISA urges immediate action on actively exploited Fortinet flaws