CVE-2026-111932 in Coder
Summary
by MITRE • 10/17/2026
Coder before 2.29.17, 2.30.0 before 2.32.7, 2.33.0 before 2.33.8, and 2.34.0 before 2.34.2 contains a stored HTML injection vulnerability because the ApplicationName and LogoURL appearance settings are rendered into HTML output without sufficient escaping. Attackers with the Owner role can store HTML markup in these settings that renders in the Coder dashboard and in SMTP notification emails sent to other deployment users.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/17/2026
The identified security flaw resides within multiple versions of the Coder application, specifically affecting releases prior to 2.29.17, 2.30.x before 2.32.7, 2.33.x before 2.33.8, and 2.34.x before 2.34.2. This vulnerability is classified as a stored cross-site scripting issue, technically categorized under CWE-79: Improper Neutralization of Input During Web Page Generation commonly known as Stored XSS or Persistent Cross-Site Scripting. The root cause lies in the insufficient input validation and output encoding mechanisms applied to two specific configuration parameters: ApplicationName and LogoURL. These settings are intended for administrative customization but are rendered directly into HTML contexts without proper sanitization, allowing malicious actors to inject executable script payloads that persist within the application's database or configuration store.
The operational impact of this vulnerability is significant due to its persistence and broad reach. Unlike reflected XSS attacks which require tricking a user into clicking a crafted link, stored vulnerabilities remain active until manually removed by an administrator. In this case, any HTML markup injected via the ApplicationName or LogoURL fields will be automatically rendered every time the Coder dashboard loads for any authenticated user. Furthermore, because these values are also included in SMTP notification emails sent to deployment users, the attack vector extends beyond the web interface into email clients. This dual-vector approach ensures that a single successful injection can compromise multiple endpoints and user sessions simultaneously without requiring further interaction from the attacker after the initial setup.
The exploitation of this flaw requires an attacker with at least the Owner role within the Coder environment. While this restricts the threat model to authenticated users with elevated privileges, it does not eliminate risk. Insider threats or compromised administrative accounts can leverage these permissions to inject malicious scripts into the ApplicationName and LogoURL fields. Once injected, when other deployment users access their dashboard or receive notification emails, their browsers will execute the embedded JavaScript code in the context of the Coder application's domain. This allows attackers to perform actions such as session hijacking by stealing authentication cookies, performing keylogging to capture sensitive credentials, redirecting users to phishing sites, or executing arbitrary commands on behalf of the victim if combined with other browser-side vulnerabilities.
From a threat intelligence perspective, this vulnerability aligns with MITRE ATT&CK technique T1059: Command and Control via Application Layer Protocol for initial access through social engineering in emails, and more directly T1189: Drive-by Client Side Scripting where the victim is compromised without any explicit user action beyond visiting a webpage or opening an email. The persistence of the payload means that even after the attacker's account is disabled, the malicious code remains active until the configuration values are corrected, creating a long-term security debt for organizations using affected versions.
To mitigate this vulnerability, immediate remediation involves upgrading to patched versions of Coder: version 2.34.2 or later, 2.33.8 or later, 2.32.7 or later, and 2.29.17 or later. These updates implement proper output encoding for the ApplicationName and LogoURL fields, ensuring that any special characters are escaped before being rendered in HTML contexts. For organizations unable to upgrade immediately due to operational constraints, a temporary mitigation involves restricting access to the Owner role strictly to trusted administrators and auditing existing configuration values for suspicious script tags or event handlers such as onerror or onload attributes within the logo URL field. Additionally, implementing Content Security Policy headers can help mitigate the impact of any residual XSS by restricting the sources from which scripts are allowed to execute, although this is not a substitute for fixing the underlying input validation flaw.