Nobody Was Managing Agent Resources: 36 DoS Zero-Days in 16 Open-Source Agents

Aug 14, 2026 7 min read

This week at USENIX Security ‘26 in Baltimore, a Fudan University team presented what appears to be the first systematic security study of resource management inside LLM-based agents: Autonomy Comes with Costs: Detecting Denial-of-Service Vulnerabilities Caused by Resource Abusing in LLM-based Agents. The headline number is brutal. Fuzzing 20 of the most popular open-source agent frameworks in their default configurations, the researchers found 36 zero-day denial-of-service vulnerabilities in 16 of them. Fifteen of the affected projects carry more than 10,000 GitHub stars. Fifteen CVEs have been assigned so far. AutoGPT alone accounts for seven, with AgentScope next at five, then LangFlow, GPT-Researcher, SuperAGI, RagFlow, and LangChain-Chatchat.

Every one of those vulnerabilities is remotely reachable with a perfectly innocent prompt — no code injection, no prompt injection, no exploit chain. The attacker just asks the agent to do what it was built to do, and the agent exhausts its own memory or disk until the service stops answering. Availability is the agent security property that gets the least attention, and it is the one that breaks without a single malicious-looking action.

The three lifecycles, and the attacker each one creates

The paper’s core contribution is a taxonomy of how agent scaffolds manage resources, sorted by release timing. Each pattern gives an attacker a distinct exhaustion strategy (paper PDF):

Short-lived resources are allocated and released within a single turn (garbage-collected or explicitly freed). The attacker must exhaust everything in one prompt. The paper’s Case I shows how: an agent that iterates over LLM-generated URLs, fetches each, and loads the content into memory — a local variable, freed when the function returns. Asking it to “load website http://large_file.html 1000 times” in a single chat exhausts memory before any cleanup runs.
Long-lived resources persist across turns within one chat session and are released only when the session ends. The attacker accumulates consumption turn by turn. Case II is the one that should worry every agent builder: the agent appends user input, LLM plan, and tool output to an in-memory self.history buffer. Because that history is not sent back to the LLM by default, the model’s context window never constrains its growth — the buffer grows until memory dies, and the “context limit” everyone assumes will save them never triggers.
Full-lifecycle resources are allocated and never released, for the entire lifespan of the deployment. The attacker rotates sessions forever. The paper’s motivating example (CVE-2025-4**90, anonymized for responsible disclosure) is a mainstream agent whose download tool writes files that persist on disk across sessions: a 30-second timeout caps any single download at roughly 300 MB, but per-interaction limits are bypassed by creating a new session and downloading again, until the disk is gone.

Across the 20 agents, AgentDoS identified 2,025 potentially vulnerable resource operators, split 77.3% short-lived / 14.1% long-lived / 8.6% full-lifecycle — with 95.2% lifecycle-identification accuracy after manual verification. The full-lifecycle bucket is the interesting one: the paper’s manual analysis found 37.9% of never-released resources are files downloaded by tools that are “never deleted after download, remaining in the system indefinitely.” The rest are developer-facing logs.

What the fuzzer had to learn that other fuzzers couldn’t

Existing DoS fuzzing doesn’t transfer to agents, and the paper quantifies exactly how badly it fails. The prior state of the art for agent vulnerability discovery, AgentFuzz, detects only 3 of the 38 verified vulnerabilities in the researchers’ benchmark — 7.9% recall against AgentDoS’s 94.7%, with 100% precision for both.

The failure is instructive. AgentFuzz issues each prompt in a fresh chat session, so it structurally cannot accumulate long-lived resources across turns — 5 of its 35 false negatives. The other 30 come from having no evaluation of how much resource a prompt actually consumes, and no mutations aimed at resource intensity: its prompts reach the vulnerable code but don’t make the agent consume enough to trigger a DoS.

