GHSA-j659-8xh6-5pq5: vLLM unpriced models silently

Q: Is GHSA-j659-8xh6-5pq5 actively exploited?

No confirmed active exploitation of GHSA-j659-8xh6-5pq5 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-j659-8xh6-5pq5?

1) Upgrade atomic-agents-stack to 1.1.0 or later, which fixes `_estimate_batch_cost` to use `PRICING.get(model, _costs._fallback_pricing())['output']`, matching the already-correct sibling function `dream._estimate_dream_cost`. 2) Until patched, inventory every model identifier passed into batch/parallel-delegate calls and confirm each exists in the framework's `PRICING` table — treat any unlisted model (self-hosted, Ollama, vLLM, or a brand-new provider SKU) as unprotected by the cost cap. 3) Add out-of-band spend monitoring (provider billing alerts, API usage dashboards) as a compensating control for any workload using unlisted models, since the in-framework guardrail cannot be trusted for them. 4) If you maintain a fork or custom pricing table, add the conformance test the advisory recommends: assert an unknown-model batch reserves a non-zero amount and that an over-cap unknown-model batch raises `CostGuardrailBlocked`. 5) Review logs/telemetry for `_check_batch_reservation` early-returns as a detection signal that the guardrail was silently bypassed.

Q: What systems are affected by GHSA-j659-8xh6-5pq5?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, model serving.

Q: What is the CVSS score for GHSA-j659-8xh6-5pq5?

No CVSS score has been assigned yet.

CISO Take

A logic defect in atomic-agents-stack's cost guardrail lets any model missing from its hardcoded pricing table default to a $0.00 output cost, which causes the batch-cost reservation check to skip itself entirely — the exact defense meant to stop parallel agent runs from collectively blowing past a configured daily spend cap. With 128 downstream dependents and 92 other CVEs already logged against this package, any team running self-hosted models (Ollama, vLLM) or a newer provider SKU through this framework's fan-out/delegate batch feature is currently unprotected, even though `daily_cap_usd` appears active in their config. There's no public exploit, scanner template, or KEV listing, and triggering it requires control over the model argument rather than remote unauthenticated access, so this reads as a silent control failure rather than an actively exploited vector — but the exposure is financial, not just technical, and invisible until an invoice arrives. Upgrade to 1.1.0, which fixes the fallback pricing lookup to mirror the already-correct `dream._estimate_dream_cost` path; until then, audit `cost_guardrails` configs for any model identifiers absent from the built-in `PRICING` table and treat those workloads as effectively unmetered.

Sources: GitHub Advisory ATLAS

What is the risk?

High risk for cost/availability rather than confidentiality or integrity. Exploitability is low-complexity (no auth bypass or code execution needed — just naming an unlisted model and issuing a parallel/fan-out batch), but it requires operator- or attacker-influenced control over the `model` parameter and a workload that legitimately uses self-hosted or newly-released models. There is no CISA KEV listing, no EPSS score, and no public PoC or Nuclei template, so this is not an actively exploited or trivially scannable vulnerability — it is a silent control-failure bug most likely to surface as an unexpected bill rather than a breach. The severity rating of 'high' reflects that the failure mode defeats the *only* stated defense (`_check_batch_reservation`) against a documented race condition, meaning the guardrail can go from 'protecting' to 'no-op' without any error, log entry, or user-visible signal.

How does the attack unfold?

Unlisted Model Selection

An operator or a user with control over the `model` argument configures a batch/delegate job to use a model absent from the hardcoded PRICING table (self-hosted, Ollama/vLLM, or a new provider SKU).

AML.T0081

Parallel Batch Fan-out

The job spawns multiple parallel helper/delegate agents that each read the identical pre-batch on-disk cost total before any reservation is committed.

AML.T0034.002

Reservation Bypass

`_estimate_batch_cost` returns 0.0 for the unknown model, so `_check_batch_reservation` early-returns and never enforces the cap for any of the parallel workers.

