Quick Take
- What: AshAi 1.5.0 sent raw exception text and internal error details to tool callers (MCP clients and LLMs) when tool actions failed, exposing module names, function names, and data values.
- Who is affected: Applications serving tools through AshAi.Mcp.Router or AshAi.ToolLoop in version 1.5.0.
- What to do: Upgrade to AshAi 1.5.1 or later. If you relied on
{:error, "message}reaching the caller, return an exception that implements AshAi.ToToolError instead. - Severity: Medium (CVSS 5.3), information disclosure vulnerability.
- Status: Patched in version 1.5.1.
In plain English
AshAi is a tool that helps AI agents interact with applications. Version 1.5.0 had a bug where, if something went wrong when an AI agent called a tool, the error message sent back included technical details like internal code names and data values that should have stayed private. An attacker who could call these tools could deliberately trigger errors to learn about the internal workings of the application. Version 1.5.1 fixes this by logging the full error privately and only sending a generic error message with an ID to the caller.
What you should do: If you use AshAi to build AI tools, you should upgrade to 1.5.1. If you don’t use AshAi, you can ignore this.
What happened
AshAi 1.5.0 introduced an implementation of AshAi.ToToolError for Ash.Error.Unknown.UnknownError that returned the error’s raw text field without filtering. When a tool action raised an exception, returned a bare {:error, term}, or produced a result that could not be JSON-encoded, Ash wrapped the error in UnknownError and stored the full Exception.format/2 output or inspect/1 of the term in that field.
AshAi.Tool.Errors.format/1 then sent this unfiltered text to tool callers through AshAi.Mcp.Server (for MCP tool calls and resource reads) and AshAi.ToolLoop (for LLM interactions). The error text often included internal module names, function names, and data values. For Protocol.UndefinedError (triggered when a result could not be encoded), the text included the full inspected value, which could be an entire record with fields the tool would never normally return. None of these errors were logged.
A caller with tool access could send unexpected or malformed arguments to make a tool fail, then read the returned error text to learn internal implementation details and data values. Before version 1.5.0, UnknownError had no AshAi.ToToolError implementation and callers received a generic unexpected error occurred message.
What you should do
Upgrade to AshAi 1.5.1 or later. If you cannot upgrade immediately, stay on version 1.4.x until you can.
If your application relied on {:error, message} reaching the caller, you must now return an exception that implements the AshAi.ToToolError protocol instead.
What it means
This vulnerability allowed information disclosure (CWE-209) in applications serving tools through AshAi.Mcp.Router or the tool loop. Anyone who could call a tool could probe for inputs that caused failures and read back internal module names and values, with no audit trail.
The fix in version 1.5.1 logs errors that AshAi.ToToolError does not describe in full under an error ID, and returns only unexpected error occurred (error id: …)” to the caller. This prevents information leakage while preserving debugging capability through server logs.
