SURIQ
Dell has patched a flaw in its PowerStore storage arrays that hands an attacker the one thing a storage admin never wants to give up: the credentials that control the whole array. Tracked as CVE-2026-58574 and rated 9.8 on the CVSS scale, the bug lets someone with a network path to the array's management interface, and no account on it, read files straight off the appliance. Some of those files hold credentials, and those credentials grant full administrative control. So a bug that looks on paper like a read-only information leak is, in practice, a route to owning every byte of storage the array serves.
Two things about this one deserve more attention than the score alone. The first is why an unauthenticated read scored a near-maximum 9.8. The second is that the severity you actually face depends almost entirely on who can reach that management interface today, and that a patch closes the door without recovering what may already have walked through it.
What Dell disclosed
The flaw is a missing authentication check on a critical function, the classic case of a sensitive operation that never asks who is calling. Dell, which assigned the CVE for its own product, spells out the chain: someone who can talk to the array's management network, holding no account on it, pulls sensitive files off the box, and among those files are secrets that hand an administrator's control over the whole array. No login. No user interaction. Reachable across the network. Those properties are what push the base score to the top of the range, a near-maximum 9.8.
It affects the PowerStore T appliance family across the range, from the entry 500T up through the 9200T. Dell ships two supported code trains, and each has its own fixed build. Check which line your array runs before you schedule the update.
| PowerStore OS line | Status | Fixed build |
|---|---|---|
| 4.1.x | Affected below the fix | 4.1.0.6-2771237 |
| 4.3.x | Affected below the fix | 4.3.1.2-2771239 |
Dell made the record public on August 26, 2026, in advisory DSA-2026-330, and it reached the wider vulnerability feeds a few days later. There is no separate workaround: the fix is the upgrade.
Why a read-only bug earns a 9.8
Plenty of information-disclosure flaws leak logs, version strings, or configuration trivia and land in the mid single digits. This one does not, because of what sits in the files it exposes. By Dell's account, the readable data includes credentials good for administrator-level control. Reading the filesystem is only the entry; the credential is the payload; command of the array is the end state. The confidentiality, integrity, and availability impacts are all rated high because an attacker who reads those secrets does not stay a reader. They can log in as an administrator and do anything the array supports, which on a storage platform means the data itself.
That chain is the reason the usual advice, upgrade and move on, is not enough here. Patching removes the unauthenticated read. It does nothing about a credential that was already read during the window the interface was reachable. If your management interface has been exposed to networks you do not fully trust, treat the stored credentials as potentially known and rotate them after you patch. A fixed build does not un-leak a secret.
Who is actually exposed
The whole severity rests on one precondition: an attacker needs a network path to the array's management interface. That interface is meant to live on an isolated administrative segment, not on a production or user subnet, and certainly not on anything internet-facing. Where that separation holds, the practical exposure is far smaller than 9.8 suggests, because the set of hosts that can even send the array a packet is tightly held.
Where it does not hold, the precondition collapses to "can reach the box." Flat networks that never segmented storage management, a management VLAN that quietly became routable, a compromised jump host inside the management segment, or an insider with ordinary network access all put the interface within reach. This is the same exposure shape we flagged on the Red Hat Multicluster Engine proxy flaw: the bug is severe on paper, but the real question is whether the sensitive endpoint is reachable from somewhere you do not control. The audit worth running today is not "are we patched" alone. It is "which hosts can currently open a connection to each array's management IP, and would we notice if one of them did."
Exploitation status
As of publication there is no public proof-of-concept, the flaw is not in CISA's Known Exploited Vulnerabilities catalog, and there is no report of exploitation in the wild. That is the calm reading, and it is worth stating plainly rather than inflating. It is also a window, not an all-clear. The mechanism is simple to describe once known, the affected product is widely deployed in enterprise datacenters, and the reward, full control of a storage array, is high. Treat the quiet as time to move, not proof that nobody will.
Patch, then rotate. A patch does not un-leak a credential.
Three steps, in order of how fast they close real risk:
- Update the PowerStore OS to
4.1.0.6-2771237on the 4.1 line or4.3.1.2-2771239on the 4.3 line, per Dell's advisory. This removes the unauthenticated read. - Rotate the array's credentials after patching if the management interface was ever reachable from an untrusted network. The upgrade does not recover secrets that may already have been read.
- Confirm the management interface is segmented so only a small, known set of administrative hosts can reach it. This shrinks the blast radius of the next flaw in the same surface, not just this one.
For detection, storage management planes are quiet by nature: the same few operators, the same few hosts, day after day. That makes anomalies easy to spot if you are watching. Alert on connections to the array's management IP from any source outside your administrative allowlist, and treat unexpected authentication or session activity on the array as worth a look, because a normal week has almost none of it. This is the second Dell storage appliance authentication problem we have covered in recent months, after an authorization flaw in the Data Domain backup line, and it rhymes with the broader run of management interfaces leaking credentials. The pattern is consistent: the appliance is trusted because it sits deep inside, so its management surface becomes the soft target. Segment it like you mean it.