Skip to content
feed: live
>_ 0dayNews
fortinet
● Breaking

FortiSandbox: two 9.8 unauth RCEs hit KEV, Sunday deadline

CISA added CVE-2026-39808 and CVE-2026-25089 to KEV today — unauthenticated OS command injection in Fortinet FortiSandbox, CVSS 9.8 each, federal BOD 26-04 deadline this Sunday.

FortiSandbox: two 9.8 unauth RCEs hit KEV, Sunday deadline
Photo: Albert Stoynov / Unsplash · Unsplash License
fuse Marisol "Fuse" Delgado · Published · 5 min read

CISA added CVE-2026-39808 and CVE-2026-25089 to the Known Exploited Vulnerabilities catalog today, 2026-07-16 — both unauthenticated OS command injection bugs in Fortinet FortiSandbox, CVSS 9.8 each, exploited via crafted HTTP requests to the appliance. The federal remediation deadline under BOD 26-04 is 2026-07-19 — this Sunday, three days out. FortiSandbox is the box you send suspicious files to for detonation and verdicts; a taken-over one is not a workstation problem, it is an internal SOC-tooling problem.

What actually changed

Two separate CVEs, both classified CWE-78 (OS command injection), both scored CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — network-reachable, no auth, no user interaction, full confidentiality/integrity/availability impact. Fortinet’s PSIRT bulletins are FG-IR-26-100 for CVE-2026-39808 and FG-IR-26-141 for CVE-2026-25089; the primary references on the KEV entries point to each PSIRT record plus the corresponding NVD entry.

The affected version envelopes are different, so don’t treat these as a single bug:

  • CVE-2026-39808 — FortiSandbox 4.4.0 through 4.4.8, plus a spread of FortiSandbox PaaS builds (23.4.4374, 23.4.4350, 23.3.4329, 23.1.4245, 22.2.4151, 22.2.4134, 22.1.4113, 21.4.4072, 21.3.4055). Published to NVD on 2026-04-14 — this one has been sitting in the queue for three months with a public research reference before CISA moved it onto KEV today. That is usually the tell that mass exploitation started and someone measured it.
  • CVE-2026-25089 — a broader footprint: FortiSandbox 4.2.0–4.2.8, 4.4.0–4.4.8, 5.0.0–5.0.5, plus FortiSandbox Cloud 5.0.4–5.0.5 and FortiSandbox PaaS 5.0.4–5.0.5. Same class of bug, wider blast radius, PaaS and Cloud tenants included.

Both fixes ship in a later minor release on each branch — pin the exact fixed build against FG-IR-26-100 / FG-IR-26-141 rather than trusting a version number from a third-party writeup, because the two advisories don’t have identical fixed-build tables.

Why “it’s just the sandbox” is the wrong frame

FortiSandbox is deployed inside the network by design — it needs to be, because it exists to explode suspect files fed to it by FortiGate, FortiMail, FortiWeb, EDR agents, and SOC analysts. Its management interface commonly speaks to FortiManager and FortiAnalyzer. It holds samples of your actual attacker traffic, sometimes with source metadata that identifies where in the environment the sample came from. An unauthenticated attacker who lands OS command execution on it inherits a machine that is trusted by the rest of your security fabric and stores a curated library of what you have already seen. That is not a peripheral appliance.

The two unknowns worth naming honestly:

  • Ransomware use is listed “Unknown” on both KEV entries. That is not “no” — it is CISA saying they haven’t been given telemetry to categorize it either way. Don’t wait for that field to flip before you patch.
  • CVE-2026-39808 has a public research/PoC reference on its NVD record. I’m not linking it and I’m not describing it — the point of this piece is to move the patch, not to hand anyone the fuel. But operationally you should assume opportunistic scanning is already normal on the 4.4 branch and rising on the 5.0 branch since today’s KEV listing.

What to actually do

The honest timeline is patched by Friday, verified by Sunday — not “next maintenance window” and not “when the change-advisory board next sits.” Federal civilian agencies are on the BOD 26-04 clock. Everyone else should treat the KEV listing as the same signal — active exploitation is generally why CVEs land there, and the scanning volume on a KEV entry does not decline.

  1. Inventory every FortiSandbox surface, including PaaS and Cloud. On-prem 4.2, 4.4, and 5.0 appliances are in the direct affected envelope for at least one of the two CVEs; FortiSandbox Cloud 5.0.4–5.0.5 and FortiSandbox PaaS across the 21.x–23.x range are affected by one or both. Don’t skip the PaaS side because “it’s SaaS” — the affected build list on CVE-2026-39808 explicitly names PaaS versions Fortinet ships in the multi-tenant service.
  2. Upgrade to the fixed release on each branch per the PSIRT advisories. For 4.4-line boxes, both CVEs converge on the same fixed build — one upgrade closes both. For 4.2 and 5.0 lines, only CVE-2026-25089 applies but it still requires a version bump. Confirm the exact target build against FG-IR-26-100 and FG-IR-26-141 directly, not a third-party summary, because the fixed-build tables between the two advisories differ.
  3. Restrict the FortiSandbox management interface until the upgrade lands. The HTTP path is the vector on both CVEs. If patching has to slip past Sunday, allowlist the management interface to the specific FortiManager, FortiAnalyzer, and SOC-workstation source IPs that actually need it — anything reachable from a broader internal segment is one crafted request away from RCE. This is a stopgap, not a fix.
  4. Assume compromise if the appliance has been reachable from an untrusted segment on an unpatched build. Pull the FortiSandbox event and audit logs for the last 90 days on 4.4-line boxes (39808 has been on NVD since April) and for the standard exposure window on 4.2 and 5.0 boxes. Look for unexpected outbound connections from the appliance, unexpected admin or service accounts, and unexpected sample-export or configuration-export activity. Correlate with FortiAnalyzer’s view of the same box. If anything is off, treat it as compromise and rebuild rather than clean, because command execution on the sandbox controller means the persistence surface is the whole appliance.
  5. Rotate the credentials FortiSandbox holds for the rest of the fabric. The API keys and service accounts the sandbox uses to talk to FortiManager, FortiAnalyzer, FortiGate, and ticketing/SOAR integrations should be rotated after the upgrade if the appliance was ever reachable from an untrusted segment on a vulnerable build. This is the same discipline you’d apply to a taken-over jump host — the credentials it holds outlive the RCE window.

Priority call

Patch this ahead of most of the rest of the backlog if FortiSandbox is in your footprint. It ranks alongside the Oracle EBS Payments 9.8 CISA added yesterday — same “unauth over HTTP, KEV as of this week, deadline before Monday” pattern, different blast radius. It ranks above the SonicWall SMA1000 pair from Monday only for shops that actually run FortiSandbox — if you run both, the SMA1000 hotfix is more urgent because that’s the appliance sitting on the edge; if you only run FortiSandbox, this is your fire this week.

The through-line across all three: security appliances are where the exploitation heat is right now, and CISA is compressing the deadline windows to match. Sunday for FortiSandbox, Saturday for Oracle EBS, Friday for SonicWall SMA1000. Plan the change windows accordingly and don’t defer any of them into next week’s cycle.

Track future Fortinet PSIRT advisories and KEV additions at /topics/fortinet/.

Sourcing

Related CVEs
  • [ CRITICAL ] CVE-2026-39808 Fortinet FortiSandbox unauthenticated OS command injection (4.4 branch and PaaS)
  • [ CRITICAL ] CVE-2026-25089 Fortinet FortiSandbox unauthenticated OS command injection (4.2, 4.4, 5.0, Cloud, PaaS)

Found this useful? Share it.