CVE-2026-12351 is not a flaw in the ordinary act of moving messages through an IBM MQ queue manager. It sits in a supplied installation verification test (IVT) application for the IBM MQ Resource Adapter for Jakarta Messaging. That distinction is important: organisations are exposed when they have deployed this EAR-based test application on a Jakarta EE application server, often while checking that the adapter and distributed transactions are configured correctly.
IBM MQ is enterprise messaging middleware: applications put work or data onto queues and other applications consume it independently. The product commonly connects transaction-heavy and mixed technology estates, which is why banks, payment operations, government bodies, manufacturers and other large organisations use it to link core systems. The affected adapter is the Java/Jakarta EE bridge between those applications and MQ, rather than a feature every MQ deployment necessarily runs.
A test servlet performs unsafe lookups
IBM says the IVT servlet processes Java Naming and Directory Interface (JNDI) lookups unsafely. JNDI is Java’s mechanism for resolving named resources, such as connection factories and message destinations. In this case, unsafe processing of a lookup can allow an unauthenticated remote party to cause arbitrary code execution on the application server hosting the deployed IVT application.
That gives an attacker a serious foothold without an account or user interaction, but it does require a reachable deployment of the IVT application. It does not establish that every network-reachable MQ queue manager is vulnerable. IBM’s bulletin identifies the affected component as Java messaging and assigns a CVSS 3.1 score of 9.8; its documentation also makes clear that the IVT is an installation-check application containing a servlet and a message-driven bean.
Public material does not disclose the vulnerable source, a patch diff, or precisely whether IBM fixed the issue by restricting lookup namespaces, validating names, removing attacker-controlled input, or another method. That means defenders should not treat a guessed configuration change as a substitute for the vendor fix.
Fixed releases are available, but no workaround is listed
The affected ranges are MQ 9.3.0.0 through 9.3.0.41 LTS; 9.3.0.0 through 9.3.5.1 CD; 9.4.0.0 through 9.4.0.25 LTS; 9.4.0.0 through 9.4.5.1, which IBM labels LTS; and 10.0.0.0. IBM’s own release material identifies 9.4.5.1 as a Continuous Delivery update, so that advisory label is inconsistent.
For 9.3 LTS, apply cumulative security update 9.3.0.42; for 9.4 LTS, apply 9.4.0.26. IBM directs 9.3 CD, 9.4 CD and 10.0.0.0 users to upgrade to 10.0.0.5. The fixed releases were available September 10, 2026, and the 9.4 fix list includes the related known issue DT473754 and CVE-2026-12351. IBM lists no workaround or mitigation.
Teams should inventory application servers as well as MQ versions, find deployed Resource Adapter IVT EARs, and remove or isolate test applications that are no longer needed while scheduling the update. Restricting access to the test endpoint is sensible exposure reduction, not a documented fix.
No confirmed attacks or public exploit
As of September 20, 2026, exploitation in the wild could not be confirmed, and no public proof of concept has been confirmed. The available CISA catalogue data did not list CVE-2026-12351 in the Known Exploited Vulnerabilities catalogue; that is not proof that unreported attacks have not occurred.
For operators, the practical message is narrow but urgent: a leftover verification application can become the internet-facing code-execution path, even when the messaging estate itself was the thing receiving attention. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs, which is particularly useful when exposure depends on an optional deployed component rather than a product name alone.
