GHSA-xg4h-6gfc-h4m8: Anthropic Python

Q: Is GHSA-xg4h-6gfc-h4m8 actively exploited?

No confirmed active exploitation of GHSA-xg4h-6gfc-h4m8 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-xg4h-6gfc-h4m8?

Update to patched version: Anthropic Python 3.7.1.

Q: What is the CVSS score for GHSA-xg4h-6gfc-h4m8?

No CVSS score has been assigned yet.

### Impact _What kind of vulnerability is it? Who is impacted?_ A user granted READ permission on a single, exact key can use the Watch gRPC API with `clientv3.WithFromKey()` (an open-ended, "from this key to the end of the keyspace" watch) to receive watch events for every key lexicographically...

Full CISO analysis pending enrichment.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Anthropic Python	go	>= 3.7.0-alpha.0, < 3.7.1	`3.7.1`
3.7K 5.9K dependents Pushed 7d ago 89% patched ~11d to patch Full package profile →

Do you use Anthropic Python? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

N/A

What should I do?

Patch available

Update Anthropic Python to version 3.7.1

Which compliance frameworks are affected?

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

Frequently Asked Questions

What is GHSA-xg4h-6gfc-h4m8?

### Impact _What kind of vulnerability is it? Who is impacted?_ A user granted READ permission on a single, exact key can use the Watch gRPC API with `clientv3.WithFromKey()` (an open-ended, "from this key to the end of the keyspace" watch) to receive watch events for every key lexicographically greater than or equal to their permitted key — not just the one key they were granted. This is an authorization bypass in etcd's RBAC enforcement for the Watch API; Range/Get and DeleteRange requests are not affected. It only affects clusters with authentication enabled — clusters running without auth already allow unrestricted read access. ### Patches _Has the problem been patched? What versions should users upgrade to?_ This vulnerability is patched in the following versions: - etcd 3.7.1 - etcd 3.6.14 - etcd 3.5.33 ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ If upgrading is not immediately possible, the following mitigations reduce exposure: - Audit READ grants. Any READ grant — even on one key — can be leveraged via Watch to read everything after it. Review who holds READ permissions and revoke/tighten any you wouldn't trust with full read access. - Restrict network access. Limit which hosts can reach etcd's client (gRPC) port via firewall rules or network policy, reducing who can attempt exploitation. ### Reporter - Luis Toro ([@lobuhi](https://github.com/lobuhi) on Github) - Anthropic and Adam Korczynski ([@AdamKorcz](https://github.com/AdamKorcz) on Github)

Is GHSA-xg4h-6gfc-h4m8 actively exploited?

No confirmed active exploitation of GHSA-xg4h-6gfc-h4m8 has been reported, but organizations should still patch proactively.

How to fix GHSA-xg4h-6gfc-h4m8?

Update to patched version: Anthropic Python 3.7.1.

What is the CVSS score for GHSA-xg4h-6gfc-h4m8?

No CVSS score has been assigned yet.

What are the technical details?

Original Advisory

### Impact _What kind of vulnerability is it? Who is impacted?_ A user granted READ permission on a single, exact key can use the Watch gRPC API with `clientv3.WithFromKey()` (an open-ended, "from this key to the end of the keyspace" watch) to receive watch events for every key lexicographically greater than or equal to their permitted key — not just the one key they were granted. This is an authorization bypass in etcd's RBAC enforcement for the Watch API; Range/Get and DeleteRange requests are not affected. It only affects clusters with authentication enabled — clusters running without auth already allow unrestricted read access. ### Patches _Has the problem been patched? What versions should users upgrade to?_ This vulnerability is patched in the following versions: - etcd 3.7.1 - etcd 3.6.14 - etcd 3.5.33 ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ If upgrading is not immediately possible, the following mitigations reduce exposure: - Audit READ grants. Any READ grant — even on one key — can be leveraged via Watch to read everything after it. Review who holds READ permissions and revoke/tighten any you wouldn't trust with full read access. - Restrict network access. Limit which hosts can reach etcd's client (gRPC) port via firewall rules or network policy, reducing who can attempt exploitation. ### Reporter - Luis Toro ([@lobuhi](https://github.com/lobuhi) on Github) - Anthropic and Adam Korczynski ([@AdamKorcz](https://github.com/AdamKorcz) on Github)

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.