Back

LLM10:2025 Unbounded Consumption - Overview

Table of Contents

What is Unbounded Consumption?

Unbounded Consumption occurs when an application lets clients drive a Large Language Model to perform inference — and the work it will do, the resources it will spend, and the money it will cost — without effective limits. Every request an LLM serves consumes compute (usually GPU), memory, wall-clock time, and, on a metered API, real currency billed per token. When there is no ceiling on how much of that a single caller can trigger, an attacker (or a buggy client) can convert a trickle of cheap requests into a flood of expensive work.

The 2025 edition of the OWASP Top 10 for LLM Applications introduced this category by merging and broadening two 2023 entries: LLM04: Model Denial of Service and LLM10: Model Theft. The insight behind the merge is that both problems share one root cause — the system permits inference (or the extraction of a model's value) to proceed without bounds. Whether the attacker's goal is to knock the service offline, run up its cloud bill, or clone the model by querying it to exhaustion, the missing control is the same: a limit on consumption.

Core Concept

A single inference request costs:  tokens_in + tokens_out  ->  GPU-seconds  ->  $$$

  Bounded service                        Unbounded service
  ---------------                        -----------------
  input capped (tokens/bytes)            accepts megabyte prompts
  output capped (max_tokens)             lets the model run until it stops
  rate limited (req/min per key)         unlimited requests per caller
  concurrency capped                     unlimited parallel in-flight work
  cost budget + billing cap              no ceiling on spend
  timeouts + backpressure                requests pinned open indefinitely
  auth required                          anonymous, uncounted usage

  Result: predictable cost & latency     Result: DoS, "denial of wallet",
                                                  and model extraction

Unbounded Consumption is best understood as three overlapping harms that all stem from uncontrolled inference:

Why It's Different for LLMs

Classic denial-of-service is about packets-per-second against cheap request handlers. LLM inference changes the economics in ways that make consumption attacks unusually potent:

Why Does This Matter?

Unbounded Consumption is ranked LLM10 in the 2025 list. A low list position is not a low severity — it reflects how the category was folded together late in the ranking process. In practice this is one of the most reliably exploitable issues in production LLM systems, because it needs no jailbreak, no clever prompt, and often no authentication: it only needs the ability to send requests.

Business Impact

Technical Impact

Technical Context

The Cost of a Single Inference

To reason about consumption you have to reason about what one request actually spends. For a token-based model the dominant factors are the number of input tokens (the prompt, including any retrieved context and conversation history) and the number of output tokens the model generates. Output tokens are usually the more expensive half, because each one is produced by a separate forward pass and, on hosted APIs, is often priced higher than input.

request_cost  ≈  price_in  ×  tokens_in  +  price_out  ×  tokens_out

Amplification levers an attacker controls:
  tokens_in    long documents, deep chat history, RAG context stuffing
  tokens_out   "keep going", "repeat", "list all", high max_tokens
  fan-out      one prompt -> many tool calls / sub-queries / agent steps
  concurrency  N identical expensive requests in parallel
  batch        multimodal payloads (large images, long audio) per request

The Three Harm Axes

AxisAttacker goalSucceeds when…Primary control
Denial of ServiceMake the service slow or unavailableCapacity is finite and unprotectedRate limits, concurrency caps, timeouts, queue limits
Denial of WalletGenerate a ruinous billBilling is metered / autoscaling is uncappedCost budgets, billing caps, per-tenant quotas, alerts
Model theftReplicate the model or its dataQuery volume is unlimited and unloggedAuth, quotas, anomaly detection, watermarking, logging

A control that stops one axis does not automatically stop the others. Aggressive rate limiting curbs DoS and DoW but a patient attacker can still extract a model slowly, under the radar, unless volume and pattern anomalies are also monitored. This is why the prevention guidance is explicitly layered.

Where Unbounded Consumption Hides in an LLM Stack

Real-World Impact

The incidents below are described as verifiable classes of event drawn from published research and widely reported operational patterns. Specific dollar figures and internal details vary by victim and are frequently not disclosed, so none are invented here.

Case Class 1: Denial of Wallet on Metered LLM and Cloud APIs

Pattern: An application exposes a hosted-model backend (or serverless functions that call one) without per-caller cost limits. An attacker — or an accidental client-side retry loop — drives sustained, high-volume, high-token requests.

Outcome: The platform autoscales and keeps serving, so availability looks healthy while token spend climbs far above budget. Operators discover the problem through a billing alert rather than an outage. This is the same dynamic that the cloud-security community has long documented as "denial of wallet" against pay-as-you-go serverless functions; hosted LLM pricing makes it sharper because a single request can bill for a very large number of output tokens.

Root cause: No cost budget, no billing cap, no per-tenant quota; autoscaling optimised purely for availability.

Case Class 2: Model Extraction / Functional Distillation via a Public API

Pattern: A model is reachable through an inference API with generous or unlimited query volume. An attacker systematically queries it and stores the input/output pairs, then trains a smaller "student" model on that data to approximate the target's behaviour.

Outcome: A functional copy of a proprietary model at a fraction of the original training cost. This is not hypothetical: the foundational academic result "Stealing Machine Learning Models via Prediction APIs" (Tramèr et al., USENIX Security 2016) demonstrated extraction against prediction APIs, and subsequent work has shown that modern LLMs can be partially distilled or have specific parameters extracted through query access alone. Providers' terms of service now routinely prohibit using outputs to train competing models precisely because query-based cloning is practical.

Root cause: Unlimited, unauthenticated, or unmonitored query access — consumption of the model's value without bound.

Case Class 3: Sponge Examples (Energy-Latency Attacks)

Pattern: Instead of many requests, an attacker crafts individual inputs designed to maximise the work per request — inputs that push a model toward its worst-case compute and latency. The research literature calls these "sponge examples" (Shumailov et al., 2021), which showed inputs that dramatically increase the energy and time a neural network spends on a single inference.

Outcome: A small number of requests inflicts outsized load, defeating naive rate limits that count requests but not the cost of each one.

Root cause: Controls that bound request count but not request cost (tokens, sequence length, generation length).

Case Class 4: Long-Context and Unbounded-Output Resource Exhaustion

Pattern: An endpoint accepts very long prompts or permits very long generations. Because attention cost scales superlinearly with sequence length, a handful of maximum-length requests saturates GPU memory and stalls the worker pool.

Outcome: Latency spikes and timeouts for all users; in memory-constrained deployments, worker crashes. Retries then compound the load. This mirrors the classic algorithmic-complexity DoS pattern (of which ReDoS is the best-known relative) applied to transformer inference.

Root cause: No input token/byte limit and no output max_tokens cap.

Prevalence

Unbounded Consumption is extremely common in real deployments, for a straightforward reason: the insecure configuration is the easy one to ship. Wiring a user text box to a model API and returning the response "just works" in a demo, and nothing in that happy path forces a developer to add token limits, quotas, or budgets. Those controls only become obviously necessary after the first surprise bill or the first outage.

Several factors keep prevalence high:

Because exploitation requires only the ability to send requests — no authentication bypass, no jailbreak — the barrier to entry is among the lowest of any category in the list.

Common Misunderstandings

"Autoscaling protects us."

Autoscaling protects availability, and in doing so it converts a denial-of-service into a denial-of-wallet. Scaling to meet malicious demand means paying to serve malicious demand. Without a cost ceiling, autoscaling is an amplifier, not a defence.

"We rate-limit requests, so we're covered."

Counting requests is necessary but not sufficient. A single request can be arbitrarily expensive (a maximum-length prompt, an unbounded generation, a sponge input). Effective limits must bound the cost of each request — input tokens, output tokens, and concurrency — not just how many requests arrive.

"This is just classic DoS with a new name."

The DoS axis is familiar, but two things are genuinely new: the denial-of-wallet failure mode, where the attack wins while the service stays up, and model theft, where the resource being consumed without bound is the model's intellectual property itself. Neither is addressed by traditional network-DoS thinking.

"Model theft requires stealing the weights."

Functional theft needs only query access. An attacker who can collect enough input/output pairs can train a student model that approximates the target's behaviour, or infer sensitive properties of the training data, without ever touching the weight files.

"Only anonymous endpoints are at risk."

Authentication helps attribute and bound usage, but an authenticated attacker — or a compromised API key, or a legitimate but buggy integration — can consume just as much. Per-identity quotas and budgets are still required behind the login.

Self-Assessment

Use these questions to gauge your exposure. Each "no" is a gap an attacker (or an accident) can exploit.

Key Takeaways

Next Steps