EEF-CVE-2026-119613: AshAi sends unrecognized tool errors verbatim to MCP clients and the model, disclosing internal details
Summary
Generation of Error Message Containing Sensitive Information vulnerability in ash-project ashai 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 ashai: from 1.5.0 before 1.5.1.
Impact
A caller with tool access sends unexpected or malformed tool arguments until a tool fails, then reads the returned error text to learn internal module and function names and the values the code failed on.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/ash_aito a version that resolves this vulnerability.Fixed in 1.5.1 - Upgrade
Upgrade
ash_aito a version that resolves this vulnerability.Fixed in 1.5.1
Event History
Frequently Asked Questions
Who can trigger the information disclosure?
A caller must have access to an AshAi tool. They can submit unexpected or malformed tool arguments until a tool call fails, then read the returned error text.
What information may be exposed when a tool call fails?
Returned errors can reveal internal module and function names and data values. In particular, a JSON-encoding failure can include an inspected value that may be an entire record containing fields the tool does not normally return.
Which versions need remediation, and what changes in the fix?
The affected range is ash_ai 1.5.0 before 1.5.1. The fix logs the error under an error ID and returns only that ID to the caller instead of the underlying error text.
Can existing logs be used to identify prior exploitation?
The vulnerable error paths were not logged. The provided information does not describe a way to retrospectively determine whether sensitive error details were previously returned.