On Tuesday, warnings about active exploitation of patched FortiSandbox vulnerabilities turned a routine Fortinet update cycle into a live exposure problem, because the flaws being probed sit inside a product designed to inspect hostile files and threats, according to SecurityWeek.
The timing matters. Defused says its honeypots have seen exploit attempts against CVE-2026-39808, CVE-2026-39813, and CVE-2026-25089. BleepingComputer reports that Fortinet released security updates for all three flaws on April 14. That means defenders are not dealing with mystery bugs. They’re dealing with the familiar gap between a patch existing and a vulnerable appliance actually being fixed.
June exploit activity turns FortiSandbox patching into an active incident question
Fortinet FortiSandbox is used to analyze suspicious content, including malware and zero-day threats. That role makes the current exploitation reports more sensitive than a narrow software bug bulletin. If attackers can reach a security appliance that handles hostile material and sits close to security workflows, the operational question changes fast: is the appliance patched, isolated, and watched, or is it just assumed to be safe because it’s a security product?
The three FortiSandbox vulnerabilities now in hacker crosshairs are different enough that security teams should not treat them as one generic “critical patch” item.
| Vulnerability | Patch timing reported | Reported issue | Why attackers care |
|---|---|---|---|
| CVE-2026-39813 | Security updates reported April 14 | Authentication bypass | Can let an attacker get past a core access control barrier |
| CVE-2026-39808 | Security updates reported April 14 | OS command injection | Can be exploited to execute arbitrary code or commands |
| CVE-2026-25089 | Security updates reported April 14 | Remote command execution | Allows a remote, unauthenticated attacker to execute arbitrary commands on vulnerable appliances |
CVE-2026-39808 was independently observed by KEVIntel on June 12. Both Defused and KEVIntel reported attacks targeting CVE-2026-39813 on June 15. Defused also said the exploit for CVE-2026-25089 appeared to have been created using AI and did not work when the company first observed it.
That last detail should not comfort anyone. XOOMAR analysis: a failed exploit attempt still signals attacker interest, and attacker interest around a recently patched remote command execution flaw can turn quickly once working code improves or spreads.
“We are observing exploitation of multiple Fortinet FortiSandbox vulnerabilities during the past 24 hours, including: CVE-2026-39813 (no previous recorded exploitation), CVE-2026-39808, CVE-2026-25089 (vibecoded, likely faulty exploit),” Defused warned, according to related reporting cited in the supplied material.
The practical move is not just “patch FortiSandbox.” Teams need to verify exact affected versions, confirm upgrade status, check whether management interfaces are reachable, review logs around the reported dates, and look for signs of successful command execution or authentication bypass attempts.
FortiSandbox patches did not close the window for every exposed appliance
A patch date is not a risk end date. It’s the start of a race.
For CVE-2026-39813, CVE-2026-39808, and CVE-2026-25089, Fortinet has released security updates, with BleepingComputer reporting an April 14 release date for all three. The exploitation reports now suggest attackers are testing whether organizations actually moved.
Security teams should separate four questions that often get blurred:
- Version status: Is every FortiSandbox instance on a fixed release?
- Exposure: Can attackers reach the appliance or its management plane from untrusted networks?
- Evidence: Are there logs showing exploit attempts or suspicious command execution?
- Containment: If compromise occurred, what credentials, connections, or adjacent systems may be affected?
That discipline matters beyond this one product. We’ve seen similar asset and credential visibility problems in other security contexts, including XOOMAR’s coverage of how Active Directory pentesting tools expose hidden AD risk. The common thread is not the technology. It’s whether defenders know what exists, who owns it, and how fast they can prove its state.
For FortiSandbox specifically, the highest priority is simple: find every instance, patch it, restrict access, and review activity from at least the dates tied to reported exploitation.
SOCRadar’s 30,000 firewall finding shows attackers are getting real logins, not just banners
The FortiSandbox exploitation reports landed alongside a separate but more quantitative warning: SOCRadar says it detected more than 30,000 compromised Fortinet firewalls exposing corporate networks to hacking.
SecurityWeek reports that the campaign has been dubbed FortiBleed. SOCRadar says a threat actor has been systematically hacking Fortinet firewalls and VPN gateways, then compiling a database of verified credentials that can be used to access them. The compromised systems reportedly belong to companies and government organizations in more than 190 countries, with many devices located in India and the United States.
SOCRadar’s description is blunt:
“The attackers scan the internet for Fortinet devices, try a curated list of known passwords against each one, and record every successful login,” SOCRadar explained. “Once a device is compromised, they use it as a listening post, monitoring traffic passing through and collecting any additional credentials that flow by. Those freshly collected passwords are then fed back into the scanner to compromise even more devices. The system feeds itself.”
That is the pressure point in this story. The FortiSandbox activity involves exploitation attempts against patched vulnerabilities. FortiBleed, separately, involves compromised Fortinet firewalls and VPN gateways with usable credentials. Together, they show two routes attackers are taking against Fortinet environments: exploit vulnerable appliances, or log in where credentials already work.
SOCRadar also said the threat actor left its server exposed, allowing researchers to collect data on infrastructure and targets. Among the recovered data were credentials for what appeared to be a defense industry VPN endpoint. SOCRadar has not attributed the activity to a known group, but believes the hackers are likely Russian speakers.
For defenders, the internal metrics should be concrete:
- Assets: Count every Fortinet firewall, VPN gateway, and FortiSandbox instance.
- Firmware: Track current versions and patch age.
- Access: Identify exposed admin interfaces.
- Identity: Rotate credentials where compromise is suspected.
- Telemetry: Review suspicious logins, unusual outbound connections, and unexplained configuration changes.
Credential exposure is not a side issue here. It is central to the FortiBleed workflow described by SOCRadar. For a separate example of how stolen secrets can become the attack path, see XOOMAR’s report on 70,000 installs exposing JetBrains plugins’ AI API key heist.
Fortinet’s next decision point is proof, not promises
Defused recently also saw exploitation of two Fortinet FortiClient EMS vulnerabilities, tracked as CVE-2026-21643 and CVE-2026-35616. Related reporting also notes that Fortinet security flaws are often exploited in ransomware attacks and cyber espionage campaigns, including as zero-day bugs.
That context should shape how CISOs handle the FortiSandbox patch race. A vendor bulletin is not enough. Security leaders need evidence: which appliances were vulnerable, when they were patched, whether they were reachable, what logs show, and whether any credentials touched by those systems need rotation.
Admins need the same thing in operational form. Not a vague mandate to “secure Fortinet.” They need affected-version lists, maintenance windows, rollback plans, indicators of compromise, and clear ownership for every Fortinet asset.
XOOMAR analysis: the useful framing is not “Fortinet has another vulnerability problem.” The sharper lesson is that security infrastructure now needs the same inventory rigor, credential hygiene, and monitoring discipline as the systems it protects. That conclusion is grounded in the source material: attackers are probing patched FortiSandbox flaws, while a separate campaign has already amassed verified Fortinet credentials at scale.
The next Fortinet advisory should not trigger a scramble
The immediate path is narrow and urgent: confirm whether any FortiSandbox vulnerabilities apply, install Fortinet’s fixes, restrict management access, rotate credentials where exposure is possible, and review logs around June 12 and June 15 for the activity reported by KEVIntel and Defused.
The next phase is harder. Teams should be able to answer, before the next advisory lands, which Fortinet appliances are internet-facing, which versions they run, who owns them, and how quickly they can be patched without improvisation.
Evidence that would confirm the risk is escalating would include working public exploit code for CVE-2026-25089, more sightings from independent exploit intelligence firms, or customer impact details tied to the FortiSandbox flaws. Evidence that would weaken the thesis would be limited exploitation telemetry, rapid patch adoption, and no confirmed post-exploitation activity.
Until then, the safest assumption is simple: if a Fortinet appliance is exposed, attackers are already checking whether it can be turned into access.
Impact Analysis
- Attackers are targeting FortiSandbox flaws after patches were already released, raising urgency for delayed updates.
- FortiSandbox handles suspicious files and malware, making compromise of the appliance especially sensitive.
- The activity highlights the risk gap between vendor fixes being available and exposed security infrastructure actually being patched.
Originally published on XOOMAR. For more news and analysis, visit XOOMAR.
Top comments (0)