Ash AI Framework Vulnerabilities: Six Flaws, One RCE Bug

On August 30, the maintainer of Ash AI quietly published six security advisories in a single day, for a tool that a growing number of teams use to wire large language models directly into their production databases. One of the six lets an attacker run arbitrary code on your server without logging in first.

Ash AI is an extension for the Ash Framework, a popular way to build backend applications in Elixir, the language that powers systems like Discord's chat infrastructure and WhatsApp's early messaging backbone. Ash AI's whole pitch is convenience: it lets developers bolt "tool calling" onto an LLM, so the model can query your database, trigger actions, or generate structured output, without hand-rolling that plumbing every time. That convenience is exactly what turned into six separate ways for things to go wrong.

The Headline Bug: Code Execution With No Login Required

The worst of the six, tracked as GHSA-2g59-hg7m-qc83, sits in a module called AshAi.Actions.Prompt. To understand it, you need to know what EEx is: it's Elixir's built-in templating engine, the same idea as PHP or JSP, where you mix plain code into a text template and the engine runs that code when it renders the page. The bug was that Ash AI fed text coming from user input straight into EEx for evaluation. If your prompt text included something like a system command, the server would simply execute it. That's called remote code execution, or RCE — plain English version: a stranger on the internet can get your server to run whatever instructions they type in, with no password needed.

The fix, now shipped, stops evaluating any prompt content that isn't a template the developer explicitly configured ahead of time. If you or your team run ash_ai in anything user-facing, updating past version 1.0.0 isn't optional homework, it's the actual patch for an unauthenticated RCE.

The Other Five Weren't Minor Either

RCE is the one that grabs headlines, but the rest of the batch is a decent tour of what can go wrong when you let an AI agent act on your behalf inside real application code:

• Broken access control in the tool-execution layer let a cleverly nested request update or delete records the caller shouldn't have had permission to touch.
• API key leakage happened when the embedding provider (the service that turns text into the number-vectors AI search relies on) threw an error that accidentally included the key in the response.
• An origin-validation bypass made it possible to fake the source of a request using the X-Forwarded-Proto header, opening the door to a DNS-rebinding CSRF attack, essentially tricking a browser into making requests it shouldn't be allowed to make.
• An uncontrolled loop could make the tool-calling logic hammer an AI provider with identical requests forever, running up your bill for nothing.
• Raw exception messages were leaking into the AI's own conversation context, handing the model, and anyone reading its output, internal details it had no business seeing.

Six advisories, one maintainer, one day. That's not a routine patch cycle, that's a framework getting a hard structural reckoning on what happens when you let an LLM sit this close to your app logic.

Why This Should Matter Beyond Elixir Shops

Very few Indian engineering teams ship production Elixir, but that's almost beside the point. What Ash AI's advisory list actually documents is a pattern showing up across every language's "AI agent toolkit": once you let a model's output steer what code runs or what database rows get touched, you've created a new, often unaudited attack surface. A lot of Indian fintech and SaaS startups are racing to bolt LLM agents onto customer support, KYC checks, or internal ops tooling right now, frequently using far less scrutinized glue code than a well-known open-source project with an active maintainer. If a framework this visible carried an unauthenticated RCE for months, in-house AI integrations built over a weekend sprint deserve at least as much suspicion.

There's also a compliance angle worth flagging. Under India's DPDP Act, a data fiduciary is expected to put in place "reasonable security safeguards" to prevent breaches, and a bug like the API key leak or the broken access control here is precisely the kind of gap a regulator or an auditor would point to after the fact. It echoes a pattern Code24 has covered before with open-source supply chain security, except the risk here sits one layer higher, in the AI tooling teams stack on top of otherwise trustworthy frameworks.

What To Actually Do About It

If your stack touches ash_ai, updating is the immediate step. But the broader lesson travels well past one Elixir library:

1. Treat any text an LLM receives from a user as untrusted input, the same way you'd treat a form field, before it reaches templating, shell commands, or database queries.
2. Audit what your AI tool-calling layer can actually reach: does it really need write access to production tables?
3. Check error handling paths specifically for leaking secrets, since that's a category of bug standard security reviews often skip.

The patches for Ash AI are already out, which is the easy part. The harder question is how many other AI agent frameworks, including ones far more widely used than a niche Elixir extension, are carrying similar bugs that nobody has gone looking for yet. The category of "let the model call functions in your app" is barely two years old, and security review practices for it are still catching up to how fast teams are shipping it.