CVE-2026-12628 is Critical, unauthenticated, and narrower than the score makes it sound. Here is exactly who is exposed, who is not, and what to lock down today.
Yes, it is really bad. It is also really narrow. Both are true at once, and the gap between them is where you make good decisions, so I am going to explain each as plainly as I can.
The bad part
CVE-2026-12628 is a pre-authentication bypass in the IBM Storage Protect FlashCopy Manager authentication path. IBM scores it 9.1 Critical with Privileges Required of None, which means a remote, unauthenticated attacker on the network can reach it. (It was published at 8.1 with Privileges Required Low and corrected to 9.1 on 23 June, which is the right call, since the description itself says "unauthenticated attacker.")
The working exploit is 76 bytes. It carries no username and no password, and it does not need to, because the check that should stop it does not check anything.
There is a hardcoded credential in the code, and it has been sitting there since version 6.1, late 2011 or so. The string is, you are not going to believe it, BUBBLEGUM. The credential is not even the worst part. The validation around it is broken three ways at once: the result of the comparison is discarded, the length it compares is never properly initialized, and one side of the comparison is never populated from the wire. Any one of those opens the door on its own. All three together mean the door was never built. When the handshake completes, the attacker holds a trusted session with SYSTEM-level access on the host.
On a backup and recovery host, that is the worst place to put a trust failure.
How this happened
This is one of the ones that always gets missed, because it was never meant to be a security gate. It got there by accident, and the accidental ones are always the worst. It began as an access gate between processes on the same host: a common known secret that local components present to each other. The secret was BUBBLEGUM.
The assumption was that only local processes could ever know it, because it lives in a binary that only runs locally. That assumption collapsed three ways. The dsmcad callback listener binds to 0.0.0.0, every interface, not loopback, so anything on the segment can reach it. The string pulls straight out of the binary for anyone holding the installer, a free download from IBM Fix Central. And the broken check above means the secret is not even necessary, the validation that should demand it does not demand anything. The name says it all: BUBBLEGUM was never meant to guard anything. It escaped the day the listener was bound to every interface instead of loopback.
The not terrible things.
This only fires on FlashCopy Manager standalone deployments, the hardware-snapshot configurations. They are not common. Most Storage Protect estates never run one. But where they exist they are almost always protecting the most business-critical components in the building, the large databases and applications where streaming backup is too slow and array snapshots are the only practical option. They also tend to carry a dsmcad scheduler service for reporting and central management, and that scheduler is what puts a listener on the network in the first place. Small population, concentrated exactly where it hurts.
The thing to take away: the trigger is a configuration, not the product. The vulnerable path only comes alive when dsm.opt contains TCPServeraddress FLASHCOPYMANAGER. That one line is the gate. I confirmed that in the code and in testing, so this is not every Storage Protect install being at risk, it is the standalone FlashCopy Manager path and the hosts that run it.
What it does not affect
I ran the exploit directly against the common configurations. These were confirmed non-reactive in testing:
- Native Backup-Archive client, standard file backup to a Storage Protect server
- Native Data Protection for SQL, streaming to the server rather than through FCM
- Data Protection for VMware data movers
- LAN-free and Storage Agent environments, where
dsmstais a separate binary that still speaks TCP/SSL to the real server
The common thread: anything pointing at a real Storage Protect server over the normal client-server protocol never touches the vulnerable code. The exploit needs the FlashCopy Manager virtual server path, and that path only exists in standalone snapshot mode. If you run TDP for SQL or Exchange on top of FCM hardware snapshots, you inherit the exposure through that FCM configuration. The streaming, native deployments do not.
How to find your exposure
A host is in scope only when all of these are true at once: it runs FlashCopy Manager or Storage Protect Snapshot standalone on Windows, its dsm.opt contains TCPServeraddress FLASHCOPYMANAGER, and its dsmcad listener is reachable on the network. If a host fails any one of those, it is not in scope.
To find them, sweep the option files across your Windows estate for TCPServeraddress FLASHCOPYMANAGER. That is your in-scope list. Then check which of those hosts run a dsmcad scheduler service, and confirm what it is actually listening on with netstat -ano, Get-NetTCPConnection, or your EDR asset inventory. Do not assume the port number, confirm the listener that is actually bound. That gives you both who is vulnerable and what is reachable.
What to do
Apply IBM's 8.2.1.1 Windows iFix on the in-scope hosts. That closes it.
One naming snag to watch: IBM ships the Windows fix under the Backup-Archive Client fixing level, not under Snapshot, so do not skip it because the label says Backup-Archive Client. It patches the Windows code path the affected FlashCopy Manager configuration uses. The bulletin lists supported 8.1 and 8.2 levels as affected, and since the credential goes back to 6.1, do not assume older unsupported FlashCopy Manager builds are safe just because they are not in that table.
If you cannot patch right away, cut the attack surface at the network. The way in is the dsmcad listener, which lives in the 158x port range (httpport defaults to 1581). Confirm your exact ports from the steps above, then restrict inbound so those listeners are reachable only from the narrow backup and management scope that actually needs them. They have no business being reachable from general server networks, workstation VLANs, or broad internal ranges. Segmentation is not a fix, but for a service that should never have been broadly exposed, it is a strong and immediate control.
One more thing for any host that was broadly reachable: do not stop at patching. Look at recent connections to the dsmcad listener and at any trusted session or proxy state that looks out of place. The logging may be thin, but a host that was open to the segment is worth a proper look, not just a patch.
If you are not on Windows
Actually I had some lawyerish mumbo jumbo text here at first. Here's the truth, it only works on windows, it has no relevance or function in any other codebase. But it's just so grained deep into the auth system that it's everywhere just by age or something, so if you see is somewhere else, you can just ignore it.
For the one-line version, for the people who just need the call: if you run FlashCopy Manager standalone on Windows, the kind with TCPServeraddress FLASHCOPYMANAGER in dsm.opt, patch to 8.2.1.1 now, or lock down the dsmcad 158x ports until you can. If you do not run FCM standalone, you can read this with interest rather than alarm. The password was real. The check was not. The blast radius is narrow. Make sure you are standing outside it.