AgentDoS closes both gaps by treating the lifecycle as the primary analysis object. A static pass locates resource-consuming operations and classifies their lifecycle from the execution logic; an LLM then generates functionality-specific seed prompts (“download this file”) tuned to drive those sinks; two mutators refine seeds from complementary directions — functional semantics and resource intensity — and a lifecycle-aware scheduler decides whether to fire them in a fresh session or pile them into the same one. The resource bill is modest: 119 CPU-hours total, averaging 5.95 hours per agent, about 9.32M tokens and US$44.30 per agent at GPT-4.1 pricing as of August 2025. For $886 and a week of compute, one framework now finds what nobody else was looking for.

The part coverage will miss: this attack is stealthy by design

Two properties make resource-exhaustion attacks worse than their reputation suggests, and the paper spells both out.

First, there is no malicious action to detect. Unlike RCE or injection, resource abuse “often resembles benign user requests” — merely downloading a file for summarization. Some security-conscious developers put “re-check code before execution” instructions in the system prompt to intercept hostile intent; that interception never fires here because the request is legitimate in every observable sense. The agent executes it enthusiastically.

Second, attack re-delegation: the attacker consumes resources until usage sits just below the limit, then stops. The next benign user’s ordinary request tips the agent over the edge, and from the maintainer’s perspective the outage looks like it was caused by the legitimate user. The true attacker is invisible even in the post-mortem.

The same week this paper went public, the pattern’s live sibling hit the operational record: CISA added CVE-2026-9198 — an unauthenticated remote code execution chain in IBM’s LangFlow orchestration framework, CVSS 9.8 — to its Known Exploited Vulnerabilities catalog on August 4, 2026. The chain is ugly in a familiar way: /api/v1/auto_login mints SUPERUSER tokens to any network caller, and /api/v1/validate/code executes user code via exec() on default deployments (IBM advisory). LangFlow is also in the AgentDoS dataset — it shipped four resource-exhaustion findings with no CVEs assigned at paper time. Different bug classes, same substrate: agent orchestration platforms are live targets this month, and the resource-exhaustion class is the one that needs no exploit tooling at all.

What operators should change

The paper’s developer conversations produced real fixes, and they map cleanly onto what a scaffold should enforce:

Scope quotas to the resource lifecycle, not the request. AutoGPT’s response to its seven findings is the reference implementation: commit 57a06f70 (“Fixes for various DoS vulnerabilities”, PR #10798, Oct 2025) enforces a 100 MB per-file cap, a 1 GB total per execution directory, rotating log files at 10 MB, capped iteration counts and text lengths in LLM and parsing blocks — plus disk-usage checks before every write. Per-turn limits alone are the failure mode: the motivating vulnerability had a per-download timeout and still died to disk exhaustion because nothing bounded the aggregate.
Assume anything that outlives the request is an accumulator. Downloaded files, logs, tool outputs, session buffers — each is a full-lifecycle or long-lived resource until proven otherwise. If a buffer is never fed back to the model, the context window is not a bound; the only bound is the one you write.
Monitor usage and suspend on anomaly. Continuous resource monitoring with alerts or a storage-operation pause is the paper’s second recommended defense — it catches both direct exhaustion and the re-delegation variant, where the visible trigger is a legitimate user.
Keep the availability/autonomy tension explicit. Over-strict limits break legitimate long-horizon work — an agent doing a literature review legitimately needs to download many papers. The design problem is real, which is exactly why nobody solved it: the frameworks optimized for autonomy and never wrote the release policy.

The uncomfortable truth is that none of this is about the model. The model is the part everyone audits. The resource lifecycle — what the scaffold allocates, retains, and never releases — is the trust boundary nobody was checking, in the most popular agent projects on GitHub. In agent systems, the autonomy tax is paid in availability.

Nobody Was Managing Agent Resources: 36 DoS Zero-Days in 16 Open-Source Agents

The three lifecycles, and the attacker each one creates

What the fuzzer had to learn that other fuzzers couldn’t

The part coverage will miss: this attack is stealthy by design

What operators should change

Sources

Keep reading