On October 8, 2026, NVD published two critical vulnerabilities in Brocade Fabric OS (Broadcom), the operating system running the Fibre Channel switches behind a large share of enterprise SANs. Both are rated 9.8 and, according to NVD, affect versions before 10.0.1.
The first one travels through the fabric itself, the second through the SNMP interface. Two different paths to the same outcome: control of a switch that carries all your storage traffic.
| CVE-2026-87659 | CVE-2026-87684 | |
|---|---|---|
| CVSS 3.1 | 9.8 (CRITICAL) | 9.8 (CRITICAL) |
| Vector | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Component | Management Server | SNMP daemon (SNMPv3) |
| NVD published | 2026-10-08 | 2026-10-08 |
| CISA KEV | no (as of writing) | no (as of writing) |
CVE-2026-87659: A Fabric Peer Acting as an Admin
A compromised switch connected to the fabric can transmit crafted inband Fibre Channel vendor-unique CT (Common Transport) management requests to bypass administrative authentication.
Switches in a Fibre Channel fabric constantly exchange in-band management requests over the Common Transport protocol. That's how the Management Server shares fabric topology and state. The flaw: some of these vendor-specific requests are processed without checking administrative authentication.
The impact NVD describes: an unauthorized peer switch can run administrative actions on the target, including resetting admin passwords, rebooting the system and triggering a firmware download.
That last one is the real concern. A forced firmware is persistence that survives password changes, sitting in a device few teams ever audit.
The prerequisite is an already compromised switch, or a rogue device attached to the fabric. That sounds demanding, but a fabric is a trust domain: one compromised switch becomes a stepping stone to all the others. The NVD vector is still AV:N/PR:N, with no privileges required on the target.
CVE-2026-87684: Stack Overflow in the SNMP Daemon
A remote, unauthenticated attacker (under default configuration) can exploit this vulnerability by sending a specially crafted SNMPv3 packet
While processing an incoming SNMPv3 packet, an internal statistics handler copies sender-supplied data into a fixed-size buffer without checking its length. A textbook stack overflow. NVD lists three possible outcomes: memory corruption, daemon crash (denial of service), and potential code execution.
Two details matter: no authentication required, and default configuration. Any switch whose SNMP service is reachable from an untrusted network is exposed.
Why This Matters on a SAN
A Fibre Channel switch isn't just another network box. It holds the zoning, meaning which host sees which LUN. Controlling it lets an attacker:
- change zoning and expose volumes to a server that shouldn't see them
- cut storage access for whole clusters, hypervisors and databases included
- install firmware on a device that rarely reports to an EDR or SIEM
And SANs are often the blind spot of patch programmes: maintenance once or twice a year, hard-won windows, firmware frozen on versions certified by the array vendor.
Versions
NVD says "versions before 10.0.1" for both CVEs and lists 10.0.1 as the boundary. That's an NVD boundary, not necessarily the version recommended for your platform: your storage array's compatibility matrix and the Broadcom security advisory are the references for picking the release to install.
Check the Fabric OS version on every switch in the fabric, including standby switches and remote-site switches linked by ISL.
Detection
- Undocumented admin password changes in Fabric OS audit logs
- Unexpected reboots of a switch, or of the SNMP daemon
- Firmware downloads outside maintenance windows, or a firmware version that doesn't match your inventory
- A new switch joining the fabric, or an unplanned topology change
- SNMPv3 traffic to the switches from sources other than your monitoring platforms
Mitigation
- Schedule the Fabric OS upgrade to a fixed release per the Broadcom advisory and your array's matrix. Two 9.8 CVEs, one unauthenticated: that justifies a dedicated maintenance window.
- Restrict SNMP to your monitoring tools' addresses using the switch access lists, and disable SNMP where it isn't used.
- Isolate switch management interfaces on a dedicated admin network, never reachable from user networks.
- Control fabric admission: review the switch membership policy Fabric OS offers, so an unexpected device can't join the fabric.
- Audit the firmware version of every switch after the upgrade and compare against inventory.
- If a switch looks suspicious: treat it as compromised, isolate it from the fabric and reinstall firmware from a verified source.
Why Continuous Monitoring of SAN Gear Matters
Fibre Channel switches are among the most critical and least tracked devices in an IT estate. Their firmware rarely changes, and a critical CVE can stay open for months without anyone linking it to the inventory.
With cveo.tech, register your SAN switches with their Fabric OS version and get alerted whenever a critical CVE affects them.