AshAi Unauthenticated EEx Template Injection Leading to Remote Code Execution

Technical Analysis

AshAi.Actions.Prompt supports a documented 'prompt: fn input, context -> ... end' pattern that builds prompt text dynamically, then passes that text through EEx.eval_string/2 for template evaluation. Because action arguments (attacker-controlled request data) can be interpolated into this prompt string, an attacker can embed EEx directives like <%= System.cmd(...) %>, which the runtime compiles and executes as native Elixir code on the host. The entry point is any exposed prompt action reachable without authentication; the attacker gains arbitrary code execution in the application's runtime context, effectively bypassing the LLM entirely. This crosses the boundary between 'data intended for an AI prompt' and 'executable server-side code,' turning an agent-facing input channel into a direct code execution primitive — the fix restricts EEx evaluation to statically configured templates only.

Affected Systems

ash_ai, Ash Framework (Elixir)

Detection Signatures

• Look for EEx template syntax (<%= %>, <% %>) embedded in incoming request parameters or prompt action arguments.
• Monitor for unexpected System.cmd, File, Port, or Code.eval_* calls originating from prompt-handling modules.
• Audit logs for prompt action invocations containing shell metacharacters, backticks, or Elixir function calls.
• Alert on ash_ai versions < 1.0.0 in dependency manifests (mix.lock, mix.exs).

Remediation Steps

1. 1

   Upgrade ash_ai

   Update to ash_ai version 1.0.0 or later, which stops evaluating function-supplied prompt content as EEx and only evaluates statically configured templates.

2. 2

   Audit prompt actions for dynamic content

   Review all AshAi.Actions.Prompt usages and ensure no request-derived or user-controlled data is concatenated into prompt strings that get EEx-evaluated.

3. 3

   Sanitize and isolate templating

   If custom templating is required, use a sandboxed or non-code-executing template engine, and never evaluate untrusted strings with EEx.eval_string or similar dynamic code evaluation functions.

4. 4

   Add authentication/authorization on prompt actions

   Ensure prompt actions are not reachable by unauthenticated clients as defense-in-depth, even after patching.

5. 5

   Runtime monitoring

   Deploy runtime application self-protection (RASP) or system call monitoring to detect anomalous process execution (System.cmd, Port.open) triggered from web-facing request handlers.