GHSA-j659-8xh6-5pq5: vLLM — HIGH

`_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....

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	<= 1.0.0	`1.1.0`
89.1K 128 dependents Pushed yesterday 24% patched ~49d 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

N/A

What should I do?

Patch available

Update vLLM to version 1.1.0

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

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

`_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`.

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?

Update to patched version: vLLM 1.1.0.

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

No CVSS score has been assigned yet.

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`.

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.