CVE-2026-77956
Summary
by MITRE • 08/31/2026
Improper Control of Generation of Code (Code Injection) vulnerability in ash-project ash_ai allows a remote, unauthenticated client to execute arbitrary Elixir code.
AshAi.Actions.Prompt evaluates prompt content through EEx.eval_string/2. The documented prompt: fn input, context -> ... end form lets the prompt content be built from action arguments, so when a prompt action's text incorporates request data, that attacker-controlled text is compiled and run as an EEx template (Elixir source). Content such as therefore executes on the server before any model request is made, requiring no authentication beyond reaching a prompt action. The fix stops evaluating function-supplied prompt content as EEx; only statically configured templates are evaluated.
This issue affects ash_ai: from 0.1.0 before 1.0.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in the ash_project ash_ai library represents a critical server-side code injection flaw, specifically categorized under Improper Control of Generation of Code as defined by CWE-94. This security defect allows an unauthenticated remote attacker to achieve arbitrary code execution on the target system. The root cause lies within the AshAi.Actions.Prompt module, which utilizes EEx.eval_string/2 to process prompt content. While this function is designed for evaluating embedded Elixir templates in legitimate scenarios, its implementation here fails to adequately sanitize or restrict user-supplied input before compilation and execution. Consequently, any data derived from external requests that is incorporated into the prompt text becomes part of the code string passed to the evaluator.
The operational mechanism of this exploit relies on the specific design pattern where prompts are constructed dynamically from action arguments. When a developer configures a prompt action with a function-based template such as fn input, context -> ... end, and subsequently allows user-provided data to influence that text, the application inadvertently treats attacker-controlled strings as executable Elixir source code. For instance, if an attacker injects malicious syntax into the request parameters, this content is compiled by the server before any interaction with external AI models occurs. This pre-processing step means the vulnerability can be triggered simply by reaching a prompt action endpoint, bypassing the need for authentication or valid API keys in many configurations. The ability to execute arbitrary code at this stage grants the attacker full control over the application environment, potentially leading to data exfiltration, privilege escalation, or complete system compromise depending on the runtime permissions of the Elixir process.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Command and Scripting Interpreter abuse, specifically allowing for remote code execution without user interaction in certain contexts. The lack of authentication requirement significantly lowers the barrier to entry for attackers, making it a high-severity issue that can be exploited by automated scanning tools or opportunistic adversaries targeting exposed endpoints. The impact is severe because Elixir runs on the BEAM virtual machine, and successful exploitation could allow an attacker to read sensitive environment variables, access internal state, or execute system commands if the application has appropriate permissions.
The remediation strategy implemented in versions 1.0.0 and later of ash_ai addresses this flaw by fundamentally changing how prompt content is evaluated. The fix restricts EEx evaluation exclusively to statically configured templates that are defined within the codebase itself, rather than dynamically constructed from user input at runtime. This separation ensures that attacker-controlled data cannot be interpreted as executable code. Organizations running affected versions between 0.1.0 and before 1.0.0 must upgrade immediately to mitigate this risk. In cases where upgrading is not feasible due to legacy constraints or compatibility issues, immediate mitigation involves strictly validating and sanitizing all input passed to prompt actions, ensuring that no user-supplied data is interpolated into EEx templates. Additionally, implementing strict content security policies for API inputs and restricting the execution context of the application can provide layered defense against exploitation until a full patch deployment is completed.