CVE-2026-111933 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 user enumeration vulnerability because userpassword.Compare() substitutes a placeholder hash derived from the string "hunter2" when a stored password hash is empty. Unauthenticated attackers can submit logins with the password "hunter2" and distinguish HTTP 403 from 401 responses to enumerate valid accounts and reveal the authentication provider of SSO-only users.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in Coder versions prior to 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 represents a critical user enumeration flaw rooted in improper handling of empty password hashes during the authentication process. This issue stems from a specific implementation detail within the userpassword.Compare function, which is responsible for validating credentials against stored secrets. When an account possesses no stored password hash, indicating that the user relies exclusively on Single Sign-On or another external authentication provider rather than a local password, the system fails to handle this state correctly. Instead of rejecting the login attempt immediately with a generic failure response, the function substitutes a placeholder hash derived from the literal string "hunter2" for comparison purposes. This design choice creates a predictable side channel that attackers can exploit to determine account validity and authentication methods without valid credentials.
From an operational perspective, this flaw allows unauthenticated actors to perform user enumeration attacks with high precision. By submitting login attempts using the password "hunter2," an attacker can observe distinct HTTP response codes returned by the server. Specifically, a 401 Unauthorized response indicates that the username exists but the provided password is incorrect for accounts where local passwords are expected or where the placeholder logic applies differently. Conversely, a 403 Forbidden response suggests that the account exists but authentication via this method is not permitted because it relies on an external provider such as SSO. This distinction enables attackers to map out valid usernames within the organization and simultaneously identify which users utilize Single Sign-On versus local password authentication. Such information gathering significantly aids in subsequent targeted attacks, including phishing campaigns or credential stuffing against accounts that do support local passwords.
The technical root cause aligns with CWE-204: Observable Response Discrepancy, where an application behaves differently depending on the input provided, allowing attackers to infer internal states. Additionally, this vulnerability facilitates CWE-287: Improper Authentication by enabling unauthorized identification of valid targets, which is a precursor step often categorized under ATT&CK technique T1589.001: Gather Victim Identity Information - Credentials. The use of a static placeholder hash like "hunter2" introduces predictability into what should be a randomized or strictly rejected process for accounts lacking local secrets. This violates the principle that authentication failures for non-applicable methods should not leak information about account existence or configuration details to unauthenticated parties.
Mitigation strategies require immediate updates to all affected Coder instances, specifically upgrading to version 2.32.7 and later for the 2.30 series, 2.33.8 and later for the 2.33 series, 2.34.2 and later for the 2.34 series, or any release after 2.29.17 in the older branch. Beyond patching, organizations should implement rate limiting on authentication endpoints to slow down automated enumeration attempts. Monitoring logs for repeated login failures associated with specific usernames can also help detect ongoing exploitation activities. Furthermore, security architectures should ensure that all authentication paths return identical error messages and status codes regardless of whether a user exists or what their preferred auth method is, thereby eliminating the observable discrepancies that this vulnerability exploits.