CVE-2026-90772 in Amundsen Frontend
Summary
by MITRE • 09/13/2026
Amundsen frontend through 4.3.0 renders table, dashboard, and feature descriptions with dangerouslySetInnerHTML without HTML sanitization in ResourceListItem components. Attackers can inject malicious markup like img elements with onerror handlers into descriptions via the metadata service or Elasticsearch, executing JavaScript in every user's browser that views search results.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/13/2026
The vulnerability identified in Amundsen frontend versions through 4.3.0 constitutes a critical Cross-Site Scripting (XSS) flaw rooted in improper handling of untrusted input within the ResourceListItem components. The core technical deficiency lies in the use of React's dangerouslySetInnerHTML property to render table, dashboard, and feature descriptions without applying any form of HTML sanitization or encoding. This architectural decision allows raw HTML content provided by external data sources to be injected directly into the Document Object Model (DOM) as executable script contexts rather than inert text nodes. The vulnerability is particularly severe because it affects multiple entry points within the application's user interface, specifically impacting how metadata and search results are displayed to end users.
The attack vector leverages the integration between Amundsen and its underlying data services, such as Elasticsearch or a generic metadata service. An attacker with write access to these backend systems can inject malicious markup into description fields associated with resources. By embedding HTML elements like img tags equipped with event handlers such as onerror, the attacker ensures that when a victim user views search results containing this poisoned content, the browser attempts to load the image resource. Since the source is invalid or non-existent, the error handler triggers immediately, executing arbitrary JavaScript code within the context of the Amundsen application's origin. This bypasses same-origin policy protections because the script runs as if it were part of the legitimate application itself.
The operational impact of this vulnerability extends beyond simple defacement or alert boxes. Because the malicious scripts execute in the user's browser with full access to cookies, session tokens, and local storage associated with Amundsen, an attacker can perform account takeover attacks by stealing authentication credentials. Furthermore, the compromised context allows for actions such as modifying application state, exfiltrating sensitive metadata about data assets stored within the platform, or using the victim’s authenticated session to make unauthorized API calls against internal services that trust cookies from this domain. This effectively turns any user viewing a search result into an unwitting participant in the attack chain, facilitating widespread compromise without requiring direct interaction with malicious links outside of normal browsing behavior.
From a classification perspective, this vulnerability aligns with CWE-79: Improper Neutralization of Input During Web Page Generation, commonly known as Cross-Site Scripting (XSS). Specifically, it represents stored XSS because the malicious payload is persisted in the backend database and served to multiple victims over time. In terms of adversary tactics, this maps directly to MITRE ATT&CK technique T1059: Command and Scripting Interpreter, where JavaScript serves as the vehicle for executing commands within the victim's environment. It also relates to T1204: User Execution, although in this case, execution is triggered automatically by rendering rather than explicit user interaction with a file or link.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective technical fix involves implementing robust HTML sanitization libraries such as DOMPurify before passing any content to dangerouslySetInnerHTML. This ensures that only safe, whitelisted tags are rendered while stripping out scripts, event handlers, and other dangerous constructs. Alternatively, developers should refactor the rendering logic to avoid using innerHTML entirely by constructing elements programmatically or using text nodes for user-generated content where HTML formatting is not strictly required. On an infrastructure level, implementing a Content Security Policy (CSP) with strict directives can mitigate the impact of any remaining XSS vulnerabilities by restricting script execution sources and preventing inline scripts from running unless explicitly allowed via nonces or hashes. Regular security audits focusing on data flow analysis for user-supplied input are also recommended to identify similar patterns in other components before they can be exploited.