A exposure of resource to wrong sphere vulnerability in Fortinet FortiSandbox 5

CVE-2026-59835 is an Exposure of Resource to Wrong Sphere flaw (CWE-668) in FortiSandbox 5.0.0–5.0.2 and 4.4.3–4.4.8. The scanning VMs that FortiSandbox uses to detonate suspicious files expose a VNC server that is reachable from the appliance's network-facing interface without authentication. An attacker who can talk to the appliance over the network can attach to the VNC console of the detonation VMs, read what's being analyzed, and interact with the guest desktop. FortiSandbox PaaS deployments are not impacted; the flaw is specific to on-prem appliances including FSA-500G and FSA-1500G. Fortinet published FG-IR-26-145 on 2026-07-14.

Fortinet rates this HIGH (8.6). Our read: 7.7 is the more defensible CVSS (matches the public write-ups), but the severity bucket is right. FortiSandbox is a security-plane appliance that ingests live malware samples — anyone reading the sandbox's screen is reading detections in flight, potentially harvesting attacker TTPs, unreleased IOCs, or sensitive files submitted for analysis. The 'wrong sphere' here is the *malware analysis sphere* leaking into the corporate LAN. HIGH is fair, not inflated.

Why this verdict

• Unauthenticated + network-reachable + no UI: the trigger is a stock VNC client, no exploit development required.
• Role multiplier — FortiSandbox is a security-analysis appliance: the chain succeeds against 100% of on-prem installs on affected firmware; blast radius is disclosure of every detonation job (malware samples, submitted files, IOCs, IR context). This is the canonical high-value-role case — floor is HIGH.
• Friction downward pressure — not internet-facing: typical deployments place FortiSandbox on internal security VLANs. That limits the attacker population to *post-initial-access* actors, which is why we don't push to CRITICAL.
• No auth, no crypto: VNC RFB with None auth means any attacker with a TCP path reads the screen — there is no interim mitigation short of an ACL.

Why not higher?

Not CRITICAL because FortiSandbox is not typically exposed to the internet, so the attacker must already have a foothold on the security or management segment. Impact is scoped to intelligence disclosure and interaction with ephemeral guest VMs — not appliance root, not fleet takeover, not identity compromise. No active exploitation observed.

Why not lower?

Not MEDIUM because the deployment role is a security-plane appliance handling live malware and IR data, the flaw needs no credentials once reachable, and Fortinet's own severity is 8.6. Any attacker who reaches the security VLAN — a common post-phish reality — gets a live window into detections.

1. ACL FortiSandbox management/data interfaces to a named admin bastion — Block TCP 5900–5910 (and ideally everything except required FortiGate/FortiAnalyzer sync ports) from all sources except the SOC bastion. Push via upstream FortiGate policy or L3 switch ACL within 30 days (noisgate HIGH mitigation SLA).
2. Upgrade to FortiSandbox 5.0.3+ or 4.4.9+ — Apply the vendor fix from FG-IR-26-145. Schedule within the 180-day noisgate HIGH remediation SLA; sooner if your sandbox handles regulated data or your security VLAN is not tightly segmented.
3. Alert on inbound VNC handshake to any security appliance — Add a Suricata/Zeek rule for RFB 003. byte pattern destined to FortiSandbox IPs. High signal, near-zero false positive on a security VLAN.
4. Audit which analysts submit sensitive files — Assume anything detonated in the last 90 days on an unpatched appliance could have been observed if an attacker had internal access. Rotate any credentials that may have appeared in submitted samples.

Run on an *auditor workstation* on the same L3 segment as the FortiSandbox appliance. Invoke as ./check-cve-2026-59835.sh <fsa-ip>; requires nmap and outbound TCP to ports 5900–5910. No credentials needed — this only probes the exposed VNC binding.

#!/usr/bin/env bash
# noisgate check for CVE-2026-59835 (FortiSandbox VNC exposure)
# Usage: ./check-cve-2026-59835.sh <fortisandbox-ip>
set -u
TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "UNKNOWN: usage: $0 <fortisandbox-ip>"; exit 2
fi
if ! command -v nmap >/dev/null 2>&1; then
  echo "UNKNOWN: nmap not installed"; exit 2
fi

# Probe the VNC port range used by FortiSandbox scanning VMs
SCAN=$(nmap -Pn -sT -p 5900-5910 --open -sV "$TARGET" 2>/dev/null)
OPEN=$(echo "$SCAN" | awk '/\/tcp[[:space:]]+open/ {print $1}')

if [[ -z "$OPEN" ]]; then
  echo "PATCHED (or ACL'd): no VNC ports reachable on $TARGET"
  exit 0
fi

# Attempt an RFB handshake read — vulnerable appliance responds with 'RFB 003.'
for P in $OPEN; do
  PORT=${P%/tcp}
  BANNER=$(timeout 3 bash -c "exec 3<>/dev/tcp/$TARGET/$PORT; head -c 12 <&3" 2>/dev/null)
  if [[ "$BANNER" == RFB* ]]; then
    echo "VULNERABLE: $TARGET:$PORT exposes VNC ($BANNER) — CVE-2026-59835"
    exit 1
  fi
done

echo "UNKNOWN: ports open on $TARGET but no RFB banner returned — investigate manually"
exit 2

Sources

1. Fortinet PSIRT FG-IR-26-145 (advisory)
2. CyberPress — FortiSandbox VNC server exposure
3. CybersecurityNews — FortiSandbox VNC vuln coverage
4. Greenbone — Fortinet RCE and FortiSandbox 2026 flaws
5. CCB Belgium — Fortinet multi-product advisory
6. BleepingComputer — Fortinet FortiSandbox/FortiAuthenticator flaws
7. CWE-668 — Exposure of Resource to Wrong Sphere