← Back to Feed CACHED · 2026-10-02 05:15:15 · CACHE_KEY CVE-2026-36848
CVE-2026-36848 · CWE-22 · Disclosed 2026-06-29

Gigamon GigaVUE-OS H-VUE Subsystem Unauthenticated Directory Traversal (persistd on port 8089)

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Unauth file read on a network packet broker nobody should still be running — EOL since May 2023."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Gain management network access

The attacker must reach port 8089 on a GigaVUE appliance running GVOS ≤ 5.16.1. Gigamon devices sit on out-of-band management VLANs in data centers, behind ACLs and often behind jump boxes. Port 8089 is not a default open port for current GVOS versions and is essentially a legacy interface. The attacker is already post-initial-access — they are inside the management plane.
Conditions required:
  • Network access to the GigaVUE management interface on port 8089
  • Target must be running GVOS ≤ 5.16.1 (EOL since May 2023)
Where this breaks in practice:
  • 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
Detection/coverage: Network IDS rules can flag traversal sequences (..%2F) in HTTP requests to port 8089. No Shodan/Censys exposure data exists for this service on the public internet.
STEP 02

Directory traversal via /download/ endpoint

The attacker sends a crafted GET request to /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.
Conditions required:
  • Network connectivity to port 8089 on the target
Where this breaks in practice:
  • Requires the H-VUE subsystem to be active — disabled in GVOS 6+
Detection/coverage: WAF or reverse proxy rules matching ..%2F in URI paths would block this trivially, though Gigamon appliances are rarely placed behind WAFs.
STEP 03

Arbitrary file read as root

The attacker can now read any file the root user can access on the GVOS appliance. High-value targets include /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.
Conditions required:
  • Successful traversal from step 2
Where this breaks in practice:
  • Credential material read from the device is limited to the Gigamon appliance itself — lateral movement requires separate exploitation
Detection/coverage: File integrity monitoring (FIM) on the appliance would log anomalous reads, though FIM is rarely deployed on network appliance OS.
STEP 04

Partial file write via /upload/ endpoint (RCE chain attempt)

The attacker can create new files at arbitrary filesystem locations as root via the /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).
Conditions required:
  • Target file path must not already exist (overwrite is blocked)
  • Target directory must be writable by root and execute scheduled tasks or similar
Where this breaks in practice:
  • 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'
Detection/coverage: FIM or auditd rules watching /etc/cron.d/, /root/.ssh/, and /etc/ for new file creation would catch this step.
03 · Compensating Control

1
LOW 3.5→IGNORE 0.0
SEVERITY REDUCED
Block port 8089 on management network ACLs — The H-VUE daemon on port 8089 is a legacy interface that should not be needed if you are managing GigaVUE appliances via CLI (SSH on port 22) or the GigaVUE-FM centralized manager. Add a deny rule for TCP/8089 on management VLAN switch ACLs or host firewall. This is a LOW-severity finding with no mitigation SLA — treat as backlog hygiene, but this control is trivial and eliminates the attack surface entirely.
2
LOW 3.5→IGNORE 0.0
SEVERITY REDUCED
Upgrade to any supported GVOS release (6.x+) — GVOS 6.0 and later removed the H-VUE subsystem entirely. Upgrading eliminates the vulnerable code. Since this is a LOW-severity finding, there is no noisgate mitigation SLA; remediation falls under backlog hygiene. However, running software 3+ years past EOL is itself a material risk — prioritize the upgrade for lifecycle reasons independent of this CVE.
3
LOW 3.5→LOW 2.0
Restrict management VLAN access to jump boxes only — If port 8089 cannot be blocked (e.g., H-VUE is still operationally required), restrict source IPs on the management VLAN to authorized jump boxes or bastion hosts only. This limits the attacker population to those who have already compromised an admin workstation or bastion, adding significant friction.
4
LOW 3.5→LOW 2.5
Deploy IDS/IPS signature for path traversal on port 8089 — Write a Suricata or Snort rule matching ..%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;).
What doesn't work
  • 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 persistd without side effects. Firewall rules are more reliable.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone 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-conceptPublic. 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.
EPSS0.00928 (≈0.93%) — roughly 48th–58th percentile depending on source. Indicates very low predicted exploitation probability in the next 30 days.
CISA KEV statusNot listed. No known exploitation has triggered KEV inclusion.
CVSS vectorCVSS: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 versionsGigamon 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 versionsGVOS 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 / exposureNear-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 assessmentProof-of-concept available; not automatable; partial technical impact. This aligns with the low real-world risk profile.
Researcher / disclosureDiscovered 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.

  1. OpenCVE — CVE-2026-36848 Detail
  2. calligraf0/CVE-2026-36848 — GitHub PoC
  3. Strix AI — CVE-2026-36848 Analysis
  4. CyberStrike — CVE-2026-36848 Detail
  5. Gigamon EOL Policy
  6. Gigamon Default Ports Documentation
  7. Gigamon End-of-Sale / End-of-Life Products
05 · The Call

Final Verdict
↓ DOWNGRADED to LOW (3.5/10)

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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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