Description

IBM MQ Agent CD: v1.0.0, v1.0.1, v2.0.0, v2.0.1 An authenticated user with a valid session cookie can submit arbitrarily large or computationallyexpensive requests that cause the LLM agent workers to be held for extended periods — rangingfrom tens of seconds to over ten minutes per request. When multiple such requests are sentconcurrently, the agent worker pool becomes exhausted, causing all other IBM MQ Console users toexperience degraded performance or complete unavailability of the AI Agent feature.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-04T16:17:24.923Z",
  "pubdate": "2026-09-04T16:17:24.923Z",
  "executiveSummary": "The IBM MQ Agent CD versions 1.0.0, 1.0.1, 2.0.0, and 2.0.1 are susceptible to a Denial of Service (DoS) vulnerability originating from improper resource management in the LLM agent worker pool.\nAn authenticated attacker possessing a valid session cookie can trigger this vulnerability by submitting specially crafted requests characterized by excessive size or high computational complexity.\nThis behavior forces the agent worker processes to remain occupied for extended durations, ranging from tens of seconds to upwards of ten minutes per individual request.\nThe primary impact is the exhaustion of the agent worker pool, leading to significant performance degradation or total unavailability of the AI Agent feature for all legitimate IBM MQ Console users.\nThis vulnerability is categorized as a resource exhaustion flaw, enabling a motivated actor to disrupt service continuity via a low-complexity attack vector that requires only standard authenticated access.\nThe risk implication is high for environments relying on the availability of AI-driven automation within the IBM MQ ecosystem, as it allows a single user to effectively perform a localized DoS attack against the management interface.",
  "technicalDetails": "The vulnerability resides within the request processing logic of the IBM MQ Agent CD component. The architecture employs a worker pool pattern to handle incoming requests directed toward the AI Agent subsystem. A failure to implement adequate input validation, rate limiting, or per-request resource quotas allows for the subversion of these workers.\nWhen an authenticated user transmits an arbitrarily large or computationally expensive payload, the LLM agent workers are forced to dedicate disproportionate CPU, memory, or time-slice resources to fulfill the request. Because these worker processes are held in a synchronous or blocking state while processing the heavy payload, they become unavailable to service legitimate concurrent requests.\nThe attack flow follows a predictable pattern: 1) The attacker authenticates to the IBM MQ Console to obtain a valid session cookie. 2) The attacker identifies the endpoint responsible for AI Agent processing. 3) The attacker submits a series of concurrent, resource-intensive requests designed to maximize processing latency. 4) The worker pool reaches maximum capacity as each worker is occupied by the attacker's tasks. 5) Subsequent legitimate requests from other authenticated users are queued or dropped, resulting in service timeout or complete system unavailability.\nThe root cause is a lack of architectural constraints on request complexity. The application fails to impose bounds on the input size or the execution time allotted to a single agent worker thread. By design, LLM-based systems can be inherently computationally expensive; however, the absence of circuit breakers or request timeouts allows an attacker to manipulate the underlying worker availability.\nThe affected versions include IBM MQ Agent CD v1.0.0, v1.0.1, v2.0.0, and v2.0.1. Exploitation is limited to users who have successfully authenticated, meaning the attacker must be a recognized entity within the system. No administrative privileges are necessarily required to execute the exploit, provided the attacker has permission to interact with the AI Agent features. Post-exploitation, the system remains in a degraded state until the malicious requests complete or the worker pool processes are forcefully terminated/recycled, which could lead to a cascading failure of the IBM MQ Console interface if the resource contention impacts shared application resources."
}