GHSA-8fxq-53rx-ph5f: Anthropic Python

### 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...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Anthropic Python	go	>= 2.34.0, < 2.34.2	`2.34.2`
3.8K 6.4K dependents Pushed 5d ago 90% patched ~11d to patch Full package profile →

Do you use Anthropic Python? You're affected.

How severe is it?

CVSS 3.1

3.7 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What is the attack surface?

AV Network

AC High

PR None

UI None

S Unchanged

C Low

I None

A None

What should I do?

Patch available

Update Anthropic Python to version 2.34.2

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-8fxq-53rx-ph5f?

### 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!

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?

Update to patched version: Anthropic Python 2.34.2.

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 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!

Weaknesses (CWE)

CWE-203 Observable Discrepancy Primary CWE-204 Observable Response Discrepancy Primary

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.