CVE-2026-119613 in ash_ai
Summary
by MITRE • 11/09/2026
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ash_ai allows a caller of an AshAi tool to read internal error details, including module names and data values, by making a tool call fail.
AshAi.ToToolError gained an implementation for Ash.Error.Unknown.UnknownError that returns the error's error field as is, and AshAi.Tool.Errors.format/1 sends that text to MCP clients (tool calls and resource reads in AshAi.Mcp.Server) and to the model in AshAi.ToolLoop. Ash stores the full Exception.format/2 output of a raised exception, or inspect/1 of a bare {:error, term} return, in that field. A tool result that cannot be JSON-encoded raises a Protocol.UndefinedError whose text includes the inspected value, which can be a whole record with fields the tool never returns. None of these errors were logged. The fix logs them under an error id and returns only that id to the caller.
This issue affects ash_ai: from 1.5.0 before 1.5.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/09/2026
The vulnerability identified in AshAi versions prior to 1.5.1 constitutes a significant information disclosure flaw rooted in improper error handling mechanisms within the application's tool execution pipeline. This issue, classified under CWE-209 as Generation of Error Message Containing Sensitive Information and aligned with MITRE ATT&CK technique T1486 Data Encrypted for Impact or more accurately T1537 Transmitting Data over a Different Protocol than Expected if used for exfiltration but primarily T1005 Data from Local System, allows an authenticated caller to extract internal system details by triggering specific failure conditions. The core of the vulnerability lies in how AshAi processes and formats error responses when a tool call encounters an exception or returns an unexpected result structure. Instead of sanitizing these outputs for external consumption, the framework inadvertently exposes low-level implementation specifics that can aid attackers in mapping the application's architecture and identifying further attack vectors.
Technically, the flaw originates from the interaction between AshAi.ToToolError and the underlying error handling logic within the Ash framework. When a tool call fails, the system invokes Ash.Error.Unknown.UnknownError to format the response. This implementation returns the raw content of the error field without sufficient sanitization or abstraction layers for external clients such as Model Context Protocol (MCP) consumers or language models interacting via AshAi.Mcp.Server and AshAi.ToolLoop. Specifically, when a tool result contains data that cannot be encoded into JSON, it triggers a Protocol.UndefinedError. The text representation of this error includes the output of inspect/1 on the problematic term, which may encompass entire record structures with internal fields that are not part of the intended public API contract. These detailed stack traces and variable values were previously transmitted directly to the caller without being logged or masked, providing a rich source of intelligence regarding module names, data types, and potentially sensitive business logic states.
The operational impact of this vulnerability is substantial for organizations relying on AshAi for automated tool execution through AI models. An attacker who can induce tool failures, either intentionally by crafting malformed inputs or passively by observing system behavior during edge cases, gains visibility into the internal structure of the application. This exposure facilitates reconnaissance activities where the adversary maps out module dependencies and identifies potential targets for more sophisticated attacks such as injection or privilege escalation. Furthermore, because these errors were not logged internally prior to the fix, there was no audit trail available for security monitoring systems to detect this enumeration activity, allowing the information leakage to occur undetected over extended periods. The exposure of internal data values could also lead to secondary vulnerabilities if those values contain secrets, tokens, or personally identifiable information embedded within application records.
Mitigation strategies focus on enforcing strict separation between internal debugging details and external error responses. The primary remediation involves ensuring that all exceptions are caught early in the execution pipeline and transformed into generic, user-friendly messages before being sent to MCP clients or language models. As implemented in version 1.5.1, errors should be logged internally with a unique identifier while only returning this opaque ID to the caller. This approach prevents direct exposure of stack traces, module names, and variable contents. Additionally, developers must implement comprehensive input validation and JSON encoding checks prior to tool execution to minimize the occurrence of Protocol.UndefinedError conditions. Security teams should also review logging configurations to ensure that all error occurrences are captured with sufficient detail for forensic analysis but never exposed in API responses or model outputs. Upgrading to AshAi version 1.5.1 or later is required to resolve this vulnerability and restore secure error handling practices consistent with industry standards for information disclosure prevention.