📢 New post: The Same Appliance, Twice: FortiSandbox CVE-2026-25089 and the Boundary You Don't Operate · 📝 Also fresh: The Light Switch Is on the KEV List: CVE-2023-4346 and Whether Your Building Is in the Boundary · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonCISACompliance

The Same Appliance, Twice: FortiSandbox CVE-2026-25089 and the Boundary You Don't Operate

Yesterday we wrote about CVE-2026-39808, an unauthenticated OS command injection in Fortinet FortiSandbox that CISA added to the Known Exploited Vulnerabilities catalog on July 16. Worth saying plainly: it wasn't the only one. The same catalog release — version 2026.07.16 — carried two FortiSandbox command injections. CVE-2026-39808 and CVE-2026-25089. Same product, same CWE-78 weakness class, same day added, same July 19 federal due date, two different Fortinet advisories (FG-IR-26-100 and FG-IR-26-141 respectively).

That matters more than it might sound, because the natural instinct after reading about the first one is to check your FortiSandbox fleet, confirm the version, and consider the box closed. On this batch, that instinct leaves you half done.

The version math is different, and wider

CVE-2026-39808's affected range was the 4.4 appliance line and a band of older PaaS builds. CVE-2026-25089 reaches further. Per Fortinet's advisory:

Product Affected Fixed
FortiSandbox 5.0 5.0.0 – 5.0.5 5.0.6 or above
FortiSandbox 4.4 4.4.0 – 4.4.8 4.4.9 or above
FortiSandbox Cloud 5.0 5.0.4 – 5.0.5 5.0.6 or above
FortiSandbox PaaS 5.0 5.0.4 – 5.0.5 5.0.6 or above

Fortinet lists FortiSandbox 5.2, Cloud 5.2 and 4.4, and PaaS 23.4, 5.2 and 4.4 as not affected. One loose end worth flagging rather than papering over: NVD's record also lists FortiSandbox 4.2 (all versions) as affected, and the vendor advisory's solution table has no 4.2 row. If you're running 4.2, that discrepancy is a question for Fortinet support, not something to resolve from a blog post.

On severity, the two sources don't agree either. NVD has completed its analysis and scores it 9.8 (CVSS 3.1) with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Fortinet's own advisory scores it 9.1. Both are critical, the remediation is identical either way, and the KEV due date doesn't move based on which number you prefer — but if your ConMon tooling ingests one feed and your risk register quotes the other, expect to explain the gap to an assessor eventually. Better to record both with their sources than to quietly pick one.

The mechanism has a nice specificity to it. Fortinet titles the advisory "second-order OS command injection via JSON input on start vnc feature" — the injected input isn't executed where it enters, it's stored and then executed later when a different feature consumes it. Second-order bugs are the ones that survive input validation reviews, because the place you'd look for the sanitizer and the place the shell actually runs are different parts of the codebase.

The reframe: whose boundary is it?

The first FortiSandbox post asked whether the appliance was drawn inside your authorization boundary at all — the security tool that protects the system, quietly living just off the edge of the diagram. This CVE asks a harder version of that question, because of one detail in the KEV entry: CISA's description for CVE-2026-25089 explicitly names FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS. The description for CVE-2026-39808 names only FortiSandbox.

Cloud and PaaS are the variants you don't operate. And a vulnerability in a component someone else runs isn't a patch ticket — it's an inheritance question:

  • If it's an appliance you run, this is the familiar path. Find it, pin the build, upgrade to 4.4.9 or 5.0.6, keep the evidence. Your clock, your change record, your POA&M if you slip.
  • If it's FortiSandbox Cloud or PaaS, you are not the one applying 5.0.6 — Fortinet is. Your obligations become different work entirely: confirm with the vendor that your tenant has been remediated and get that in writing, record it as inherited remediation with a date and a source, and check whether that service was ever documented as a leveraged service in your SSP in the first place. The KEV required action anticipates exactly this, pointing at BOD 26-04's guidance for cloud services, or discontinuing use where mitigations aren't available.
  • If you genuinely don't know which you're running, that's the finding. "We have FortiSandbox" is not an inventory answer when the delivery model determines who owns the remediation.

The uncomfortable middle case is the common one: a team patches the appliances, marks the CVE remediated, and never notices the PaaS tenant that a different group stood up — because it never felt like infrastructure, it felt like a subscription. A vendor-operated component inside your boundary is still inside your boundary. You just can't fix it yourself, which means the evidence you owe is a vendor attestation rather than a change ticket, and that's the artifact nobody remembers to collect.

What the work actually is this week

The KEV-clock mechanics are the ones we've walked through before: the catalog entry inherits a federal due date that overrides your comfortable 30/90/180-day ConMon windows. July 19 is the date, and it's the date for both CVEs. Concretely:

  • Treat this as two remediations, not one. Different advisories, different affected ranges, different fixed builds. Closing 39808 does not close 25089, and a ConMon record that conflates them will read as a gap later.
  • Enumerate by delivery model, not just by version. For every FortiSandbox in the estate, record appliance vs. Cloud vs. PaaS alongside the build. That field is what determines who owes the fix.
  • Chase the vendor attestation for anything you don't operate. Date, tenant, version confirmed remediated, who said so. Ask now — it takes longer than the patch does, and the clock doesn't pause for a support ticket.
  • Reconcile the score discrepancy in your own records. Note 9.8 (NVD) and 9.1 (Fortinet CNA) with sources rather than picking one silently.
  • Assume access, then look. KEV listing means confirmed exploitation, and CISA's required action points at the forensics triage guidance under BOD 26-04. CISA currently marks known ransomware campaign use as unknown for this CVE — which is not the same as "no," and isn't a reason to skip the look.

What we keep coming back to

Every few weeks the KEV item is a different product, and the lesson underneath refuses to change: know what you run before you're asked to account for it under a clock. This pair just adds a wrinkle worth carrying forward — knowing what you run includes knowing how you consume it. The same product name, delivered three ways, splits into three different remediation obligations and three different piles of evidence.

That's the shape of work the Novaprospect audit engine is built toward: discovery that records not just the component and its version but the delivery model and the boundary answer attached to it, so an inherited control is visible as an inherited control before a due date makes it urgent. When two CVEs land on the same appliance on the same day with a three-day clock, the question worth being able to answer from a query is not just what version are we on — it's and which of these do we actually control?

Reference