CVE-2026-82579 in ash_ai
Summary
by MITRE • 08/31/2026
Loop with Unreachable Exit Condition (Infinite Loop) vulnerability in ash-project ash_ai allows an attacker who can influence a model's output to hang the tool loop and drive unbounded, repeated model requests.
AshAi.ToolLoop classifies a model response of :tool_calls, then filters the calls through normalize_tool_calls/2 and unprocessed_tool_calls/2. Both can empty the list: a call missing a valid name, or one reusing a tool_call_id that already has a result in history, is dropped. With an empty list the loop appended nothing and recursed with a byte-identical message list, so the conversation never advanced and the same request was re-sent every iteration. Under the supported max_iterations: :infinity this never terminated; otherwise it exhausted the full budget. Prompt-injected content can make the model re-emit a spent tool_call_id. The fix treats an empty post-filter list as terminal.
This issue affects ash_ai: from 0.6.0 before 1.0.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in the ash_project ash_ai library represents a critical logic flaw within its AI agent orchestration engine, specifically residing in the AshAi.ToolLoop module. This component is responsible for managing the iterative interaction between an application and large language models that support tool calling capabilities. The core function of this loop is to process model responses containing instructions or data intended for external tools, execute those tools, and feed the results back into the conversation context until a termination condition is met. However, due to insufficient validation of the filtered tool call list, the system fails to recognize when no valid actions remain to be performed, leading to an infinite loop scenario that can severely degrade system availability and consume unbounded resources.
The technical root cause lies in how the loop handles responses classified as containing tool calls but which are subsequently invalidated by internal filtering mechanisms. When a model response is received with :tool_calls, the AshAi.ToolLoop module processes these instructions through two specific functions: normalize_tool_calls/2 and unprocessed_tool_calls/2. These functions serve to sanitize inputs and ensure historical consistency, respectively. A call is dropped if it lacks a valid tool name or if it attempts to reuse a tool_call_id that has already been processed and recorded in the conversation history. In scenarios where all proposed calls are filtered out—resulting in an empty list—the loop logic erroneously appends nothing to the message state and recursively invokes itself with a byte-identical message list. Because the input data remains unchanged between iterations, the model is likely to produce the same invalid response again, creating a cycle that never advances the conversation state or reaches a natural conclusion.
This flaw creates significant operational impacts for any application relying on ash_ai for autonomous agent workflows. If the configuration allows for an infinite number of iterations via max_iterations: :infinity, the process will hang indefinitely, effectively causing a denial of service by consuming CPU cycles and memory without performing useful work. Even in configurations with finite iteration limits, the vulnerability leads to rapid exhaustion of the allocated budget or token quota. This not only wastes computational resources but also disrupts user experience as legitimate requests are delayed or failed due to resource contention. Furthermore, this behavior can be triggered maliciously through prompt injection attacks where an attacker crafts input that causes the model to repeatedly request a tool call with an already-used ID, thereby forcing the system into this infinite loop state intentionally.
From a security classification perspective, this vulnerability aligns with CWE-835, which describes loops with unreachable exit conditions or infinite looping. It also relates to CWE-400 regarding uncontrolled resource consumption, as the repeated execution leads to excessive CPU and memory usage. In terms of adversary tactics, this flaw can be exploited in conjunction with ATT&CK technique T1059 Command and Scripting Interpreter if an attacker uses it to disrupt security monitoring agents or automated defense systems that rely on AI-driven analysis tools. The inability to gracefully terminate the loop prevents proper logging and alerting mechanisms from functioning correctly during such attacks, potentially masking other malicious activities occurring in parallel.
The issue affects versions of ash_ai ranging from 0.6.0 up to, but not including, version 1.0.0. To mitigate this vulnerability, developers must ensure they are running a patched version where the loop logic has been corrected to treat an empty post-filter list as a terminal condition rather than continuing recursion. For applications currently on vulnerable versions, immediate remediation involves upgrading to the fixed release. In cases where upgrading is not immediately feasible, implementing external safeguards such as strict timeout mechanisms for individual tool execution steps and monitoring for repeated identical API requests can help detect and terminate these loops before they consume critical system resources. Additionally, validating model outputs against expected schemas more rigorously at a higher architectural level may reduce the frequency of invalid calls that trigger this specific code path.