43 CVEs in your array's fibre switch, and not one is critical

On 8 October 2026 the NVD published, on the same day, 43 Brocade Fabric OS vulnerabilities: the operating system of the fibre switches sitting between your servers and your disk array. None of them is rated critical. The highest stops at 8.7. And 38 of the 43 require the attacker to already hold credentials. With those three numbers, the advisory files itself away. Which is exactly what made me read the whole thing.

Up front, so you know where this is written from: at everyWAN we do not sell Brocade, arrays, or licences of any kind. What we run in production is Proxmox VE with distributed Ceph storage across several datacentres, and we provide colocation on our own hardware. Even so, this article does not end in "change technology". It ends in a far cheaper question.

The idea we are going to argue with, in its strongest form

The reason the fibre switch has gone years without being touched is not laziness. It is an argument, and a good one: Fibre Channel is not routed, there is no path from the internet to that port; zoning is enforced by the hardware itself rather than by a firewall whose rules someone can scramble; the network joining the servers to the array is a cable that never leaves the rack. And above all: it has worked for years. Touching it can only make it worse.

I have defended that position in meetings. The problem is that the 8 October batch answers the first half, and the vendor's own documentation answers the second.

Who the attacker in these 43 advisories actually is

All 43 carry a CVSS 4.0 vector. If instead of the score you read the vector, the batch says something very specific about where it expects the attack to come from:

That distribution is exactly what produces low scores. CVSS charges a toll for every obstacle the attacker must clear before starting, and here almost every advisory charges two: you have to be next to it and you have to be authenticated. Hence no criticals. But look at what you just said: the batch's threat model is not the internet. It is the neighbour. And "the neighbour is trusted" is, word for word, the argument for not patching.

The five that ask for nothing: start there

Before going on, it is worth pulling the five that need no credentials out of the pile, because they are the ones an operator should look at first and because they contradict the comfortable reading of "this only happens to people who are already inside". The highest-scoring one in the batch is CVE-2026-87684 (8.7): a stack overflow in the SNMP daemon that, per the advisory, "a remote, unauthenticated attacker (under default configuration)" can exploit with a single crafted SNMPv3 packet, causing memory corruption, daemon crash or potential arbitrary code execution. CVE-2026-94585 (7.7) is an authentication bypass in the single sign-on workflow of the MXG610 platform's web interface: administrative access with no credentials, though the vector marks it as high attack complexity. And CVE-2026-87671 (7.1) crashes the web management daemon with one unauthenticated HTTP request.

All three are adjacent-vector, not internet-facing. But "adjacent" here means the switch's management network, and in too many places the switch's management network is the same flat VLAN as the printers.

Two advisories where the attacker is another switch

This is what CVE-2026-87659 says, quoted in full from the text published on the NVD:

"A critical authorization bypass vulnerability exists in the Management Server handling of Brocade Fabric OS versions before 10.0.1. A compromised switch connected to the fabric can transmit crafted inband Fibre Channel vendor-unique CT (Common Transport) management requests to bypass administrative authentication. Successful exploitation allows an unauthorized peer switch to execute administrative actions on the target device, including resetting administrative passwords, initiating system reboots, and triggering firmware downloads."

Look at the first word and then at the score. The vendor calls it critical in prose. The rating says 7.1: high. That mismatch inside a single document is the summary of this whole article, and the reason sits in the vector, which reads AV:L and PR:H: local vector, high privileges. Here is my reading, flagged as opinion: you already paid that toll. The "high privileges" CVSS demands are not those of one of your administrators; they are those of a switch that is part of the fabric. You connected it the day you racked the second one. CVSS measures what it costs the attacker to reach the door, and your architecture gave that part away at cabling time.

It is not alone. CVE-2026-87663 describes the inter-switch remote execution service: the receiving switch processes remote-command IPC frames "at an elevated processing level without proper verification of transmitted parameters", which allows an attacker to "execute arbitrary root commands locally or across other managed fabric members where remote execution functionality is enabled". In short: the fabric has a peer-to-peer administration channel, and that channel takes its peers at their word.

And sometimes the neighbour is a process inside the switch

What struck me most in the batch is CVE-2026-87664 (8.5). The web management daemon, when processing local IPC storage callbacks, "accepts and registers session structures including administrative role permissions, user identifiers, and authorization flags —without verifying the identity or authenticity of the sending process". It is not that authentication is badly implemented: there is no authentication between processes at all, and an administrator-role session is taken on trust from whichever process sends it.

Add CVE-2026-94578 (7.5): an already authenticated user who can return specific, crafted attributes (VSAs) from an external identity provider —RADIUS, LDAP, TACACS+ or a federated IdP— can bypass role restrictions during session establishment and gain root-equivalent chassis control. That is, the switch delegates authorization to your directory and then trusts whatever value comes back. If you have centralised infrastructure authentication —and you should— this is the advisory that lands on you rather than on the shop next door.

Forty are in the management plane. Three are not

I have read all 43 descriptions. The vast majority land in the management plane: REST API, the WebTools web interface, the SNMP daemon, diagnostic utilities, certificate management, the account subsystem, AAA integration, configuration download. My first reading was that none of them touched the data path. That is wrong, and it is worth naming the ones that do not fit there:

With the caveat that matters: all three are process crashes and memory corruption, which is to say availability. None of the 43 says your LUNs will corrupt. But "storage has stopped" is, for whoever is living through it, indistinguishable from the data being wrong, and that is no longer only a question of who gives orders to the switch.

The maintenance-window excuse does not hold

This is where I expected to find the real reason —"I cannot patch because taking the switch down means taking storage down"— and where I ran out of argument. The Fabric OS 10.0.x firmwareDownload documentation states that the command "will cause a warm/non-disruptive boot on the active CP". And it adds, with a qualifier that has to be respected: "On enterprise-class platforms, this command, by default, downloads the firmware image to both control processors (CPs) in rollover mode to prevent disruption to application services".

