Claude Code CVE-2026-103012

Requires local access to a device on which a Claude Code API key was already stored (via an earlier /login or written directly to the configuration), and an active Claude Enterprise or Team session that authenticated with the org account. The flaw only manifests for organizations using server-managed (cloud policy) settings - Claude for Enterprise from version 2.0.68 and Claude for Work/Team from 2.1.38. The complete-policy-loss outcome additionally requires that no managed settings had ever been cached on the machine; otherwise a stale cached copy continues to apply. Endpoint-managed settings delivered via MDM or local files are NOT affected and continue to enforce correctly. Fixed in 2.1.260 (already delivered via standard auto-update); manual-update users must upgrade.

This is a low-priority issue confirmed by the CVSS 4.0 base score of 2.0. The vendor vector (AV:L/AC:L/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N) is internally consistent with the description: exploitation requires local access to a device that already holds a stored API key (AV:L), an authenticated Enterprise/Team session (PR:L), and - for the most impactful 'no policy at all' outcome - the additional precondition that no managed settings were ever cached (AT:P). The only impact is a low integrity effect (VI:L): the session runs as the organization account but fails to receive or refresh server-managed policy such as permission deny rules, model restrictions and managed-only locks. There is no confidentiality or availability impact (VC:N/VA:N), so the 'Information Disclosure' tag overstates the nature of the flaw - this is a policy-enforcement/ordering defect (CWE-696, incorrect behavior order in credential selection), not data exposure. No EPSS score, CISA KEV listing, POC, or SSVC decision data was provided; there is no public exploit identified at time of analysis. There is no signal conflict between network/local vectors - every source points to a local, authenticated, integrity-only weakness. The realistic worst case is a user on an already-trusted device operating outside intended org guardrails, not remote compromise, so this warrants routine patching rather than emergency response.

On a device that already stores a Claude Code API key (from a prior /login or a key written directly to config), a user signs in with their valid Claude Enterprise or Team account and launches a session. Claude Code incorrectly prefers the stored key when fetching the organization's server-managed settings; the endpoint rejects that key, so the session either starts with no server-managed policy (if none was ever cached) or keeps applying a stale cached policy while still operating as the org account, silently bypassing controls like permission deny rules and model restrictions. No public exploit exists and the flaw requires local access to such a preconfigured device.