Cost Cap Overrun

The batch's collective spend exceeds `daily_cap_usd` with no error or block, resulting in unbounded billing exposure discovered only after the fact.

AML.T0034

Unlisted Model Selection

An operator or a user with control over the `model` argument configures a batch/delegate job to use a model absent from the hardcoded PRICING table (self-hosted, Ollama/vLLM, or a new provider SKU).

AML.T0081

Parallel Batch Fan-out

The job spawns multiple parallel helper/delegate agents that each read the identical pre-batch on-disk cost total before any reservation is committed.

AML.T0034.002

Reservation Bypass

`_estimate_batch_cost` returns 0.0 for the unknown model, so `_check_batch_reservation` early-returns and never enforces the cap for any of the parallel workers.

Cost Cap Overrun

The batch's collective spend exceeds `daily_cap_usd` with no error or block, resulting in unbounded billing exposure discovered only after the fact.

AML.T0034

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	<= 1.0.0	`1.1.0`
92.7K 95 dependents Pushed 5d ago 26% patched ~47d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Upgrade atomic-agents-stack to 1.1.0 or later, which fixes _estimate_batch_cost to use PRICING.get(model, _costs._fallback_pricing())['output'], matching the already-correct sibling function dream._estimate_dream_cost. 2) Until patched, inventory every model identifier passed into batch/parallel-delegate calls and confirm each exists in the framework's PRICING table — treat any unlisted model (self-hosted, Ollama, vLLM, or a brand-new provider SKU) as unprotected by the cost cap. 3) Add out-of-band spend monitoring (provider billing alerts, API usage dashboards) as a compensating control for any workload using unlisted models, since the in-framework guardrail cannot be trusted for them. 4) If you maintain a fork or custom pricing table, add the conformance test the advisory recommends: assert an unknown-model batch reserves a non-zero amount and that an over-cap unknown-model batch raises CostGuardrailBlocked. 5) Review logs/telemetry for _check_batch_reservation early-returns as a detection signal that the guardrail was silently bypassed.

How is it classified?

DoS Agent Framework AML.T0034 - Cost Harvesting AML.T0034.002 - Agentic Resource Consumption

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

NIST AI RMF

MANAGE-4.1 - Post-deployment AI risks are monitored and managed

OWASP LLM Top 10

LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is GHSA-j659-8xh6-5pq5?

A logic defect in atomic-agents-stack's cost guardrail lets any model missing from its hardcoded pricing table default to a $0.00 output cost, which causes the batch-cost reservation check to skip itself entirely — the exact defense meant to stop parallel agent runs from collectively blowing past a configured daily spend cap. With 128 downstream dependents and 92 other CVEs already logged against this package, any team running self-hosted models (Ollama, vLLM) or a newer provider SKU through this framework's fan-out/delegate batch feature is currently unprotected, even though `daily_cap_usd` appears active in their config. There's no public exploit, scanner template, or KEV listing, and triggering it requires control over the model argument rather than remote unauthenticated access, so this reads as a silent control failure rather than an actively exploited vector — but the exposure is financial, not just technical, and invisible until an invoice arrives. Upgrade to 1.1.0, which fixes the fallback pricing lookup to mirror the already-correct `dream._estimate_dream_cost` path; until then, audit `cost_guardrails` configs for any model identifiers absent from the built-in `PRICING` table and treat those workloads as effectively unmetered.

Is GHSA-j659-8xh6-5pq5 actively exploited?

No confirmed active exploitation of GHSA-j659-8xh6-5pq5 has been reported, but organizations should still patch proactively.

How to fix GHSA-j659-8xh6-5pq5?

