Hackers Pounce on Fortinet FortiSandbox Bugs After Patches

If all three critical FortiSandbox vulnerabilities now have fixes, how many vulnerable deployments were still exposed when exploitation began over the weekend?

Unknown attackers are actively targeting three Fortinet FortiSandbox flaws that can let remote attackers bypass authentication, escalate privileges, and run malicious code, according to The Register Security. Fortinet patched two of the bugs in April and the third last week, but threat intelligence firm Defused says exploitation is now underway.

Which FortiSandbox vulnerabilities are being exploited now?

The three bugs are CVE-2026-39813, CVE-2026-39808, and CVE-2026-25089. All carry 9.1 CVSS ratings. Fortinet said at patch time that it had no reports of active exploitation, according to the source material, but Defused now says attackers are hitting them.

“We are observing exploitation of multiple Fortinet FortiSandbox vulnerabilities during the past 24 hours,” Defused said in a LinkedIn post on Monday.

Defused said exploitation began over the weekend. SecurityWeek also reported that Defused honeypots saw attempts against all three CVEs, and that KEVIntel independently observed exploitation of CVE-2026-39808 on June 12 and attacks targeting CVE-2026-39813 on June 15.

Here is the patch map security teams need first:

Fortinet credited Loic Pantano, a Fortinet security analyst, with finding CVE-2026-39813. It credited KPMG Spain researcher Samuel de Lucas Maroto with finding and reporting CVE-2026-39808.

Why do these FortiSandbox bugs demand faster patching than routine CVEs?

The short answer: the flaws are critical, remote, and now observed in the wild.

A sandbox product is part of a security team’s defensive machinery. FortiSandbox is used for analyzing suspicious files and behavior, so a critical bug in that layer is not just another appliance maintenance item. XOOMAR analysis: when a flaw allows unauthenticated command execution or authentication bypass, the practical response window shrinks because attackers don’t need valid credentials to start probing vulnerable systems.

The hardest part for defenders is the attacker profile. The source material does not identify who is exploiting the bugs, how many targets have been hit, or whether successful compromise has been confirmed beyond exploit attempts. That matters because motive and target selection remain opaque.

Defused also flagged an unusual detail on CVE-2026-25089.

“Per our research a working exploit for CVE-2026-25089 has not yet been publicly disclosed,” Defused said.

The firm added that the exploit for that flaw appeared to be “vibe coded” and may be faulty. In this context, that means it appeared to be generated with AI-assisted coding from prompts rather than carefully built by hand. That does not make it harmless. Broken exploit code can still improve quickly once attackers test it against real targets.

For readers tracking the Fortinet patch cycle, XOOMAR’s related FortiSandbox coverage, Hackers Pounce on FortiSandbox Vulnerabilities After Fixes, is a useful companion to this update.

Which Fortinet versions should security teams check first?

Start with version inventory. The affected ranges are specific, and that makes the first decision simple: any FortiSandbox 4.4.0 through 4.4.8 should be treated as exposed until upgraded. The same applies to FortiSandbox 5.0.0 through 5.0.5 for the flaws that affect the 5.0 branch.

Security teams using FortiSandbox Cloud 5.0.4 through 5.0.5 or FortiSandbox PaaS 5.0.4 through 5.0.5 also need to confirm they are on fixed versions for CVE-2026-25089.

The immediate checklist is narrow:

• Inventory: Identify every FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS deployment.
• Compare: Match versions against the affected ranges above.
• Upgrade: Move to 4.4.9+, 5.0.6+, or the relevant fixed version.
• Verify: Confirm the appliance actually reports the patched version after maintenance.
• Review: Check Fortinet advisories and threat intelligence updates for any new indicators or mitigation notes.

XOOMAR analysis: because Defused and KEVIntel observed exploitation after patches were available, patch status alone should not be the final step for systems that were vulnerable over the weekend. Teams should review relevant access logs, administrative events, network connections, and recent configuration changes for activity around the reported observation dates.

Fortinet did not respond to The Register’s inquiries about the three CVEs or whether the vendor had also observed attacks. That leaves defenders dependent on public advisories and outside threat intelligence for now.

How much will remain unknown after the patches are installed?

A lot. Patching closes the known holes, but it does not answer whether attackers landed on any exposed systems before upgrades were completed.

The Register also pointed to a separate warning earlier this month from Check Point VP of research Lotem Finkelstein, who said ransomware criminals had exploited a critical authentication bypass affecting Fortinet Remote Access VPN and Mobile Access deployments, and that the same crew was likely abusing other VPN-related Fortinet vulnerabilities. For broader VPN exposure context, see XOOMAR’s explainer on how VPN split tunneling can leak more than you expect online.

The next pressure point is CVE-2026-25089. Defused says a working public exploit was not yet disclosed, and the observed exploit may be faulty. If that changes, unpatched systems move from theoretical exposure to a much more crowded target list.

For Fortinet customers, the practical takeaway is blunt: upgrade first, verify second, investigate third. Then keep watching Fortinet notices, Defused updates, and other threat intelligence feeds for signs that today’s exploit attempts have turned into confirmed compromises.

Impact Analysis

• All three flaws are critical and are now being targeted despite patches already being available.
• The bugs can enable authentication bypass, privilege escalation, and malicious code execution against FortiSandbox deployments.
• Security teams need to verify upgrades quickly because exploitation began shortly after the latest fix was released.