Coder CVE-2026-111933

No special target configuration is required - the oracle works against default deployments of Coder (self-hosted) on any version before 2.29.17, 2.32.7, 2.33.8, or 2.34.2, because userpassword.Compare() substitutes a placeholder hash derived from 'hunter2' whenever a stored password hash is empty. The specific precondition is that a probed account has an empty stored hash (nonexistent users and SSO-only users), which is what the password 'hunter2' matches; the subsequent login-type check then returns 403 (login type disclosed) versus 401 for real password users. Limiting factors: exploitation is unauthenticated and remote but yields only account-existence and authentication-provider enumeration - no authentication bypass, credential recovery, or data access - and the vendor notes the timing component is noisy, so value is confined to reconnaissance for credential-stuffing and phishing.

This is a genuine but modest-severity information-disclosure issue (CWE-203, observable discrepancy), not a high-impact priority. The input CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) describes a remote, unauthenticated flaw but with elevated attack complexity and a present attack requirement, consistent with the base score of 6.3 (medium) and VC:L / VI:N / VA:N limiting impact to low confidentiality only. No EPSS score, no CISA KEV listing, and no public exploit were provided, so there is no signal of active or widespread exploitation; by the precision rules this is 'no public exploit identified at time of analysis.' The vendor advisory itself explicitly downgrades practical risk, noting the timing side channel is noisy and that the bug 'only reveals whether an account exists' with 'no authentication bypass or data access.' Signals are consistent rather than conflicting: the deterministic 403-vs-401 response-code oracle is reliable, but the overall value to an attacker is limited to account/login-type enumeration that aids downstream credential-stuffing and phishing. One nuance worth noting: the vendor assigned AC:H/AT:P largely because of the noisy timing channel, yet the HTTP 403-vs-401 distinction is itself deterministic, which arguably makes enumeration easier than the complexity metric implies - verify against the fix (PR #26205) behavior.

An unauthenticated attacker scripts login requests against a public Coder instance, submitting the well-known password 'hunter2' for a list of candidate usernames. Accounts with an empty stored hash (nonexistent users and SSO-only users) match the placeholder and return HTTP 403 disclosing login type, while password users return 401, letting the attacker enumerate valid accounts and identify SSO providers. No public exploit code was identified, but the technique is trivial to reproduce from the advisory.