CVE-2026-10853 is a high severity flaw (CVSS 7.5) in IBM MQ. An authenticated attacker with cluster access can cause a denial of service or possibly run code, because cluster command message lengths are not properly validated. IBM lists fixed levels for each release line, for example 9.4.0.26 and 10.0.0.5.
What's affected
The IBM security bulletin, which we fetched, was first published on 14 September 2026. It lists these affected versions: IBM MQ 9.1.0.0 to 9.1.0.37 LTS, 9.2.0.0 to 9.2.0.43 LTS, 9.3.0.0 to 9.3.0.41 LTS, 9.3.0.0 to 9.3.5.1 CD, 9.4.0.0 to 9.4.0.25 LTS, 9.4.0.0 to 9.4.5.1 CD, and 10.0.0.0. The affected component is the Server.
IBM's fixes are cumulative security updates: 9.1.0.38, 9.2.0.44, 9.3.0.42 and 9.4.0.26 for the LTS lines, and an upgrade to IBM MQ 10.0.0.5 for the 9.3 CD, 9.4 CD and 10.0.0.0 releases. IBM says there are no workarounds or mitigations.
Differences between sources. The record rates 7.5 with a CVSS vector that agrees with IBM's. The record lists the weakness as CWE-470, unsafe reflection. IBM's bulletin title says the queue manager is vulnerable to remote code execution, and its summary describes a heap buffer overflow in the cluster repository manager, while the bulletin lists the CWE as 470 as well. The wording of the cause and the CWE label do not match neatly, so rely on the version and fix details from the bulletin.
How to check if you're exposed
On each queue manager host, print the installed level:
dspmqver
Compare the version and fix level with the affected list above. Remember that an LTS line and a CD line have different numbering, so match on the line you installed.
Then find which queue managers belong to a cluster. The record says the attacker needs cluster access, so a queue manager outside any cluster has a much lower exposure. In the MQ explorer or with the command line you can display cluster queue managers:
echo "DISPLAY CLUSQMGR(*)" | runmqsc YOUR_QMGR
Replace the queue manager name with yours. Review which parties can join your cluster and which accounts have cluster channel authority.
What to do now
- Apply the fix for your line from the IBM bulletin: 9.1.0.38, 9.2.0.44, 9.3.0.42, 9.4.0.26, or upgrade to 10.0.0.5 for the CD and 10.0.0.0 releases.
- Patch full repository queue managers first, because the bulletin names the cluster repository manager.
- Restrict cluster membership and channel authentication so only known queue managers can connect.
- Review which accounts have authority over cluster channels and remove the ones that are not needed.
- Monitor queue manager restarts and error logs for unexplained crashes after you patch.
Why it matters
MQ clusters let queue managers share information about queues and each other, and they send cluster command messages to do it. Those messages carry lengths, and the bulletin says IBM MQ did not properly validate them. A wrong length can make the receiving code read or write the wrong amount of memory, which causes crashes at best and code execution at worst.
The prerequisite matters: a user with access to the cluster. That makes this an insider or compromised partner problem and not an internet one. Still, in organisations with many integrations, cluster membership grows over time and rarely shrinks.
Message brokers are central to many systems, so an outage here spreads. The lack of a workaround means patching is the only answer. The record does not mark this CVE as known exploited, and the bulletin does not say so either.
Try it yourself
See how this kind of finding shows up in a dependency workflow.
Click through it at your own pace, or open it full screen.
Quick check
Is there a workaround?
IBM lists none. Apply the fix for your release line.
Who can exploit it?
The record and bulletin describe an authenticated attacker with cluster access.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
