Critical Race Condition Vulnerability Found in LLM-Generated Code for Billing Systems
Key Takeaways
- ▸All major coding LLMs generate the same TOCTOU race condition vulnerability in billing code, but can identify and fix it when explicitly asked
- ▸The vulnerability allows users with minimal credits to generate massive API bills by sending concurrent requests that bypass credit checks during LLM processing delays
- ▸The 'Denial of Wallet' attack is particularly severe for high-value features processing large documents, where longer completion times create wider exploitation windows
Summary
A widespread vulnerability has been identified in LLM-generated code that implements credit-based billing for AI-powered applications. The flaw is a classic Time-of-Check to Time-of-Use (TOCTOU) race condition where concurrent API requests can bypass credit checks, allowing users to consume thousands of dollars worth of compute with minimal credits. Researchers testing ten major coding LLMs found that every model generates this vulnerable pattern when asked to create credit-gated features—but remarkably, every model can also identify and fix the vulnerability when specifically prompted to do so.
The vulnerability exploits the inherent delay in LLM API calls, which can take seconds to minutes depending on document size. While a server awaits a model response, multiple concurrent requests from a user can each pass the credit check independently before any deductions are recorded. This 'Denial of Wallet' attack is particularly dangerous for applications processing large documents, where longer completion times create wider windows for exploitation and higher per-request costs. The issue represents a fundamental shift in security calculus—race conditions that were previously acceptable risks in legacy systems now pose serious financial threats in the era of expensive AI APIs.
- This represents a systemic pattern in LLM-generated code rather than isolated developer error, raising concerns about production AI app security
Editorial Opinion
This finding exposes a critical gap between LLM capability and safety in real-world deployments. While it's encouraging that these models can identify the vulnerability when prompted, the fact that they generate it reliably by default suggests a training or alignment issue—these systems appear optimized for functional correctness rather than security-first design. Developers using LLMs to scaffold billing-critical features should treat the generated code as proof-of-concept only, not production-ready, and implement explicit security prompting or human review processes.