1) Upgrade atomic-agents-stack to 1.1.0 or later, which fixes `_estimate_batch_cost` to use `PRICING.get(model, _costs._fallback_pricing())['output']`, matching the already-correct sibling function `dream._estimate_dream_cost`. 2) Until patched, inventory every model identifier passed into batch/parallel-delegate calls and confirm each exists in the framework's `PRICING` table — treat any unlisted model (self-hosted, Ollama, vLLM, or a brand-new provider SKU) as unprotected by the cost cap. 3) Add out-of-band spend monitoring (provider billing alerts, API usage dashboards) as a compensating control for any workload using unlisted models, since the in-framework guardrail cannot be trusted for them. 4) If you maintain a fork or custom pricing table, add the conformance test the advisory recommends: assert an unknown-model batch reserves a non-zero amount and that an over-cap unknown-model batch raises `CostGuardrailBlocked`. 5) Review logs/telemetry for `_check_batch_reservation` early-returns as a detection signal that the guardrail was silently bypassed.

What systems are affected by GHSA-j659-8xh6-5pq5?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-agent orchestration, model serving.

What is the CVSS score for GHSA-j659-8xh6-5pq5?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-agent orchestrationmodel serving

MITRE ATLAS Techniques

AML.T0034 Cost Harvesting

AML.T0034.002 Agentic Resource Consumption

Compliance Controls Affected

EU AI Act: Article 9

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

`_estimate_batch_cost` (`atomic_agents/agent.py`) looks up the per-model output price with `PRICING.get(model, {})`, returning 0.0 for any model not in the hardcoded pricing table. `_check_batch_reservation` then early-returns when the reservation is <= 0, skipping the batch reservation entirely. That reservation is the only defense against the documented fan-out race where every parallel helper/delegate reads the identical pre-batch on-disk cost total and each passes its individual check even though the collective spend overruns the configured cap. **Impact:** an operator running any model not in the pricing table (self-hosted/Ollama/vLLM, a new provider SKU) with `cost_guardrails` + `daily_cap_usd` set believes the cap protects them, but a single parallel batch can blow past the cap. The parallel-helper `model` argument can also be steered to an unknown id. The sibling `dream._estimate_dream_cost` does this correctly (`PRICING.get(model, _fallback_pricing())`), which makes this a clear defect. **Affected:** `agent.py` (`_estimate_batch_cost` / `_check_batch_reservation`), all versions through 1.0.0. **Fix:** use `PRICING.get(model, _costs._fallback_pricing())['output']` (mirror dream/calc_cost). Add a conformance test asserting an unknown-model batch reserves > 0 and that an over-cap unknown-model batch raises `CostGuardrailBlocked`.

Exploitation Scenario

An operator (or a lower-trust user/tenant with the ability to specify the `model` argument in a multi-tenant agent platform) submits a parallel batch job — e.g., 10 concurrent delegate agents — using a self-hosted Ollama model that isn't in atomic-agents-stack's hardcoded `PRICING` table. Each of the 10 parallel workers independently calls `_estimate_batch_cost`, which returns 0.0 for the unrecognized model; `_check_batch_reservation` sees a reservation of 0.0 and short-circuits without reserving any budget or checking the cap. Because all 10 workers read the identical pre-batch on-disk cost total before any of them writes back, every worker individually 'passes' its guardrail check, and the batch collectively consumes far more than the configured `daily_cap_usd` — with no error, warning, or blocked request at any point. The operator only discovers the overrun when the compute/inference bill arrives, by which point the budget control they believed was enforced had never actually engaged.

Weaknesses (CWE)

CWE-770 Allocation of Resources Without Limits or Throttling Primary

CWE-770 — Allocation of Resources Without Limits or Throttling: The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

[Requirements] Clearly specify the minimum and maximum expectations for capabilities, and dictate which behaviors are acceptable when resource allocation reaches limits.
[Architecture and Design] Limit the amount of resources that are accessible to unprivileged users. Set per-user limits for resources. Allow the system administrator to define these limits. Be careful to avoid CWE-410.

Source: MITRE CWE corpus.