That qualifier matters, and I say it before drawing conclusions: "enterprise-class platforms" means dual control-processor directors. The typical switch in an SME or a software company is fixed-port with a single CP, and for those the page does not repeat the rollover sentence. What it does say for everything is the warm boot on the active CP, and what I could not confirm from that page is exactly what happens, platform by platform, with a single CP. So I stop where the documentation stops and not a step further.

The rest the page states plainly: it depends on High Availability support —"this operation depends on High Availability (HA) support. If HA is not available, use the -s option to upgrade the CPs one at a time"—; open SSH and telnet sessions are dropped; and the procedure is sequential: "for each standalone switch in your fabric, complete all firmware download changes before issuing the firmwareDownload command on the next switch to ensure a nondisruptive download". That last clause, the one I had skipped on a first skim, is what turns the ordering into the condition for nothing being cut. So with four switches you do not have an outage: you have one well-ordered afternoon. That is a scheduling problem, not an architectural one.

The real reason: that switch has no owner

If it is not the window and not the technical difficulty, what is left is the uncomfortable explanation: in the installations we have seen, the fibre switch belongs to nobody. It arrived inside the array project, it was configured by the integrator who installed the storage, the support contract is with the array vendor rather than with whoever writes the firmware, and in the inventory —if there is one— it shows up as "SAN", one line, no version.

That has a practical consequence worth knowing before you open a ticket: Fabric OS is resold under other names. Dell ships it as Connectrix B-Series and publishes its own release notes listing the versions it has qualified. The version Brocade publishes is not automatically the one you can install; you have to wait for your array vendor to qualify it. So "it is fixed" and "you can fix it" are not the same sentence, and the second one arrives later.

And there is a detail in the batch itself that complicates any quick answer. The 43 descriptions do not point at a single fixed version but at two branches: 20 point at "before 9.2.2d" and 22 at "before 10.0.1", and one is left over. the leftover is CVE-2026-87664, the only one of the 43 that names no fixed version at all: it lists 9.2.2d as an affected version. Twenty, twenty-two and one make 43. I do not know whether that is a drafting error in the advisory or a separate branch, and I am not going to invent an explanation; what is certain is that "we are on 9.2.2d" is not, on its own, a closed answer. You have to check advisory by advisory which of the two lists applies to you.

Four ownership questions (this is not a hardening checklist)

Nothing needs hardening today. What is needed is to know whose this is. Four questions, answerable in a short meeting:

Does distributed storage fix this? No. It moves it

It would be easy to close with "that is why we build Ceph over Ethernet". And it would be dishonest. Ceph does not remove the storage control plane: it moves it onto a network you already have. Its authentication system, cephx, had an authentication flaw of its own —CVE-2025-30156, through misuse of AES-CBC— which forced a new key type and a rotation of daemon keys; we wrote it up when we had to do it, including why rebooting the VM does not refresh the key. A control plane is a control plane, whether it rides on fibre or copper.

What does change is whose it is. On Ethernet, the storage management plane lands on a network your team already knows how to segment, monitor and update, with the same tools it uses for everything else; and you decide when to update, without waiting for a third party to qualify a version. In exchange, Ceph demands three real nodes, a dedicated network and people who know how to run it, and that is a genuine cost, not a footnote. If your array works and you have a support contract, switching technology over 43 management-plane CVEs is a bad reason. What you do have to change is the inventory line. And if you are mid-migration and planning to reuse the array, it also helps to know what gets left behind when you do.

Failure and breakdown

We repeat one line a lot: failure is inevitable, a breakdown is a design decision. Here you can see it unusually clearly. That one of your switches gets compromised some day is the failure, and no architecture prevents that. That this switch can then reset its neighbour's password, reboot it and push firmware at it is no longer a failure: it is what whoever designed the peer management protocol decided twenty years ago, and what you decide every time you plug one more into the fabric without writing down who administers it.

None of the 43 is critical. The 43 together say that your storage management plane has been out of the conversation for years. That part is.

Sources and method (verified 8 October 2026): the count of 43 Brocade Fabric OS vulnerabilities, their split by severity (25 high, 16 medium, 2 low; highest 8.7; none critical), by vector (33 AV:A, 9 AV:L, 1 AV:N; 5 requiring no privileges, 21 low, 17 high), by CWE and by version branch (20 "before 9.2.2d", 22 "before 10.0.1" —counting the "prior to" wording too— and 1 with no fixed version) was obtained by querying the public NIST NVD API and counting over the result; Brocade SANnav and Brocade ASCG entries published the same day were excluded from the count. Texts quoted in the body: CVE-2026-87684, CVE-2026-94585, CVE-2026-87671, CVE-2026-87665, CVE-2026-94582, CVE-2026-87660 and CVE-2026-87659, CVE-2026-87663, CVE-2026-87664 and CVE-2026-94578. Upgrade behaviour: the Fabric OS 10.0.x firmwareDownload page on Broadcom TechDocs. Rebadged resale and separately qualified versions are documented in the Dell Connectrix B-Series release notes. The cephx CVE cited is CVE-2025-30156, fixed in Ceph Squid 19.2.6 and Tentacle 20.2.4. Correction made before publishing: an earlier draft of this piece claimed none of the 43 left the management plane; that is false, and the three that do are named above. What we do not know: we found no public evidence of exploitation of any of the 43; we could not confirm from the cited page what firmwareDownload does exactly on fixed-port switches with a single CP; and we could not clarify why CVE-2026-87664 lists 9.2.2d as affected when twenty other advisories treat it as the fix.