This is a spare key hidden inside the locked server room, not a burglar opening the front door
CVE-2026-0383 is an information disclosure flaw in Brocade Fabric OS where an authenticated local attacker who already has privileges to reach the Bash shell can read insecurely stored file contents, including command history. Broadcom says affected releases are all versions before 9.2.1c2, 9.2.2 through 9.2.2a, and 10.0.0, with fixes in 9.2.1c2, 9.2.2b, and 10.0.0a.
The vendor's HIGH 8.2 score is technically defensible in a vacuum but operationally inflated. The decisive friction is not exploit complexity; it is attacker position: this requires authenticated local access on a SAN switch plus shell-level privileges, which means the attacker is already inside your management boundary and already holds an unusually powerful account.
4 steps from start to impact.
Reach the switch management plane with ssh
- Fabric OS management IP is reachable from the attacker's foothold
- Valid credentials or an already-compromised admin account
- SSH or other admin access is enabled
- Management networks are often segmented from user networks
- AAA controls such as TACACS+/RADIUS and MFA can block casual credential reuse
- Many SANs are only reachable through privileged jump hosts
Escalate into shell-capable context with bash or maintenance access
- Account has privileges to access the Bash shell or equivalent maintenance context
- Target runs a vulnerable Fabric OS build
- Most day-to-day SAN operators never need native shell access
- Support or break-glass accounts are fewer and more auditable than standard admin roles
- Modern role design should sharply limit who can reach this layer
Read insecurely stored files with history, cat, or grep
- Relevant files exist on disk and are readable from the shell context
- Administrators or support staff previously used commands that left sensitive material behind
- Some environments have clean operator hygiene and sparse shell history
- Not every switch will contain reusable secrets or high-value artifacts
- The issue is disclosure-focused, not direct code execution
Exploit the disclosed data for follow-on access
- Disclosed data includes reusable credentials or sensitive operational context
- Those credentials or details still work elsewhere
- Blast radius is limited if credentials are vaulted, rotated, and scoped
- A single switch's history may not provide broader access
- Downstream movement may be stopped by MFA, network segmentation, or separate admin domains
The supporting signals.
| In-the-wild status | No current evidence of active exploitation found in public sources reviewed. It is not listed in CISA KEV, and I found no vendor, CISA, or major threat-intel reporting tying this CVE to campaigns. |
|---|---|
| Public exploit / PoC | No public exploit or PoC was found in current searches. Tenable's Nessus plugin for this CVE states 'No known exploits are available'. |
| EPSS | User-supplied EPSS was 0.00011; Shodan's CVE dashboard shows EPSS ranking 1.4%, i.e. near the floor of likely exploitation. |
| KEV status | Not in CISA KEV based on the current Known Exploited Vulnerabilities Catalog. |
| CVSS reality check | CNA vector is AV:L/PR:L/UI:N with high confidentiality impacts. That is the tell: this is local, authenticated, post-boundary abuse, not remotely reachable unauthenticated compromise. |
| Affected versions | Broadcom advisory and NVD list before 9.2.1c2, 9.2.2 through 9.2.2a, and 10.0.0 as affected. |
| Fixed versions | Broadcom fixed this in 9.2.1c2, 9.2.2b, and 10.0.0a. No distro backport stream was identified because this is vendor appliance firmware, not a general Linux package. |
| Exposure / scanning reality | This is a poor fit for internet-exposure metrics. Shodan can track the CVE and score it, but the vulnerable condition is not exposed service-side; it requires post-login shell access, so GreyNoise/Censys-style mass scanning is largely irrelevant. |
| Disclosure timeline | Broadcom's advisory was published 2026-01-27; NVD published the CVE entry on 2026-02-03 and added NVD enrichment on 2026-02-06. |
| Discovery / reporting | Broadcom credits internal testing; no external researcher is named in the advisory. |
noisgate verdict.
The single biggest downgrade factor is the prerequisite chain: the attacker already needs authenticated local access to the SAN switch and privileges to reach Bash shell. That sharply limits exposed population and makes this a post-compromise secret exposure issue rather than an initial-access vulnerability.
Why this verdict
- Downgrade for attacker position:
AV:Lis not a nuisance detail; it means the attacker is already on-box or effectively operating through an existing management foothold. - Downgrade again for privilege scope: this is not merely authenticated access, it is an account with privileges to reach the Bash shell on a storage switch—an unusually narrow population in mature enterprises.
- Downgrade for exposure reality: Broadcom notes hardening in FOS 9.x that removed or reduced direct root/native OS access, which further shrinks who can actually trigger this path.
- Downgrade for threat evidence: no KEV listing, no public PoC found, and EPSS sits near the bottom of the distribution.
- Hold at MEDIUM, not LOW: if an attacker does satisfy the prerequisites, command history on SAN infrastructure can leak high-value operational secrets and enable higher-consequence follow-on access.
Why not higher?
There is no front-door path here. The chain requires prior management-plane reachability, valid credentials, and shell-capable privileges on a SAN switch, which compounds downward pressure at every step. Even then, the flaw discloses whatever operators left behind; it does not itself grant code execution or privilege escalation.
Why not lower?
Calling this LOW would understate the potential value of what can leak from storage-network administration history. SAN switches sit close to crown-jewel infrastructure, and exposed commands, credentials, or topology data can materially amplify an existing intrusion.
What to do — in priority order.
- Restrict management-plane reachability — Limit Fabric OS SSH and admin access to dedicated jump hosts and management segments, and validate that only storage admin workstations can reach those IPs. For a MEDIUM finding there is no noisgate mitigation SLA, but this is the highest-value containment step while you work through the remediation window.
- Treat shell-capable accounts as break-glass only — Review who can reach Bash or maintenance contexts, remove standing access where possible, and require explicit approval for vendor/support use. This directly attacks the decisive prerequisite that makes the CVE reachable.
- Rotate any secrets ever typed on-switch — Assume CLI history may have captured credentials, tokens, hostnames, or troubleshooting commands and rotate those secrets in priority order. Focus first on shared admin accounts, service credentials, and anything used across multiple fabrics.
- Centralize auth and session accountability — Force admin access through TACACS+/RADIUS/jump-host logging so you can correlate who logged in, from where, and when shell-capable sessions occurred. For a MEDIUM issue this is a control-hardening task to complete within the normal remediation program rather than an emergency block.
- A WAF or edge IPS does not help; this is not an HTTP or perimeter exploit path.
- Internet scanning reduction alone does not solve the problem, because the reachable condition is post-login shell access rather than an exposed unauthenticated service flaw.
- EDR on the switch is usually unavailable or irrelevant on this appliance class; do not assume endpoint telemetry will catch history-file access.
Crowdsourced verification payload.
Run this from an auditor workstation or jump host that has network reachability to the Fabric OS management IP and an ssh client installed. Invoke it as python3 check_cve_2026_0383.py [email protected]; it needs only a read-capable account that can execute the version command over SSH.
#!/usr/bin/env python3
# check_cve_2026_0383.py
# Verify whether a Brocade Fabric OS host appears vulnerable to CVE-2026-0383
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=USAGE
import re
import subprocess
import sys
USAGE = "Usage: python3 check_cve_2026_0383.py user@host\n"
def parse_fos(ver):
m = re.fullmatch(r"(\d+)\.(\d+)\.(\d+)([a-z]?)(\d*)", ver.strip(), re.I)
if not m:
return None
major = int(m.group(1))
minor = int(m.group(2))
patch = int(m.group(3))
letter = m.group(4).lower()
letter_val = 0 if letter == "" else (ord(letter) - ord("a") + 1)
letter_num = int(m.group(5)) if m.group(5) else 0
return (major, minor, patch, letter_val, letter_num)
def cmp_ver(a, b):
return (a > b) - (a < b)
def is_vulnerable(ver_str):
v = parse_fos(ver_str)
if v is None:
return None
v_921c2 = parse_fos("9.2.1c2")
v_922 = parse_fos("9.2.2")
v_922b = parse_fos("9.2.2b")
v_1000 = parse_fos("10.0.0")
# Per Broadcom/NVD published ranges:
# - versions before 9.2.1c2
# - versions from 9.2.2 up to (excluding) 9.2.2b
# - version 10.0.0
if cmp_ver(v, v_921c2) < 0:
return True
if cmp_ver(v, v_922) >= 0 and cmp_ver(v, v_922b) < 0:
return True
if cmp_ver(v, v_1000) == 0:
return True
return False
def get_version(target):
cmd = [
"ssh",
"-o", "BatchMode=yes",
"-o", "ConnectTimeout=10",
target,
"version"
]
proc = subprocess.run(cmd, capture_output=True, text=True)
if proc.returncode != 0:
return None, proc.stderr.strip() or proc.stdout.strip()
text = proc.stdout
# Try to find a Fabric OS style version anywhere in output, e.g. 9.2.1c1 / 9.2.2b / 10.0.0a
matches = re.findall(r"\b\d+\.\d+\.\d+[a-z]?\d*\b", text, re.I)
if not matches:
return None, text.strip()
# Prefer higher/longer-looking versions if multiple tokens exist
matches = sorted(matches, key=lambda s: (len(s), s), reverse=True)
return matches[0], text.strip()
def main():
if len(sys.argv) != 2:
sys.stderr.write(USAGE)
sys.exit(3)
target = sys.argv[1]
version, raw = get_version(target)
if version is None:
print("UNKNOWN")
sys.stderr.write("Could not retrieve/parse Fabric OS version. SSH output follows:\n")
sys.stderr.write((raw or "<no output>") + "\n")
sys.exit(2)
verdict = is_vulnerable(version)
if verdict is None:
print("UNKNOWN")
sys.stderr.write(f"Parsed version token '{version}' but could not evaluate it.\n")
sys.exit(2)
if verdict:
print("VULNERABLE")
print(f"Detected Fabric OS version: {version}")
sys.exit(1)
else:
print("PATCHED")
print(f"Detected Fabric OS version: {version}")
sys.exit(0)
if __name__ == "__main__":
main()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.