Six AshAI Flaws Turned Prompts Into a Path to Server Takeover
AshAI did not merely pass an attacker’s words to a language model. In a vulnerable configuration, it compiled those words as Elixir and executed them inside the application’s BEAM node.
The flaw is the sharpest of six vulnerabilities disclosed together in the AshAI framework. The critical issue can give an unauthenticated remote user server-side code execution before the application makes any request to an AI provider. It does not depend on convincing a model to follow malicious instructions. It does not require an OpenAI key. It does not even require the model to be available.
That distinction matters. This is not conventional prompt injection. It is a failure to keep untrusted data separate from executable application code.
The prompt crossed a code boundary
AshAI provides prompt actions for applications built with the Ash framework. Developers can configure a prompt as a function that builds message content from action arguments. That is a natural pattern for an endpoint accepting text from a user.
In affected versions, AshAi.Actions.Prompt passed non-ReqLLM.Context prompt content through Elixir’s EEx.eval_string/2. EEx is a template engine, but its expressions are Elixir source. If attacker-controlled content reached that evaluation step, the application treated it as code.
The project’s public reproduction for CVE-2026-77956 sends an EEx expression in an ordinary HTTP form field. The expression executes inside the victim process before the prompt action fails because no model API key is configured. The vulnerability has a CVSS 4.0 score of 10.0 and requires no privileges or user interaction.
The vulnerable range is AshAI 0.1.0 through versions before 1.0.0. The project fixed the issue in version 1.0.0 by treating prompt content returned at runtime as data rather than evaluating it as an EEx template. Statically configured templates retain their intended template behaviour.
Six vulnerabilities arrived together
The RCE is part of a coordinated set of six AshAI advisories published within seconds of each other on 30 August 2026. Each advisory includes a working reproduction. The bugs cross several different trust boundaries: HTTP input, MCP requests, tool identity filters, embedding-provider errors and model-generated tool calls.
CVE-2026-77956: unauthenticated remote code execution
An application is exposed when it places an AshAI prompt action behind an HTTP or other untrusted boundary and constructs the runtime prompt from request data. Attacker-controlled EEx is then evaluated as Elixir in the server process. Versions from 0.1.0 up to, but not including, 1.0.0 are affected.
CVE-2026-81315: MCP origin validation bypass
A malicious website can bypass the DNS-rebinding protection in AshAi.Mcp.Server by supplying a spoofed X-Forwarded-Proto: https header. The page can then issue cross-site requests to a local MCP server with the victim’s actor context. The vulnerable condition affects AshAI 0.8.0 through versions before 1.0.0 and requires the victim to visit an attacker-controlled page.
CVE-2026-82564: identity filters can become operators
An identity-configured update or destroy tool expects a scalar identifier. A caller can instead provide a nested JSON object that is interpreted as an operator map. The result can be an update or deletion affecting records the caller never identified, potentially including every row exposed through that tool. Versions from 0.6.0 up to, but not including, 1.0.0 are affected.
CVE-2026-75760: embedding errors can disclose credentials
When an embedding-provider request fails, AshAi.Changes.Vectorize can return the inspected provider error through an attacker-visible validation response. Depending on the HTTP client, that error can contain the provider URL, response body and the Authorization header carrying the API key. The vulnerable range begins at version 0.1.0 and ends before 1.0.0.
CVE-2026-82579: a tool loop can consume credits forever
If a model response contains only invalid or already-processed tool calls, AshAI can filter every call out and recurse without changing the conversation. With the supported max_iterations: :infinity setting, the same paid model request can be submitted indefinitely. The project’s reproduction generated thousands of identical requests before its test harness stopped the process. Versions from 0.6.0 up to, but not including, 1.0.0 are affected.
CVE-2026-82580: raw tool exceptions enter the conversation
A user who can make an exposed tool raise an exception may receive its raw message through the conversation. Database columns, query fragments, schema names, policies and validation details can consequently reach both the model provider and the chat user. Versions from 0.6.0 up to, but not including, 1.0.0 are affected.
Public proof of concept is not confirmed exploitation
All six GitHub advisories contain reproducible demonstration code. That materially reduces the work needed to understand and test the flaws, especially the critical RCE. It does not establish that attackers are exploiting any of them in the wild.
As of 31 August, neither the project nor a government exploitation catalogue had reported confirmed malicious exploitation. The correct operational description is therefore public proof of concept available, not actively exploited.
What defenders should do
- Upgrade to AshAI 1.0.0. It is the fixed release for all six advisories.
- Inventory prompt actions. Find every prompt function that builds message content from request arguments, uploaded content, tool results or other untrusted data.
- Treat runtime prompt content as data. Do not pass it through EEx or another general-purpose template evaluator. Returning a
ReqLLM.Contextavoided the vulnerable EEx path in earlier releases, but upgrading is the durable response. - Review exposed MCP routes. Do not trust forwarded headers unless they come from a known proxy that strips client-supplied values. Restrict local MCP services from browser-originated requests.
- Audit identity-configured update and destroy tools. Check whether nested operators could broaden a supposedly exact lookup.
- Rotate provider credentials if errors were exposed. Logs and client responses may reveal whether embedding failures returned request headers or provider details.
- Set finite tool-loop limits. Apply request budgets, execution timeouts and cost controls even after upgrading.
The model was not the vulnerable interpreter
Security discussions around AI applications often concentrate on what a model might be persuaded to do. This incident sits one layer lower. The dangerous interpreter was part of the application framework, and it ran before the model had any role.
That is the broader lesson from the six advisories. AI frameworks connect ordinary users to privileged tools, local MCP services, databases and paid model APIs. Every conversion between those components is a trust boundary. A prompt can become code. An identifier can become a query operator. An error can become a credential disclosure. A tool call can become an unbounded bill.
The word “AI” does not make these new classes of bug. It concentrates familiar ones around unusually powerful application paths.
Sources
- AshAI advisory: remote code execution through EEx evaluation, published 30 August 2026 at 23:23:28 UTC
- AshAI advisory: MCP origin-validation bypass, published 30 August 2026 at 23:23:28 UTC
- AshAI advisory: identity-filter authorization bypass, published 30 August 2026 at 23:23:29 UTC
- AshAI advisory: embedding-provider credential disclosure, published 30 August 2026 at 23:23:31 UTC
- AshAI advisory: uncontrolled tool loop, published 30 August 2026 at 23:23:29 UTC
- AshAI advisory: raw exception disclosure, published 30 August 2026 at 23:23:30 UTC
- AshAI patch commit for runtime prompt handling
