The United States' Cybersecurity and Infrastructure Security Agency has told federal agencies to patch two flaws in Fortinet's FortiSandbox by Sunday 19 July — three days' notice — because they are already being exploited in the wild. That deadline binds US government bodies, not you. The reason to care anyway is the product involved.
FortiSandbox is a security appliance. Its entire job is to take suspicious files, detonate them in a controlled environment, and tell you whether they are malware. It is a box you buy to catch attackers. And it is now the way in. There is a bleak, recurring joke running through the last few years of this industry, and this is the latest telling of it: the equipment sold to defend the perimeter has become the softest part of it.
What is actually wrong
Two vulnerabilities are being actively exploited, and both are about as bad as the scoring gets.
- CVE-2026-39808 — CVSS 9.1, critical. An operating-system command-injection flaw that lets an unauthenticated attacker run commands on the appliance by sending specially crafted HTTP requests. It affects FortiSandbox versions 4.4.0 to 4.4.8, and is fixed in 4.4.9.
- CVE-2026-25089 — CVSS 9.1, critical. The same class of flaw — unauthenticated OS command injection via crafted HTTP requests — but with wider reach: it affects the 4.2 versions, 4.4.0 to 4.4.8, and 5.0.0 to 5.0.5, including the Cloud and PaaS variants. It is fixed in 4.4.9 and 5.0.6.
A third flaw, CVE-2026-39813, was reported alongside these but has no recorded exploitation yet; the two above are the ones on fire.
Strip out the jargon and the danger is in three words: unauthenticated, network, code execution. Command injection means the attacker gets the appliance to run their commands as if they were its own — because the software failed to separate user input from system instructions. "Unauthenticated" means they need no password, no account, nothing. "Via HTTP requests" means they need only be able to reach the box over the network. No user has to click anything. No credential has to be phished. If the management interface is reachable and unpatched, that is the whole attack. CISA rates the complexity as low, which is a polite way of saying this is not hard to do.
And this is not a device you want an attacker inside. A malware sandbox sits deep in the trust model — it handles hostile files by design, it is often connected to email and network-inspection pipelines, and it is trusted by everything around it. Owning it is a foothold with a view.
Why "patch by Sunday"
The mechanism behind the deadline is worth understanding, because it is the most useful free tool in vulnerability management and most organisations underuse it.
CISA maintains the Known Exploited Vulnerabilities catalogue — the KEV. It is not a list of scary-sounding bugs. It is the shorter, far more important list of vulnerabilities that are actually being exploited in the wild, right now. When something lands on the KEV, CISA's Binding Operational Directive obliges US federal agencies to fix it within a set window — here, an unusually short one. These two FortiSandbox flaws were added on 16 July with a 19 July deadline.
Here is the part that matters for everyone who is not a US federal agency, which is most of my readers. The KEV is the best patch-prioritisation feed in existence, and it is free. I argued in my write-up of this month's 622-CVE Patch Tuesday that the headline vulnerability count is noise and the only figure that matters is the short list of what is being exploited. The KEV is that short list, maintained by people with visibility you do not have, published for nothing. If you do one thing to modernise your patching, subscribe to it and treat everything on it as a drop-everything item — regardless of which government you answer to. An attacker exploiting FortiSandbox does not check your jurisdiction first.
The pattern: your security kit is the target
Step back from this specific box, because the more important story is the pattern it belongs to.
For several years now, the devices most reliably turning up in exploitation reports have not been obscure servers. They have been security and edge appliances — VPN gateways, firewalls, secure email gateways, and now malware sandboxes. Fortinet has had a run of these. So has Ivanti. So have others. It is not bad luck, it is structural, and the reasons are worth spelling out because they tell you where to look in your own estate:
These appliances are internet-facing by design — they have to be reachable to do their job. They run large, complex codebases with a lot of attack surface. They are trusted deeply inside the network, so compromising one pays off enormously. And they are operationally forgotten — bought, racked, and left alone between annual renewals, patched less diligently than the servers everyone thinks of as "IT," because they feel like appliances rather than computers. They are computers. They are, in fact, some of the most exposed and most valuable computers you own.
The sandbox is the darkly funny end of this. A device whose entire purpose is to safely handle things that are trying to attack you, turned into the thing attacking you. But it is the same underlying failure as every VPN and firewall bug before it, and it will not be the last.
What to actually do
The immediate response is simple and the strategic one is duller, and you need both.
- Find out whether you run FortiSandbox at all. You cannot patch what you do not know you own, and security appliances are exactly the kind of thing that gets bought by one team and forgotten by the rest. This is the inventory question I keep coming back to, and it is the first control every time.
- If you do, check your version and patch it now — to 4.4.9 or 5.0.6. This is a "before the weekend" job for everyone, not just US federal agencies, because the flaws are already being exploited. The gap between a patch being available and you applying it is exactly the window attackers are racing you through right now.
- Get the management interface off the internet. The single most durable fix here is not this patch, it is ensuring the administrative and HTTP interfaces of your security appliances are never exposed to the open internet in the first place. If yours is, that is the finding — and closing it protects you against the next FortiSandbox bug too, whichever appliance it lands in.
- Assume it may already have been used. These are unauthenticated remote code execution flaws that have been exploited in the wild. If you were internet-exposed and unpatched, patching closes the door but does not tell you whether someone already walked through it. Treat an exposed, unpatched box as suspect: hunt for signs of compromise, do not just install the update and move on.
- Wire the KEV into your process. Make "is it on the KEV?" the first question your patch triage asks. It is the cheapest, highest-quality threat intelligence available, and it costs nothing but the discipline to watch it.
The tidy version and the real one
The tidy version of this story is a to-do: patch FortiSandbox to 4.4.9 or 5.0.6 before Sunday, and check whether you were exposed in the meantime.
The real version is a posture. Stop treating security appliances as set-and-forget infrastructure. They are internet-facing, deeply trusted, complex, and squarely in the crosshairs — which makes them some of the highest-priority boxes in your estate to inventory, patch, and wall off from the open internet. The vendor's next critical vulnerability in one of these devices is not a possibility to insure against; it is a certainty to prepare for. FortiSandbox is this week's. There will be another, and the organisations that handle it calmly will be the ones who already know what appliances they own, already keep the management planes off the internet, and already treat the KEV as their to-do list rather than a newsletter they skim.