Like finding an unlocked filing cabinet in a building that was condemned three years ago
CVE-2026-36848 is an unauthenticated directory traversal in the H-VUE web management subsystem of Gigamon GigaVUE-OS (GVOS) appliances running version 5.16.1 and earlier. The vulnerable component is persistd.py, a TornadoHTTP-based daemon listening on port 8089. It exposes /download/ and /upload/ URL handlers that pass user-supplied path segments directly to filesystem operations without sanitisation. An attacker with network access to port 8089 can read arbitrary files as root (e.g., GET /download/..%2F..%2F..%2Fetc%2Fshadow) and perform partial writes — creating new files at arbitrary locations, though overwriting existing files is not possible. The write primitive could theoretically be chained to RCE by dropping a cron job or similar, and the PoC author (calligraf0) labels the exploit "Unauth RCE," though the CVSS vector scores only the confidentiality impact.
The vendor's HIGH / 7.5 rating is technically defensible if you evaluate the CVSS vector in a vacuum: network-reachable, no auth, no user interaction, high confidentiality impact. But it dramatically overstates real-world risk. GVOS 5.16.1 reached end of support on May 26, 2023 — over three years ago. GVOS 6.x removed the H-VUE subsystem entirely, meaning no currently supported version of GigaVUE-OS contains this code. Gigamon packet brokers sit on isolated management networks deep inside data centers; port 8089 is a legacy management interface with near-zero internet exposure. SSVC classifies it as *not automatable* with *partial technical impact*. The vendor severity treats the vulnerability as if it exists in actively maintained, widely deployed software — it does not.
4 steps from start to impact.
Gain management network access
- Network access to the GigaVUE management interface on port 8089
- Target must be running GVOS ≤ 5.16.1 (EOL since May 2023)
- Gigamon appliances are not internet-facing; management interfaces are segmented
- GVOS 5.16.1 has been EOL for 3+ years — shrinking installed base
- Port 8089 is not a default listener in current GVOS versions
..%2F) in HTTP requests to port 8089. No Shodan/Censys exposure data exists for this service on the public internet.Directory traversal via /download/ endpoint
/download/..%2F..%2F..%2Fetc%2Fshadow (or any sensitive file path). The DownloadDbFile handler in persistd.py passes the URL-encoded path directly to a filesystem read operation as root, returning the file contents in the HTTP response. No authentication token, session cookie, or API key is required. The calligraf0 PoC on GitHub automates this step.- Network connectivity to port 8089 on the target
- Requires the H-VUE subsystem to be active — disabled in GVOS 6+
..%2F in URI paths would block this trivially, though Gigamon appliances are rarely placed behind WAFs.Arbitrary file read as root
/etc/shadow, SSH host keys, SNMP community strings, API tokens, and Gigamon configuration exports. On a packet broker, configuration files may contain credentials for upstream or downstream integrations. However, this does NOT grant access to mirrored network traffic — packet broker traffic flows do not persist to disk in readable form through this path.- Successful traversal from step 2
- Credential material read from the device is limited to the Gigamon appliance itself — lateral movement requires separate exploitation
Partial file write via /upload/ endpoint (RCE chain attempt)
/upload/ handler with traversal sequences. The limitation is that existing files cannot be overwritten. To achieve RCE, the attacker would need to write a new cron job (e.g., to /etc/cron.d/backdoor) or a new authorized_keys file if none exists. The calligraf0 PoC titles the exploit 'Unauth RCE,' implying this chain was demonstrated, though the CVSS vector scores only confidentiality impact (I:N).- Target file path must not already exist (overwrite is blocked)
- Target directory must be writable by root and execute scheduled tasks or similar
- Cannot overwrite existing files — limits many common write-to-RCE chains
- GVOS is a hardened appliance OS; cron and SSH may be configured in ways that limit new-file abuse
- SSVC classifies exploitation as 'not automatable'
/etc/cron.d/, /root/.ssh/, and /etc/ for new file creation would catch this step...%2F or ../ patterns in HTTP requests to TCP/8089. This provides detection-in-depth for any residual exposure. Example: alert http any any -> any 8089 (msg:"CVE-2026-36848 Gigamon H-VUE traversal"; content:"..%2F"; nocase; sid:2026036848; rev:1;).- Vendor patching — no patch exists or will exist. GVOS 5.16.x is end-of-life. The only remediation is upgrading to GVOS 6+.
- WAF in front of the Gigamon appliance — nobody deploys a WAF in front of a network packet broker's management interface. This is theoretically viable but operationally absurd.
- Disabling H-VUE via config — on GVOS ≤ 5.16.1, H-VUE is an integral subsystem; there is no supported method to disable
persistdwithout side effects. Firewall rules are more reliable.
The supporting signals.
| In-the-wild exploitation | None observed. Not listed in CISA KEV. No GreyNoise tags or scanning activity detected for this CVE or for Gigamon port 8089. No campaigns documented by Mandiant, CrowdStrike, or Proofpoint reference this CVE. |
|---|---|
| Proof-of-concept | Public. GitHub repo calligraf0/CVE-2026-36848 provides a working PoC demonstrating arbitrary file read and partial write via the /download/ and /upload/ endpoints. Titled "Gigamon Unauth RCE." No nuclei template or ExploitDB entry found. |
| EPSS | 0.00928 (≈0.93%) — roughly 48th–58th percentile depending on source. Indicates very low predicted exploitation probability in the next 30 days. |
| CISA KEV status | Not listed. No known exploitation has triggered KEV inclusion. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N — Network-accessible, no auth, no interaction, high confidentiality impact only. Notably scores I:N (no integrity impact) despite the partial write capability documented in the PoC. The vector may undercount actual impact. |
| Affected versions | Gigamon GigaVUE-OS (GVOS) ≤ 5.16.1. The vulnerable H-VUE subsystem runs in the persistd.py daemon on port 8089. GVOS 5.16.1 was the last version to include H-VUE. |
| Fixed / unaffected versions | GVOS 6.0 and all later releases removed the H-VUE subsystem entirely. There is no patch for 5.16.x — the software reached end of support on May 26, 2023. Remediation is upgrading to any supported GVOS release. |
| Scanning / exposure | Near-zero internet exposure. Gigamon appliances are internal network visibility infrastructure (packet brokers / TAPs) deployed on management VLANs. Port 8089 does not appear in Shodan or Censys scans. Gigamon's own default port documentation lists 22, 80, 161, 443, and 9090 — not 8089. |
| SSVC assessment | Proof-of-concept available; not automatable; partial technical impact. This aligns with the low real-world risk profile. |
| Researcher / disclosure | Discovered and disclosed by calligraf0 (GitHub). CVE reserved 2026-04-06, published 2026-06-29, last modified 2026-07-01. References point to the GitHub PoC and Gigamon's EOL policy. |
Sources.
Why this verdict
- EOL software dominates the calculus. GVOS 5.16.1 reached end of support on May 26, 2023 — over three years ago. GVOS 6.x removed the vulnerable H-VUE subsystem entirely. No currently supported version of GigaVUE-OS contains this code. The vulnerability exists only in software Gigamon no longer maintains, and no patch will be issued.
- Internal-only management interface. Gigamon GigaVUE appliances are network packet brokers and TAPs deployed on isolated management VLANs inside data centers. Port 8089 (the H-VUE daemon) has near-zero internet exposure per Shodan/Censys and is not among Gigamon's default open ports. Reaching this service requires an attacker who is already post-initial-access on the management plane — a significant prerequisite that CVSS does not account for.
- Shrinking installed base. With 3+ years since EOL, the population of GVOS ≤ 5.16.1 deployments is small and declining. Organizations still running this version have broader unsupported-infrastructure problems that dwarf this single CVE.
- No exploitation evidence, low EPSS, not automatable. EPSS is ~0.93%, no KEV listing, no GreyNoise tags, no documented campaigns. SSVC classifies exploitation as not automatable with partial technical impact. The PoC exists but requires manual targeting of an internal management interface.
- Role multiplier: Gigamon packet brokers are NOT in the high-value-role catalog. They are internal network visibility infrastructure — not firewalls, identity providers, hypervisors, CAs, or edge appliances. Compromising a packet broker's filesystem yields device credentials and configuration data, not fleet-scale or identity-scale blast radius. The device does see copies of monitored traffic, but the directory traversal reads files from disk, not live packet captures. The blast radius is host-level (the Gigamon appliance itself), not domain-level or fleet-level. This does not trigger the HIGH floor.
Why not higher?
To rate this MEDIUM or above, you'd need either active exploitation, meaningful internet exposure, or impact to a high-value role with fleet-scale blast radius. None of those apply. The software is 3+ years past EOL, the management interface sits behind management VLAN segmentation, the installed base is negligible and shrinking, and the blast radius of compromising a single packet broker appliance is limited to that device's configuration and credentials — not domain takeover, supply-chain pivot, or fleet-scale impact.
Why not lower?
We don't drop to IGNORE because the PoC is public and functional, the attack is unauthenticated once you reach port 8089, and some enterprises almost certainly still have EOL Gigamon devices on their management networks. The partial write-to-RCE chain (via cron job creation) adds integrity and availability impact that the CVSS vector undercounts. For those laggard environments, this is a real — if niche — risk that warrants backlog attention rather than complete dismissal.
Crowdsourced verification payload.
Run this script from any Linux/macOS workstation that has network access to the Gigamon appliance's management interface. Usage: ./check_cve_2026_36848.sh <target_ip>. No special privileges required on the auditor workstation; the script makes an unauthenticated HTTP request to port 8089.
#!/usr/bin/env bash
# CVE-2026-36848 Checker — Gigamon GVOS H-VUE Directory Traversal
# Tests whether port 8089 (H-VUE persistd) is reachable and responds
# to a path-traversal probe reading /etc/hostname.
# Exit codes: 0 = VULNERABLE, 1 = PATCHED/NOT AFFECTED, 2 = UNKNOWN
set -euo pipefail
TARGET="${1:-}"
PORT=8089
TIMEOUT=5
if [ -z "$TARGET" ]; then
echo "Usage: $0 <target_ip_or_hostname>"
exit 2
fi
# Step 1: Check if port 8089 is open
if ! timeout "$TIMEOUT" bash -c "echo >/dev/tcp/$TARGET/$PORT" 2>/dev/null; then
echo "PATCHED — Port $PORT is not reachable on $TARGET."
echo "The H-VUE subsystem (persistd) is not listening. Either GVOS >= 6.x"
echo "(which removed H-VUE) or the port is firewalled."
exit 1
fi
echo "[*] Port $PORT is open on $TARGET. Testing traversal..."
# Step 2: Attempt directory traversal to read /etc/hostname
RESPONSE=$(curl -sk --max-time "$TIMEOUT" \
"http://$TARGET:$PORT/download/..%2F..%2F..%2Fetc%2Fhostname" 2>/dev/null || true)
if [ -z "$RESPONSE" ]; then
# Try HTTPS variant
RESPONSE=$(curl -sk --max-time "$TIMEOUT" \
"https://$TARGET:$PORT/download/..%2F..%2F..%2Fetc%2Fhostname" 2>/dev/null || true)
fi
if [ -z "$RESPONSE" ]; then
echo "UNKNOWN — Port $PORT is open but did not respond to traversal probe."
echo "Manually verify whether the H-VUE subsystem is running."
exit 2
fi
# Step 3: Check if we got a hostname back (not an error page)
if echo "$RESPONSE" | grep -qiE '(404|not found|error|forbidden|<!DOCTYPE)'; then
echo "PATCHED — Port $PORT responded but rejected the traversal request."
exit 1
fi
# If we got non-error content back, the traversal likely succeeded
echo "VULNERABLE — CVE-2026-36848 confirmed on $TARGET."
echo "Traversal response (first 200 chars):"
echo "$RESPONSE" | head -c 200
echo ""
exit 0