CVE-2026-77850 in ash_admin
Summary
by MITRE • 08/31/2026
Stored Cross-site Scripting vulnerability in ash-project ash_admin executes attacker-supplied record content as script in an administrator's browser.
The relationship typeahead components AshAdmin.Components.Resource.RelationshipField and AshAdmin.Components.Resource.ManagedRelationshipSelectField highlight the matched search term by wrapping it in <b> tags and rendering the whole string with Phoenix.HTML.raw/1. The highlighted value is the destination record's label_field, ordinary database content that is often written by lower-privileged users. Because raw/1 disables output escaping for the entire string, a stored label such as <img src=x onerror=...> runs as JavaScript in the admin's session as soon as a matching record appears in the dropdown, giving the attacker the admin's privileges over everything AshAdmin exposes. The fix HTML-escapes the label before inserting the highlight markup.
This issue affects ash_admin: from 0.13.0 before 1.3.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in the ash_admin component represents a critical Stored Cross-site Scripting (XSS) flaw that compromises the integrity and security of administrative interfaces built with Ash Framework applications. This specific weakness resides within the relationship typeahead components, specifically affecting the AshAdmin.Components.Resource.RelationshipField and AshAdmin.Components.Resource.ManagedRelationshipSelectField modules. The core technical failure stems from how these components handle user-supplied data during search operations. When a user performs a search to select related records, the interface highlights matching terms by wrapping them in HTML span tags with specific styling classes. However, instead of properly escaping the underlying database content before applying this markup, the application utilizes Phoenix.HTML.raw/1 to render the entire string. This function explicitly disables output escaping for the provided input, treating it as safe and trusted HTML rather than raw text data that requires sanitization.
The operational impact is severe because the source of the malicious payload is not direct user input into a form field but rather stored database content known as label_field values. These fields are frequently populated by lower-privileged users or automated processes during normal application operation, meaning they are often considered trusted internal data. An attacker who can inject script tags such as <script>alert(1)</script> into these record labels effectively plants persistent malicious code within the application's database. When an administrator subsequently uses the relationship selector and triggers a search that matches this tainted label, the browser executes the embedded JavaScript immediately upon rendering the dropdown results. This execution occurs within the context of the administrator’s active session, granting the attacker full administrative privileges over all resources exposed through AshAdmin without requiring any additional authentication or privilege escalation steps beyond accessing the vulnerable interface.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. More specifically, it falls under CWE-836 Use of Password-based Credential for Authorization in contexts where session hijacking leads to privilege escalation, although the primary vector is XSS leading to unauthorized actions. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1059 Command and Scripting Interpreter via browser-side scripting, allowing attackers to execute arbitrary commands within the victim's environment. The persistence aspect classifies it under T1187 Forced Authentication or potentially T1204 User Execution if combined with social engineering, but primarily it is a Stored XSS attack that facilitates subsequent malicious activities such as session hijacking, credential theft via keyloggers embedded in the script, or defacement of administrative pages.
The root cause lies in the assumption that data retrieved from internal database fields does not require sanitization before being injected into HTML structures. This is a common misconception among developers who distinguish between user input and stored content, failing to recognize that any dynamic data rendered by Phoenix.HTML.raw/1 bypasses the framework's default escaping mechanisms. The fix implemented in version 1.3.1 addresses this by ensuring that the label value is HTML-escaped before being wrapped in highlight markup. This ensures that special characters like angle brackets are converted into their safe entity equivalents, preventing them from being interpreted as executable code by the browser while still allowing visual highlighting of search matches through CSS classes applied to neutral text nodes.
To mitigate this vulnerability and prevent similar issues in other parts of an Ash-based application, developers must adhere strictly to principles of output encoding whenever dynamic data is inserted into HTML contexts. Even when using Phoenix.HTML.raw/1 for performance or complex rendering reasons, any variable content within that string must be pre-escaped using functions like Phoenix.html.escape_text/1 if it originates from untrusted sources, including database records modified by lower-privileged users. Additionally, implementing Content Security Policy headers can provide a layer of defense-in-depth by restricting the execution of inline scripts and limiting script sources to trusted domains. Regular security audits focusing on data flow analysis are recommended to identify other instances where raw rendering functions might be misused with dynamic content that has not been properly sanitized.