FortiSandbox exploited: CVE-2026-25089 and CVE-2026-39808
The appliance built to examine hostile files has itself become an active target. On July 16, CISA added two FortiSandbox vulnerabilities — CVE-2026-25089 and CVE-2026-39808 — to its Known Exploited Vulnerabilities catalog. Both are OS command-injection flaws, both can be reached over the network without authentication, and both carry a CVSS 3.1 score of 9.8 in the vendor-supplied scoring data.
The US federal remediation deadline was July 19. That deadline applies to federal civilian agencies, but the exploitation signal matters globally: it confirms that this is no longer a hypothetical risk waiting in a scanner report.
What the two CVEs expose
CVE-2026-25089 affects FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS releases identified in Fortinet's advisory. A specially crafted HTTP request can allow an unauthenticated attacker to execute unauthorised commands. CVE-2026-39808 is a separate command-injection path affecting FortiSandbox releases in the 4.4 branch. Administrators should use the vendor advisories, not a copied version table, to identify the correct target release for each deployment.
CISA's decision model labels exploitation active, automation feasible, and technical impact total. Public information does not currently establish a named threat actor or ransomware campaign for these entries. That absence should prevent premature attribution, not delay remediation.
Why compromise of a sandbox is unusually valuable
A sandbox is deliberately placed where suspicious content arrives. It may receive attachments from email-security systems, samples from analysts, files from endpoints, and URLs from other detection products. It also needs controlled outbound access to observe malware behaviour. Those integrations can give a compromised appliance visibility and connectivity that an ordinary web server does not have.
The risk depends on architecture, but responders should consider API credentials, service accounts, file samples, analyst submissions, proxy settings, management sessions, and connections to SIEM, email, endpoint, and orchestration platforms. The security label on the box does not make those relationships safe by default.
Patch first, then answer whether it was used
- Inventory every deployment model. Check physical or virtual appliances, cloud tenants, PaaS instances, disaster-recovery systems, and lab deployments. Confirm versions from the product itself.
- Apply Fortinet's fixes or mitigations. Prioritise any management or HTTP interface reachable from untrusted networks. If a fix cannot be applied, isolate the interface until the deployment has a supported path forward.
- Preserve evidence. Export system, administrator, web, audit, authentication, and network telemetry before rebuilding. Record configuration and integrations. CISA explicitly pairs these KEV entries with forensic-triage requirements for federal agencies.
- Hunt on and around the appliance. Look for unexpected commands or child processes, changed files, new accounts, altered jobs, unusual outbound connections, configuration changes, and activity in connected security platforms.
- Rotate exposed trust. If compromise is found or cannot be reasonably excluded, replace API keys, service-account passwords, certificates, session material, and integration credentials accessible to the appliance. Contain first so the replacements are not captured again.
Do not stop at the internet perimeter
“Our management interface is internal” is useful exposure reduction, not a complete answer. An attacker with VPN access, a compromised administrator workstation, an SSRF path, or a foothold in an adjacent segment may still reach it. Review access logs from every route to the interface and validate which reverse proxies, load balancers, or management networks can send requests.
The broader lesson is uncomfortable: security infrastructure belongs in the incident-response inventory, not outside it. Sandboxes, firewalls, identity systems, EDR consoles, and backup servers concentrate trust. When one of them appears in KEV, the response should account for the credentials and connections it held — not only the vulnerable software version.