CVE-2026-77956PoC

🔥 CyberForge CVE of the Day #039 🚨 CVE-2026-77956 — AshAi EEx Template Evaluation Enables Conditional Remote Code Execution A newly disclosed AshAi vulnerability turns attacker-controlled prompt content into executable Elixir code inside the host application. And here is the crucial distinction: this is not ordinary LLM prompt injection. The malicious text can execute on the server before the prompt ever reaches the model. No jailbreak, cooperative model, valid provider API key or successful LLM response is required. 🔑 Key details: ⭐ Current severity: High — CVSS v4.0: 8.9 ⭐ Additional score: Critical — CVSS v3.1: 9.8 🧠 Weakness: CWE-94 — Improper Control of Generation of Code 🎯 Target: ash-project AshAi / Hex package ash_ai 🧩 Component: AshAi.Actions.Prompt 🔓 Authentication: None in the vendor’s exposed example; consuming apps may impose their own controls 👆 User interaction: None ⚙️ Complexity: Low, with Attack Requirements Present under CVSS v4 ⚔️ Impact: Conditional remote code execution 🛡️ Affected: ash_ai >=0.1.0 and <1.0.0 ✅ Fixed: AshAi 1.0.0 🧪 Public PoC: Yes — complete reproduction in the official vendor advisory 🌍 Active exploitation: None confirmed as of 1 September 2026 📋 CISA KEV: Not listed 📊 CISA SSVC: PoC / Not automatable / Total technical impact 📉 EPSS: 0.38% at review time 🧬 What actually went wrong? AshAi prompt actions support several configuration styles. One documented form is a runtime function that builds a prompt or list of messages from the action input and execution context. That is a perfectly natural place for an application developer to use values from input.arguments. In vulnerable AshAi releases, prompt content returned by this runtime function can pass through EEx.eval_string/2. EEx is Elixir’s embedded template engine, so content the developer intended to be ordinary LLM message text can be interpreted again as Elixir source. If attacker-controlled request data is copied into that returned content, the trust boundary collapses: 1️⃣ An attacker reaches an exposed AshAi prompt action. 2️⃣ Their request value becomes part of the runtime-generated prompt. 3️⃣ Vulnerable AshAi treats that prompt content as an EEx template. 4️⃣ Attacker-supplied EEx expressions execute inside the application’s BEAM process. 5️⃣ Only after that does the application attempt to contact the configured model provider. The vendor’s official demonstration proves the ordering beautifully: the code-execution marker fires even though the later prompt action fails because no OpenAI API key is configured. The LLM never needs to process the malicious prompt. 🤖 Prompt injection versus code injection: Ordinary prompt injection attempts to manipulate a model’s instructions, tools or output. CVE-2026-77956 instead makes the application server compile text as Elixir. The model is not the execution engine—the vulnerable BEAM application is. That means system prompts, model alignment, output filtering and provider-side abuse controls do not fix the root cause. This belongs firmly in the server-side code-injection and RCE world. ⚠️ Exploitability is conditional: Merely finding AshAi 0.x in a dependency list does not prove that a service is remotely exploitable. The complete path requires: ✅ An affected AshAi version below 1.0.0 ✅ A prompt action using the runtime function form ✅ Attacker-controlled request/action data placed into the function’s returned prompt content ✅ An HTTP, GraphQL, JSON, MCP or other untrusted interface capable of invoking that action If the consuming application requires authentication, the attacker must satisfy that application-level control. In an exposed unauthenticated route like the vendor’s example, no account or special privileges are needed. There is also no universal vulnerable URL or parameter. The /analyze route and text field shown in the official PoC belong to the demonstration application, not AshAi itself. 📊 The scoring wrinkle: Current vendor and CNA metadata use: CVSS:4.0/AV/AC/AT/PR/UI/VC/VI/VA/SC/SI/SA — 8.9 High The Local metric models the vulnerable library being invoked inside its consuming application, while Attack Requirements Present acknowledges that the app must use and expose the dangerous runtime pattern. In practical deployments, the malicious input can still arrive remotely through an application endpoint. NVD-linked CVSS v3.1 enrichment captures that path as 9.8 Critical with Network reachability. The public CVE record initially carried a CVSS v4.0 10.0 Network/AT vector before being revised on 31 August to the current 8.9 Local/AT assessment. The revised score does not erase the demonstrated RCE; it more carefully represents the required application configuration. 💥 Potential impact: Successful exploitation runs Elixir with the privileges of the Ash application process. Depending on the deployment, an attacker could potentially: 🔹 Read application secrets and environment variables 🔹 Access model-provider or database credentials 🔹 Query business data available to the service 🔹 Read or modify application files 🔹 Reach internal services permitted by network policy 🔹 Launch operating-system commands or additional tooling 🔹 Establish persistence or move laterally where surrounding controls allow it This does not automatically grant root access, container escape, Kubernetes administration or full cloud-account compromise. The blast radius depends on service permissions, secret scoping, filesystem controls and network segmentation. 🛠️ How version 1.0.0 fixes it: The patch separates trusted static prompt templates from runtime-generated content. 🔹 Static developer-authored templates can still use EEx as intended. 🔹 Content returned by a runtime prompt function is normalised with EEx evaluation disabled. 🔹 The change covers strings, system/user tuples and message lists. 🔹 A regression test verifies that EEx-shaped runtime text remains inert message content instead of executing. That is the correct trust model: static application configuration may be a template, but the result of a runtime function must remain data. 🔎 Defender hunting guide: 1️⃣ Inventory - Search mix.lock, SBOMs, containers and deployed Elixir releases for ash_ai below 1.0.0. Check every web node and worker—not merely the version requested in mix.exs. 2️⃣ Review application code - Look for AshAi.Actions.Prompt, prompt: fn, prompt functions using input.arguments, and returned strings or messages assembled from request-derived values. 3️⃣ Map exposure - Identify every API, GraphQL operation, MCP surface, background job or internal interface able to invoke those actions. Record its authentication and authorisation controls. 4️⃣ Hunt request telemetry - Search action inputs and proxy logs for EEx delimiters such as <% and <%=, including encoded forms. Treat these as hunting clues rather than complete signatures—encoding and alternate Elixir constructs can bypass simple matching. 5️⃣ Correlate workload behaviour - Investigate unusual EEx compilation errors, action failures before any provider call, new outbound connections, suspicious file writes and unexpected child processes launched by beam.smp or the Elixir release. The absence of OpenAI, Anthropic or other provider logs does not prove safety. The vulnerable evaluation occurs first. 🛡️ Defensive action: ✅ Upgrade to AshAi 1.0.0 or later ✅ Refresh and verify the resolved lockfile ✅ Test integrations because 1.0.0 is a major release ✅ Rebuild containers and Elixir release artefacts ✅ Redeploy every web and worker node ✅ Disable exposed vulnerable prompt actions until patched ✅ Apply strong authentication and explicit action-level authorisation ✅ Run the BEAM service as a non-root, least-privileged identity ✅ Restrict filesystem writes and unnecessary outbound access ✅ Scope database, cloud and model-provider credentials tightly If exploitation is suspected, isolate and rebuild the workload from a trusted fixed image, preserve application/EDR/network evidence, rotate every credential accessible to the service and inspect internal systems contacted by it. Do not rely on blocking EEx markers as the permanent fix. It is a brittle filter around a code-evaluation flaw; upgrading is the remediation. 🧪 Exploitation status: The official vendor advisory contains a complete reviewed PoC, so exploitability is not theoretical. However, public PoC availability is not the same as active exploitation. No confirmed in-the-wild attacks were identified during CyberForge research, and the CVE was not present in CISA’s KEV catalog on 1 September 2026. The early EPSS probability of 0.38% is low, but the record is exceptionally young and the vendor PoC is already public. EPSS should inform prioritisation—not overrule exposure, technical impact or first-party evidence. 🔥 CyberForge verdict: CVE-2026-77956 is a superb example of why every interpretation boundary matters in AI-enabled applications. A developer believes they are constructing text for a model. The library silently interprets that runtime text as a program. Once an untrusted request crosses that boundary, the model becomes irrelevant and the host application is exposed. This is not universal “install AshAi and get remotely owned” RCE. It requires a vulnerable runtime prompt pattern and an attacker-reachable action. But where that chain exists, server-side execution happens before the provider call and without model credentials or victim interaction. Internet-facing AshAi 0.x deployments deserve urgent inventory, upgrade and threat hunting. The low initial EPSS and lack of confirmed attacks are reasons for measured language—not reasons to delay a confirmed vendor fix for a public RCE chain. 🔗 Full visual/vendor advisory and official PoC: https://github.com/ash-project/ash_ai/security/advisories/GHSA-2g59-hg7m-qc83 🔗 Security patch: https://github.com/ash-project/ash_ai/commit/e9948254b5659c1143b73dc2f59f457931e64514 🔗 CNA record: https://cna.erlef.org/cves/CVE-2026-77956.html 🔗 Full NVD vulnerability details: https://nvd.nist.gov/vuln/detail/CVE-2026-77956 #CyberForge #CVEOfTheDay #CVE202677956 #AshAi #Elixir #EEx #RCE #CodeInjection #LLMSecurity #AppSec #DevSecOps #BlueTeam #ThreatHunting