Queue poisoning is the abuse of a shared request pipeline so that attacker-controlled bytes are processed as part of another user’s or another request’s traffic. It is dangerous because the attacker does not need direct code execution to influence what the back-end sees next.
Expanded Definition
Queue poisoning refers to a class of request-path abuse in which data placed into a shared queue, buffer, job stream, or message pipeline alters how a later consumer interprets the next request. In practice, the attacker is not trying to own the system outright; the goal is to smuggle attacker-controlled bytes into a processing flow that was assumed to be isolated. That makes the term relevant anywhere traffic is batched, multiplexed, retried, or handed between services.
In security terms, queue poisoning sits close to request smuggling, desynchronisation, and other state-confusion failures, but the emphasis is on the poisoned queue or pipeline rather than the protocol trick alone. Definitions vary across vendors and incident write-ups, because some teams use the term for message queues only, while others apply it more broadly to shared ingress, worker queues, and asynchronous back-end processing. The most useful interpretation is operational: any design where one actor can influence what another actor’s request context will become is exposed. The NIST Cybersecurity Framework 2.0 is relevant here because it emphasizes maintaining trustworthy, well-governed system and data flows across assets and services.
The most common misapplication is treating queue poisoning as a generic injection issue, which occurs when defenders miss the shared-state condition that allows one request to contaminate another request’s processing path.
Examples and Use Cases
Implementing shared request processing rigorously often introduces latency, buffering overhead, and extra validation steps, requiring organisations to weigh throughput against stronger isolation and observability.
- A reverse proxy accepts pipelined HTTP traffic and forwards bytes to the origin in a way that leaves residual data in the connection buffer, so the next request is parsed with attacker-influenced content.
- A message queue used by multiple services lacks per-tenant separation, allowing one producer to insert crafted payloads that alter how a later consumer interprets headers or task metadata.
- An API gateway reuses request context across retries, and malformed input from one call becomes part of the next call’s upstream representation, creating cross-request contamination.
- A shared worker pool processes asynchronous jobs from different users, and a poisoned job envelope changes the routing, identity, or parameters of a subsequent job.
- In agentic AI or tool-using systems, a shared context queue can carry attacker-controlled instructions into a later model or agent invocation, which is why OWASP guidance for LLM applications is often consulted when queues feed prompt construction or tool execution.
These examples are rarely visible as a single broken line of code. More often, they emerge from weak boundaries between producers, intermediaries, and consumers, especially where input validation is done only at the edge and not again at the point of consumption.
Why It Matters for Security Teams
Queue poisoning matters because it breaks the assumption that a request is self-contained. Once that assumption fails, authentication checks, request logging, rate limiting, and content filtering can all be applied to the wrong message or the wrong actor. That creates integrity risk first, but it can quickly become an availability and authorization problem when poisoned entries trigger malformed retries, downstream parsing errors, or privilege-bound actions in a back-end worker.
For identity-heavy systems, the impact can be even more serious. A poisoned queue entry may carry a session identifier, user context, token reference, or workflow step that is later trusted by another service. In NHI environments, the same pattern can affect service accounts, workload identities, or agent actions when shared orchestration layers fail to isolate one execution from the next. The practical lesson is that queue boundaries must be treated as security boundaries, not just performance boundaries. Teams should validate at ingress, re-validate at consumption, and ensure that correlation identifiers, auth context, and payload data cannot be repurposed across requests. Guidance from the OWASP ecosystem is especially useful where shared pipelines feed web applications, APIs, or agentic systems. Organisations typically encounter queue poisoning only after a strange downstream inconsistency, at which point containment, replay analysis, and queue hygiene become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Protects data in transit and flow integrity across shared processing paths. |
| OWASP Agentic AI Top 10 | Covers shared context and tool-use risks where poisoned prompts or jobs can affect agents. | |
| OWASP Non-Human Identity Top 10 | Applies when poisoned queues can alter workload identity, secrets, or service-to-service trust. | |
| NIST AI RMF | Supports governance of AI data flows where queued inputs can change model or agent behavior. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust segmentation helps prevent one request path from contaminating another. |
Bind identities and secrets to specific workloads so queue data cannot be reused out of context.
