AI Threat AlertA flaw in Coder's login flow used a hardcoded placeholder hash derived from the string 'hunter2' when comparing passwords for accounts with no stored hash, so any unauthenticated attacker submitting 'hunter2' as the password could distinguish nonexistent accounts, SSO-only accounts, and password-based accounts by the HTTP status code returned (403 vs. 401). With 6,417 downstream dependents and Coder widely used to provision cloud development environments — including workspaces for AI/ML engineering teams — this lets an attacker cheaply enumerate valid users and their authentication method, a direct enabler for credential-stuffing lists and targeted phishing against real employees. The severity is genuinely low (CVSS 3.1 base 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) — no EPSS score is published, it's not in CISA KEV, and no public exploit or scanner template exists, so this is not an active-exploitation emergency; the vendor itself notes the timing side channel is noisy and only confirms account existence, with no authentication bypass or data access possible. Security teams running self-hosted Coder should patch to 2.34.2, 2.33.8, 2.32.7, or 2.29.17 (ESR) — there is no workaround — and can retroactively detect exploitation attempts by scanning auth logs for repeated login attempts using the literal password 'hunter2' across many usernames.
What is the risk?
Low risk overall. Exploitability is theoretically favorable (unauthenticated, no user interaction, network vector) but the CVSS AC:H rating and the vendor's own note that the timing signal is noisy limit reliable real-world abuse. Impact is confined to confidentiality (account existence and auth-provider disclosure) — no integrity or availability impact, no authentication bypass, no credential or data access results from this bug alone. No EPSS score, no CISA KEV listing, and no public exploit code or Nuclei template exist, indicating no observed or imminent mass exploitation. Exposure is limited to self-hosted Coder deployments with an internet-facing login endpoint; the main downstream risk is that harvested account/provider data feeds follow-on credential-stuffing or phishing rather than direct compromise via this flaw.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Anthropic Python | go | >= 2.34.0, < 2.34.2 | 2.34.2 |
Do you use Anthropic Python? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 stepUpgrade to the patched release for your line — 2.34.2, 2.33.8, 2.32.7, or 2.29.17 (ESR) — there is no workaround, so patching is the only mitigation. After patching, review authentication logs for pre-patch reconnaissance: look for repeated failed login attempts using the password 'hunter2' across many distinct usernames from a single source, the signature of this technique. Rate-limit and alert on abnormal login-attempt volume against the login endpoint generally, since account enumeration is a common precursor to credential-stuffing and phishing campaigns. If Coder-hosted workspaces have access to sensitive AI assets (model weights, training data, API keys), treat any flagged enumeration activity as a trigger to review access logs on those downstream systems too.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-8fxq-53rx-ph5f?
A flaw in Coder's login flow used a hardcoded placeholder hash derived from the string 'hunter2' when comparing passwords for accounts with no stored hash, so any unauthenticated attacker submitting 'hunter2' as the password could distinguish nonexistent accounts, SSO-only accounts, and password-based accounts by the HTTP status code returned (403 vs. 401). With 6,417 downstream dependents and Coder widely used to provision cloud development environments — including workspaces for AI/ML engineering teams — this lets an attacker cheaply enumerate valid users and their authentication method, a direct enabler for credential-stuffing lists and targeted phishing against real employees. The severity is genuinely low (CVSS 3.1 base 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) — no EPSS score is published, it's not in CISA KEV, and no public exploit or scanner template exists, so this is not an active-exploitation emergency; the vendor itself notes the timing side channel is noisy and only confirms account existence, with no authentication bypass or data access possible. Security teams running self-hosted Coder should patch to 2.34.2, 2.33.8, 2.32.7, or 2.29.17 (ESR) — there is no workaround — and can retroactively detect exploitation attempts by scanning auth logs for repeated login attempts using the literal password 'hunter2' across many usernames.
Is GHSA-8fxq-53rx-ph5f actively exploited?
No confirmed active exploitation of GHSA-8fxq-53rx-ph5f has been reported, but organizations should still patch proactively.
How to fix GHSA-8fxq-53rx-ph5f?
Upgrade to the patched release for your line — 2.34.2, 2.33.8, 2.32.7, or 2.29.17 (ESR) — there is no workaround, so patching is the only mitigation. After patching, review authentication logs for pre-patch reconnaissance: look for repeated failed login attempts using the password 'hunter2' across many distinct usernames from a single source, the signature of this technique. Rate-limit and alert on abnormal login-attempt volume against the login endpoint generally, since account enumeration is a common precursor to credential-stuffing and phishing campaigns. If Coder-hosted workspaces have access to sensitive AI assets (model weights, training data, API keys), treat any flagged enumeration activity as a trigger to review access logs on those downstream systems too.
What systems are affected by GHSA-8fxq-53rx-ph5f?
This vulnerability affects the following AI/ML architecture patterns: cloud development/MLOps workspace platforms, agent development environments.
What is the CVSS score for GHSA-8fxq-53rx-ph5f?
GHSA-8fxq-53rx-ph5f has a CVSS v3.1 base score of 3.7 (LOW).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0087Gather Victim Identity InformationCompliance Controls Affected
What are the technical details?
Original Advisory
### Summary `userpassword.Compare()` substituted a placeholder hash derived from the well-known string `"hunter2"` when the stored hash was empty. Submitting `"hunter2"` therefore matched accounts with no password hash (nonexistent users and SSO-only users) and a subsequent login-type check returned an HTTP 403 that disclosed the account's login type, versus 401 for password users. > **Note:** Practical exploitation is limited because the timing side channel is noisy and only reveals whether an account exists. ### Impact An unauthenticated attacker could enumerate valid accounts and their authentication provider by submitting logins with the password `"hunter2"`, distinguishing nonexistent users, SSO users (provider revealed) and password users from the response. This aids credential-stuffing and targeted phishing. No authentication bypass or data access resulted. ### Patches The fix derives the timing-defense placeholder from a secure random value that no supplied password can match. The fix was backported to all supported release lines: | Release line | Patched version | |---|---| | 2.34 | [v2.34.2](https://github.com/coder/coder/releases/tag/v2.34.2) | | 2.33 | [v2.33.8](https://github.com/coder/coder/releases/tag/v2.33.8) | | 2.32 | [v2.32.7](https://github.com/coder/coder/releases/tag/v2.32.7) | | 2.29 (ESR) | [v2.29.17](https://github.com/coder/coder/releases/tag/v2.29.17) | ### Workarounds None. ### References - Fix: #26205 ### Credits We'd like to thank Anthropic's Security Team (ANT-2026-22433) for independently disclosing this issue!
Exploitation Scenario
An attacker targeting an organization's engineering org first identifies that it self-hosts Coder (e.g., via a coder.<company>.com subdomain or job postings referencing Coder). They script a login sweep against a list of likely usernames (firstname.lastname, harvested from LinkedIn or GitHub commit history) using the password 'hunter2' for each. The response code — 403 for SSO-only or nonexistent accounts vs. 401 for password accounts, though noisy — lets the attacker build a partial map of which accounts exist and, for SSO users, confirms external identity-provider use. The attacker then uses this validated account list to run credential-stuffing attacks against those accounts on other services, or crafts a targeted phishing email impersonating IT support to the confirmed SSO users, increasing the credibility and hit rate of the follow-on attack rather than gaining any direct access via Coder itself.
Weaknesses (CWE)
CWE-203 — Observable Discrepancy: The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor.
- [Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
- [Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:NReferences
Timeline
Related Vulnerabilities
CVE-2026-9460310.0Podman: checkpoint images override sandbox on run
Same package: anthropicCVE-2026-544498.8LangBot: RCE via arbitrary STDIO MCP command
Same package: anthropicCVE-2026-277758.8Gitea: cached permission check allows repo takeover
Same package: anthropicCVE-2026-75748.7Claude Desktop: VM integrity bypass enables RCE
Same package: anthropicCVE-2026-554298.7Coder: cross-workspace agent hijack via app ID reuse
Same package: anthropic