← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-0383 · CWE-78 · Disclosed 2026-01-27

Information disclosure in Brocade Fabric OS before 9

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.

"This is a post-compromise SAN secret leak, not a front-door break-in."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Reach the switch management plane with ssh

The attacker first needs access to a Fabric OS management interface and valid credentials for a local or centralized account. In most enterprises that means landing on the management network or a jump host first, then logging in over SSH or an equivalent admin path.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Good coverage for the login event itself via switch auth logs, AAA logs, and jump-host logs; poor coverage for intent.
STEP 02

Escalate into shell-capable context with bash or maintenance access

The vulnerability is not exposed to every authenticated user; the account must have privileges to access the Bash shell. Broadcom's own platform hardening notes that in FOS 9.0+ the root account is disabled by default and in FOS 9.1+ direct root access was removed, so the reachable population is narrower than the CVSS label suggests.
Conditions required:
  • Account has privileges to access the Bash shell or equivalent maintenance context
  • Target runs a vulnerable Fabric OS build
Where this breaks in practice:
  • 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
Detection/coverage: Partial. Role assignment reviews and privileged-session logging can catch this, but many shops do not deeply audit shell transitions on storage switches.
STEP 03

Read insecurely stored files with history, cat, or grep

Once in shell context, the attacker can inspect files that should not have been left readable, including shell history. The practical value is opportunistic secret harvesting: past commands, troubleshooting artifacts, embedded credentials, hostnames, zoning details, or support data that helps later movement.
Conditions required:
  • Relevant files exist on disk and are readable from the shell context
  • Administrators or support staff previously used commands that left sensitive material behind
Where this breaks in practice:
  • 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
Detection/coverage: Weak. Version-based scanners can flag vulnerable releases, but file reads of command history are usually invisible unless shell command auditing is enabled.
STEP 04

Exploit the disclosed data for follow-on access

The attacker uses whatever was exposed—credentials, topology data, support artifacts, or administrative workflows—to move deeper into the SAN management tier or adjacent infrastructure. This is where business impact appears, but it depends entirely on what operators previously left behind in history and files.
Conditions required:
  • Disclosed data includes reusable credentials or sensitive operational context
  • Those credentials or details still work elsewhere
Where this breaks in practice:
  • 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
Detection/coverage: Detection shifts to downstream controls: AAA anomalies, lateral-management logins, and credential-use monitoring.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 / PoCNo public exploit or PoC was found in current searches. Tenable's Nessus plugin for this CVE states 'No known exploits are available'.
EPSSUser-supplied EPSS was 0.00011; Shodan's CVE dashboard shows EPSS ranking 1.4%, i.e. near the floor of likely exploitation.
KEV statusNot in CISA KEV based on the current Known Exploited Vulnerabilities Catalog.
CVSS reality checkCNA 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 versionsBroadcom advisory and NVD list before 9.2.1c2, 9.2.2 through 9.2.2a, and 10.0.0 as affected.
Fixed versionsBroadcom 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 realityThis 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 timelineBroadcom'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 / reportingBroadcom credits internal testing; no external researcher is named in the advisory.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (4.6/10)

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.

HIGH Affected/fixed version boundaries from Broadcom and NVD
MEDIUM Reassessed severity based on real-world attacker-position friction
MEDIUM Absence of public exploit evidence in reviewed sources

Why this verdict

  • Downgrade for attacker position: AV:L is 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a post-compromise appliance secret-leak issue, not a remote emergency. Because the reassessed verdict is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use that time to inventory Fabric OS versions, remove standing shell-capable access, and rotate any secrets that may have been typed on-switch. Apply access-hardening during normal operations now, then complete the actual firmware upgrades to 9.2.1c2 / 9.2.2b / 10.0.0a or later within the noisgate remediation SLA of ≤365 days.

Sources

  1. Broadcom advisory BSA-2026-3181
  2. NVD CVE-2026-0383
  3. CISA Known Exploited Vulnerabilities Catalog
  4. Shodan CVEDB entry for CVE-2026-0383
  5. Tenable Nessus plugin 299689
  6. Broadcom Safeguard your SAN with Brocade Gen 7
  7. Broadcom Brocade Fabric OS SAN Security Features
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.