The recently disclosed MQ vulnerability to Slowloris attack (CVE-2025-36128) is a reminder that even mature messaging platforms like IBM MQ can be impacted by classic web-layer denial-of-service techniques. IBM’s security bulletin confirms that certain IBM MQ components are susceptible to a Slowloris-style attack that can exhaust resources and disrupt availability.

In this post, we’ll unpack what Slowloris is, how it relates to IBM MQ, what IBM is recommending, and how MQ teams can strengthen their monitoring and operations in response.

Slowloris is an application-layer denial-of-service (DoS) technique that targets HTTP servers. Instead of flooding the network with traffic, the attacker opens many HTTP connections and keeps them half-open by sending partial requests very slowly. The server holds these connections open, tying up resources until it can’t accept legitimate requests.

Because Slowloris uses minimal bandwidth and focuses on connection handling, it’s particularly effective against servers that:

• Allow many simultaneous connections
• Don’t aggressively time out slow or incomplete HTTP requests
• Rely on limited thread or connection pools for handling traffic

If those conditions are present, a single attacker can cause a denial of service without generating the obvious traffic spikes seen in traditional volumetric DDoS attacks.

For a deeper, vendor-neutral explanation of the technique, see Cloudflare’s overview of the Slowloris DDoS attack.

According to IBM’s official security bulletin, CVE-2025-36128 affects IBM MQ versions 9.1, 9.2, 9.3, and 9.4 LTS, as well as 9.3 and 9.4 Continuous Delivery (CD).

The issue is described as follows:

IBM MQ is vulnerable to a denial of service, caused by improper enforcement of the timeout on individual read operations. By conducting Slowloris-type attacks, a remote attacker could exploit this vulnerability to cause a denial of service.

IBM identifies the affected installable components as:

• REST API
• Console

These components are implemented using the IBM WebSphere Liberty profile that is shipped with IBM MQ.

From a risk perspective, IBM assigns a CVSS v3.1 base score of 7.5 (High) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, which reflects a high impact on availability with no confidentiality or integrity impact explicitly identified.

In practical terms, if an attacker can reach the MQ REST API or console endpoints, they may be able to hold many HTTP connections open using Slowloris-style behavior, consuming Liberty resources and potentially making those management interfaces unavailable.

The bulletin does not list a product code fix or configuration change within IBM MQ itself. Instead, it focuses on hardening the Liberty front-end using network and application security components. Specifically, IBM recommends the following approaches to protect Liberty from a Slowloris-style DoS:

1. Load balancer configuration
   If you place a load balancer in front of the Liberty profile used by IBM MQ, configure it to handle Slowloris-type attacks. Properly tuned HTTP profiles can ensure that only complete and valid HTTP requests are forwarded to Liberty, dropping partial or overly slow requests.
2. Reverse proxy
   A reverse proxy can buffer requests, enforce connection timeouts, and apply additional security rules. This helps shield the Liberty server from abusive connection patterns.
3. Web Application Firewall (WAF)
   A WAF can analyze HTTP traffic, detect suspicious patterns characteristic of Slowloris (numerous long-lived, partial requests), and block them before they ever reach Liberty.
4. Limit concurrent connections
   Implement per-IP or per-source limits on concurrent connections to prevent a single origin from hoarding all available connections.
5. Traffic rate limiting
   Apply rate limiting to constrain how many requests a single source can send within a given time window.

At the same time, the bulletin’s “Workarounds and Mitigations” section formally lists “None”, so organizations should treat the above measures as IBM’s primary guidance for reducing exposure and continue to monitor IBM security bulletins for any future updates.

For MQ administrators and security teams, this vulnerability sits at the intersection of infrastructure, application, and operations. Here are practical actions to consider, building on IBM’s bulletin and general Slowloris mitigation practices:

• Inventory where MQ REST and console endpoints are exposed.
  Identify which environments (production, test, DR) have the MQ REST API and console enabled, and through which hostnames, ports, and paths they are published.
• Evaluate existing proxies, load balancers, and WAFs.
  Confirm whether these layers already sit in front of Liberty for MQ, and whether they enforce:
  • Idle timeout and header-timeout rules
  • Limits on concurrent connections per IP
  • Rate limits for HTTP requests
• Align with security and network teams.
  Because many of IBM’s recommendations depend on external infrastructure, MQ teams should work closely with security and network engineering to tune those devices specifically for the MQ REST and console endpoints.
• Harden access paths.
  Where possible, restrict direct exposure of MQ management endpoints to the public internet. Use VPNs, private connectivity, or trusted jump-hosts to reduce who can even attempt a Slowloris-style attack.

While CVE-2025-36128 specifically targets the HTTP-based management surfaces of IBM MQ, the outcome is classic: reduced availability. To manage that risk, you need both preventive controls and strong operational visibility.

Specialized MQ monitoring and administration platforms, such as Avada Software’s Infrared360®, provide real-time monitoring and customizable alerts across IBM MQ environments, helping operations teams detect and respond quickly when connections, threads, or endpoints begin to misbehave. You can learn more about these capabilities on our IBM MQ monitoring and administration page.

By combining:

• The infrastructure-level protections IBM outlines,
• Thoughtful exposure and access control around REST and console endpoints, and
• Robust MQ-aware monitoring and alerting,

organizations can significantly reduce the operational impact of the MQ vulnerability to Slowloris attack, even before any future product-level updates are released.

CVE-2025-36128 does not change how IBM MQ moves messages, but it does highlight how its management interfaces—implemented on top of Liberty—can become a choke point if Slowloris-style attacks are not mitigated. Treat this as an opportunity to harden your HTTP front-end, verify your monitoring, and tighten the availability story around your MQ estate.