The active exploitation of three critical vulnerabilities in Fortinet FortiSandbox is particularly concerning because the affected product is itself designed to analyse suspicious files and detect advanced threats. Attackers have been observed targeting CVE-2026-39813, CVE-2026-39808, and CVE-2026-25089, all of which carry a critical severity rating. Two of the vulnerabilities were addressed in April 2026, while the third was fixed in June 2026.

CVE-2026-39813 is a path-traversal vulnerability in the FortiSandbox JRPC API that can allow an unauthenticated remote attacker to bypass authentication through specially crafted HTTP requests. CVE-2026-39808 is an operating-system command-injection vulnerability that can enable an unauthenticated attacker to execute unauthorized commands or code.

CVE-2026-25089 is another unauthenticated operating-system command-injection vulnerability affecting the FortiSandbox web interface, FortiSandbox Cloud, and FortiSandbox PaaS. Crafted HTTP requests could allow an attacker to execute commands on affected systems.

What makes this incident more serious than an ordinary application vulnerability is FortiSandbox’s position within the security architecture. A sandbox typically receives suspicious files, email attachments, URLs, and malware samples from firewalls, email gateways, endpoints, and other security systems. It may also be connected to management platforms and have access to internal networks, security telemetry, file repositories, and administrative credentials.

If attackers compromise such a system, they could potentially execute commands, install persistent access mechanisms, manipulate configurations, interfere with malware analysis, access submitted files, steal credentials, or use the appliance as a trusted point from which to explore the wider network. A security appliance becoming an attacker-controlled platform is an especially uncomfortable form of irony.

An attacker may also attempt to alter or suppress analysis results. This could allow malicious files to be incorrectly classified as safe or prevent security administrators from receiving accurate threat information. Although there is no public confirmation that these specific outcomes occurred in the observed exploitation, they remain credible risks when arbitrary command execution is possible on a security-analysis platform.

The reported attacks also demonstrate how quickly vulnerabilities can be weaponized after disclosure. Exploitation activity emerged shortly after fixes became available, leaving organizations with very little time between patch release and attacker interest. Traditional monthly patch cycles are increasingly unsuitable for internet-facing or security-critical infrastructure.

Reports also suggested that one exploit contained signs of AI-assisted development and was technically faulty. This should not provide reassurance. A defective exploit can be corrected, copied, or improved rapidly once vulnerability details are available. AI-generated exploit code may reduce the effort required for less capable attackers to conduct scanning and experimentation, even when the first version is unreliable.

Organizations using FortiSandbox should immediately identify all deployed instances, including physical appliances, virtual machines, cloud deployments, disaster-recovery systems, testing environments, and management interfaces that may have been overlooked.

Affected systems should be upgraded to the corrected FortiSandbox releases specified by Fortinet. Customers using FortiSandbox Cloud or PaaS should confirm the remediation status of their environment and verify that their tenant is running a fixed release.

Patching must not be treated as proof that the system was never compromised. Since active exploitation has been reported, any vulnerable and externally reachable FortiSandbox instance should be reviewed for indicators of unauthorized activity. Security teams should examine web-access logs, JRPC API activity, administrative authentication records, system commands, process execution, file modifications, configuration changes, scheduled tasks, and outbound network connections.

Particular attention should be paid to unexpected HTTP requests to management or API endpoints, unusual path-traversal patterns, command separators or shell syntax inside request parameters, newly created accounts, unfamiliar SSH keys, unexpected services, and connections to unknown external infrastructure.

Administrators should also review whether the FortiSandbox appliance initiated connections to internal systems that it does not normally access. A compromised appliance may be used as a pivot point because traffic from a security system is often trusted more readily than traffic from an ordinary endpoint. Trust based only on the device’s function is how internal networks gradually become collections of optimistic assumptions.

Credentials stored on or accessible to the appliance should be considered at risk where compromise is suspected. This may include administrator passwords, API tokens, integration credentials, service-account secrets, SSH keys, certificates, and authentication information used to communicate with firewalls, email security systems, SIEM platforms, or file repositories. Such credentials should be rotated from a separate trusted system.

Organizations should restrict access to FortiSandbox administrative and API interfaces. These interfaces should not be directly exposed to the public internet unless there is an unavoidable operational requirement. Management access should be limited to trusted administrative networks, VPN users, or tightly controlled jump hosts, with multi-factor authentication and source-IP restrictions wherever supported.

Network segmentation is equally important. A sandbox should be able to analyse malicious content without receiving unrestricted access to production servers, directory services, backup systems, databases, and management infrastructure. Integrations should use dedicated, minimally privileged service accounts, and communication should be permitted only to explicitly required destinations and ports.

Security teams should also monitor the integrity of sandbox results and configurations. Unexpected changes to analysis policies, allowlists, detection settings, update sources, file-retention rules, or integration endpoints may indicate that an attacker is attempting to weaken detection or redirect information.

A compromised sandbox may contain sensitive material submitted for analysis, including confidential documents, suspected malware samples, email attachments, internal URLs, scripts, and customer data. Organizations should therefore consider whether an attacker could have accessed or exfiltrated files stored in analysis queues, reports, or retained sample repositories.

Where compromise cannot be ruled out, merely upgrading the appliance may be insufficient. Organizations should follow incident-response procedures, preserve relevant logs and forensic evidence, isolate the affected instance, and consider rebuilding it from a verified image. Restoring an appliance from an untrusted backup can faithfully reproduce the attacker’s persistence, which is efficient in precisely the wrong direction.

The incident also highlights a larger architectural lesson: security products must not be assumed to be inherently secure merely because they provide security functions. Firewalls, sandboxes, management servers, VPN gateways, and endpoint consoles are high-value targets because they occupy trusted positions and often possess extensive visibility and privileges.

These systems require the same, and often greater, protection than ordinary servers. They should be continuously patched, isolated, monitored, backed up securely, and included in vulnerability assessment and incident-response programmes. Administrative interfaces should be treated as sensitive applications rather than convenient web pages placed on every reachable network.

For customers, the key takeaway is that active exploitation of FortiSandbox vulnerabilities is not simply a Fortinet maintenance issue. It represents a potential compromise of a central security-control point. Organizations must update affected systems immediately, investigate vulnerable deployments for prior exploitation, restrict management exposure, rotate potentially exposed credentials, and monitor for abnormal behaviour across both the appliance and the surrounding network.

The uncomfortable lesson is straightforward: attackers increasingly target the tools responsible for detecting them. Once a trusted security platform is compromised, it can become a powerful hiding place, intelligence source, and launch point. Effective defence therefore requires not only deploying security appliances, but also continuously securing, validating, and monitoring the security appliances themselves.

Bad actors are exploiting multiple security vulnerabilities in Fortinet FortiSandbox, according to threat intelligence firm Defused Cyber. In a post shared on X, the company said it has observed exploitation of CVE-2026-39813, CVE-2026-39808, and CVE-2026-25089 over the past 24 hours. CVE-2026-39813 (CVSS score: 9.1) refers to a path traversal vulnerability in FortiSandbox JRPC API that could

Source: Attackers Exploit Three Fortinet FortiSandbox Flaws, One Patched Last Week via The Hacker News — published 16 Jun 2026.