CVE-2026-82580 in ash_ai
Summary
by MITRE • 08/31/2026
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_ai discloses internal error text to chat users.
In AshAi.ToolLoop and AshAi.Tools, an exception raised while executing a tool was serialized verbatim with Exception.message/1 into the tool-result content. That content is appended to the conversation, emitted as a {:tool_result, ...} stream event, and sent back to the model, which typically relays it to the user. No filtering happened first, so anything raised inside a tool callback or lifecycle hook (database constraint messages, adapter errors, query fragments, policy or validation internals) was echoed as-is. A chat user who can steer tool arguments into a raising code path receives the raw internal text. The fix routes raised tool errors through the same safe formatter used for other tool errors.
This issue affects ash_ai: from 0.6.0 before 1.0.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in AshAi versions prior to 1.0.0, specifically within components such as AshAi.ToolLoop and AshAi.Tools, represents a significant information disclosure flaw rooted in improper error handling mechanisms. This issue falls under the category of CWE-209: Generation of Error Message Containing Sensitive Information, where an application inadvertently exposes internal implementation details to unauthorized parties. The core technical failure lies in how exceptions are processed when tools execute within the Ash AI framework. When a tool callback or lifecycle hook encounters an error during execution, the system serializes the exception using Exception.message/1 without any prior sanitization or filtering. This raw serialization captures not only generic error descriptions but also internal diagnostic data such as database constraint violations, adapter-specific errors, SQL query fragments, and policy validation internals.
The operational impact of this vulnerability is substantial because it allows a chat user to potentially extract sensitive backend information by manipulating tool arguments to trigger specific failure paths. Since the serialized exception content is appended directly to the conversation history and emitted as a stream event, it becomes part of the context sent back to the language model. The model then typically relays this raw text to the end-user in its response. This creates a direct channel for information leakage where an attacker can steer inputs into code paths that raise exceptions containing database schemas, internal API structures, or other proprietary logic details. In environments handling sensitive data, such as healthcare or finance applications built on Ash Framework, this could lead to compliance violations and provide attackers with valuable reconnaissance data for further exploitation attempts.
From a threat modeling perspective, this vulnerability aligns with ATT&CK technique T1592: Gather Victim Host Information, specifically the sub-technique of gathering system configuration details through error messages. The lack of input validation on tool arguments exacerbates the risk, as it enables an attacker to systematically probe for different types of internal errors by varying inputs until a revealing exception is triggered. This behavior mirrors common web application vulnerabilities where stack traces or database error codes are exposed due to debug modes being left enabled in production environments, although here the exposure occurs through the natural flow of AI tool execution rather than HTTP responses.
The resolution implemented in AshAi version 1.0.0 addresses this flaw by routing raised tool errors through a standardized safe formatter that is already used for other non-sensitive tool errors. This ensures that any exception message processed during tool execution undergoes sanitization before being included in the conversation context or sent to the model. By decoupling raw internal exceptions from user-facing outputs, the framework prevents the leakage of implementation-specific details while still allowing developers to handle errors appropriately on the backend if needed for logging purposes. Organizations using Ash AI should upgrade immediately to version 1.0.0 or later to mitigate this risk and ensure that error handling practices align with security best standards for information disclosure prevention.