--- title: "Claude Code Managed Settings Skipped by a Stored API Key - CVE-2026-103012 | Anomity Blog" description: "CVE-2026-103012: a stored API key could make Claude Code skip your org's server-managed policy. Fixed in 2.1.260, plus the 2.1.285-2.1.289 deny-rule fixes." url: "https://anomity.ai/blog/claude-code-managed-settings-bypass-cve-2026-103012/" source: html --- On this page - What to do first - How Anomity surfaces and governs it - What CVE-2026-103012 did - Five releases of permission fixes - Stable is not latest - What to change in governance - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Claude Code Managed Settings Skipped by a Stored API Key - CVE-2026-103012 ![Anomity robot illustrating Claude Code Managed Settings Skipped by a Stored API Key - CVE-2026-103012] Insights # Claude Code Managed Settings Skipped by a Stored API Key - CVE-2026-103012 Anomity Research Anomity Research · Oct 5, 2026 · 5 min read Share: Copied TL;DR - CVE-2026-103012 (GHSA-gfvf-j8jh-jxxw, Low , CVSS 4.0 2.0 ) affects Claude Code 2.0.68 up to 2.1.260 for Claude for Enterprise, and 2.1.38 up to 2.1.260 for Team. Fixed in 2.1.260 . Action: confirm every machine is on 2.1.260 or later , especially manual updaters. - When a machine also held a stored API key , Claude Code used it instead of the Enterprise or Team sign-in to fetch server-managed settings . If that fetch was rejected, the session started with no org policy , or a stale cached copy , while still acting as the org account. - Skipped policy includes permission deny rules, model restrictions and managed-only locks . Endpoint-managed settings (MDM or file-based) were not affected. - Separately, Claude Code 2.1.285 through 2.1.289 (September 29 to October 3) shipped at least ten fixes and changes for cases where deny rules, ask rules, permission ceilings or PreToolUse hooks did not hold. On October 5 npm's stable tag still points to 2.1.285 . - The pattern: policy that exists in config is not policy that ran. Pin the version, prefer endpoint-delivered policy for critical rules, and keep a record of actual allow and deny decisions. **The short version:** for months, a leftover API key on a laptop could make Claude Code start a session **without your organization's server-managed policy**. **CVE-2026-103012** is rated Low and is **fixed in Claude Code 2.1.260**. The bigger story is the week that followed: five releases, at least ten fixes and changes for **deny rules, permission ceilings and hooks that did not hold**, and a stable channel that does not have the latest of them. Anthropic published **GHSA-gfvf-j8jh-jxxw** on **September 29, 2026**, and the CVE record followed on September 30. It credits **Tamas Voros of the NVIDIA AI Red Team**. The fix itself shipped in **2.1.260 on September 3**, whose changelog reads: "Fixed managed settings not loading for claude.ai Enterprise/Team users who also had a leftover API key from an earlier `/login`." ## What to do first - Confirm every machine runs Claude Code 2.1.260 or later . Manual updaters and pinned installs are the ones at risk. - Find machines that hold a stored Anthropic API key alongside an Enterprise or Team sign-in, and remove keys that are not needed. - Deliver rules you cannot afford to lose through endpoint-managed settings (MDM or the managed settings file), which the advisory says were not affected . - Decide whether your fleet tracks npm stable (2.1.285 on October 5) or latest (2.1.289), knowing which permission fixes each includes. ## How Anomity surfaces and governs it **See it.** The Endpoint Sensor inventories Claude Code on every managed endpoint with its version, hooks and configured MCP servers, and inventories secrets, including stored API keys, with values redacted on the endpoint. That turns this advisory into three lists: machines below 2.1.260, machines holding a stored key, and machines on builds older than 2.1.289. Metadata only leaves the device. **Record what policy did.** At the Claude Code PreToolUse hook, Anomity returns **allow, deny or log** before a tool call runs. Hook-based enforcement, ours included, depends on Claude Code invoking the hook, and 2.1.288 fixed a case where it did not, which is one more reason the version inventory matters. Every decision lands in a **90-day audit trail** and routes to SIEM, Slack, email or Jira, so "was the rule enforced on that laptop last Tuesday?" has an answer. ## What CVE-2026-103012 did Claude for Enterprise and Team admins can push **server-managed settings**: permission deny rules, model restrictions and managed-only locks that users cannot override. Claude Code fetches them when a session starts. Per the advisory, Claude Code selected an API key it had stored, from an earlier `/login` or written to its configuration, **ahead of the user's valid Enterprise or Team sign-in** when making that fetch, even though the session itself authenticated with the organization account. When the settings endpoint rejected the stored key, one of two things happened: - No policy. If no managed settings had been cached on the machine before, the session started without the organization's server-managed policy. - Stale policy. If a cached copy existed, the session kept applying it and stopped receiving later policy changes . In both cases the session continued to operate **as the organization's account**. Enterprise organizations were affected from **2.0.68**, Team organizations from **2.1.38**, when server-managed settings became available to them. The rating is Low, CVSS 4.0 2.0, because triggering it required local access to a device holding such a key. The assurance problem is larger than the score: nothing in the console showed that a given session had run without your rules. ## Five releases of permission fixes Between **September 29 and October 3**, Claude Code shipped 2.1.285 through 2.1.289. Their changelog entries include the following fixes and changes for rules and hooks that did not hold. None has a CVE. Version What did not hold 2.1.285 PowerShell permission checks skipped deny and ask rules, and cached the failure, when the command parser failed to start (for example, out of memory) 2.1.287 Organization per-tool permission ceilings were silently dropped for an MCP tool named `__proto__` 2.1.287 Whole-tool Bash allow rules and allowing hooks now prompt, rather than run, for shell writes to files Claude Code's file tools refuse outright, such as the host credentials file 2.1.288 PreToolUse and PermissionRequest hooks were skipped when matching failed or the tool input could not be serialized to JSON; the call is now blocked 2.1.288 A dangerous `rm` inside `bash -c` or `sh -c` ran without a prompt in bypassPermissions mode or under a shell allow rule 2.1.289 Bash deny and ask rules missed a command behind an environment-variable prefix with an expanded value, such as `TZ="$HOME" rm -rf build`, under sandbox auto-allow 2.1.289 A Bash deny or ask rule was skipped under sandbox auto-allow when a bare variable assignment came before the command 2.1.289 `Read` deny rules did not apply to files @-mentioned, changed or selected in the IDE through a symlink 2.1.289 A deny or ask rule on a nested part of a compound command did not hold over a user-installed mod's approval on managed machines 2.1.289 A user-installed plugin could rewrite the descriptions of an organization-managed MCP server's sign-in tools One behavior change in 2.1.285 is worth knowing too: when the OS denies reading the **managed settings file**, Claude Code now **warns and starts without that file's policies** instead of refusing to start. Other read errors and unparseable files still stop every session. A file-permission mistake on that path now means a session without those policies, so monitor for it. ## Stable is not latest On **October 5, 2026**, npm's `stable` tag for `@anthropic-ai/claude-code` points to **2.1.285** and `latest` to **2.1.289**, released October 3. A fleet that installs the stable tag has the CVE-2026-103012 fix and the 2.1.285 fixes, but **not the 2.1.287 to 2.1.289 fixes** in the table above. That may be the right trade-off for your fleet. It should be a decision, not a default. We walk through how rules, modes and hooks interact in [how Claude Code permissions work](https://anomity.ai/blog/how-claude-code-permissions-work/) and the practical setup in [the Claude Code permissions and hooks hardening guide](https://anomity.ai/blog/claude-code-permissions-hooks-hardening-guide/). The same string-matching gap showed up this week outside Claude Code, in [Ollama's agent-mode approval bypass, CVE-2026-102697](https://anomity.ai/blog/ollama-agent-mode-bash-approval-bypass-cve-2026-102697/). ## What to change in governance - Treat policy delivery as a dependency. Put critical deny rules in endpoint-managed settings as well as server-managed settings. - Inventory versions, not intentions. Know which Claude Code build runs on each endpoint, and which npm channel it follows. - Remove stray credentials. A stored API key next to an Enterprise sign-in caused this one; keys left on laptops cause others. - Keep a decision record. An audit trail of allow and deny decisions is how you find out a rule stopped applying, instead of assuming it did. CVE-2026-103012 is Low severity and already fixed for most auto-updating users. The lesson is not: a policy in the admin console is a statement of intent, and only the endpoint can tell you whether it ran. For rolling Claude Code out at scale, see [deploying Claude Code across a fleet](https://anomity.ai/blog/deploying-claude-code-across-a-fleet-guide/). To see which policy actually applied on each machine, [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions Am I affected by CVE-2026-103012? Your organization was exposed if it uses server-managed settings for Claude Code on Claude for Enterprise (Claude Code 2.0.68 or later) or Claude for Work Team (2.1.38 or later, when server-managed settings became available), and some machines run a version earlier than 2.1.260 while also holding a stored API key from an earlier /login or written directly to configuration. Anthropic says users on standard auto-update already have the fix; manual updaters should move to 2.1.260 or later. What exactly went wrong? Claude Code chose a stored API key ahead of the user's valid Enterprise or Team sign-in when fetching the organization's server-managed settings, even though the session itself authenticated with the organization account. When the settings endpoint rejected the key, the session started without the server-managed policy, or kept applying a previously cached copy and stopped receiving later changes. The advisory classifies it as CWE-696, incorrect behavior order. Why is it rated Low if it removes the whole policy? Triggering it required local access to a device that held such a stored API key, and the no-policy case also required that no managed settings had been cached on the machine before. The CVSS 4.0 vector reflects local access, low privileges and low integrity impact. The practical risk for security teams is less about attackers and more about assurance: you could not tell from the admin console that a given session ran without your rules. Were MDM or file-based managed settings affected? No. The advisory says endpoint-managed settings delivered by MDM or a managed settings file were not affected. Only server-managed settings fetched at session start were. That is a useful design input: rules you cannot afford to lose can be delivered by both channels. What changed in Claude Code 2.1.285 to 2.1.289? The changelog for those five releases lists fixes including: PowerShell permission checks skipping deny and ask rules when the command parser failed to start (2.1.285); organization per-tool permission ceilings dropped for an MCP tool named __proto__ (2.1.287); PreToolUse and PermissionRequest hooks being skipped when matching failed or tool input could not be serialized, now blocked instead (2.1.288); a dangerous rm inside bash -c running without a prompt in bypassPermissions mode or under a shell allow rule (2.1.288); and Bash deny rules missing commands behind an environment-variable prefix under sandbox auto-allow (2.1.289). None of these has a CVE. Which Claude Code version should we pin? At minimum 2.1.260 for CVE-2026-103012. For the permission fixes, 2.1.289 was the latest release on October 5, 2026, while the npm stable tag pointed to 2.1.285. Machines that install the stable tag are fixed for CVE-2026-103012 but do not yet have the 2.1.287 to 2.1.289 fixes. Decide deliberately which channel your fleet tracks, and check the version that actually runs on each endpoint. How does Anomity help with this? The Anomity Endpoint Sensor inventories Claude Code and other agents on every managed endpoint with their versions, hooks and configured MCP servers, plus secrets such as stored API keys with values redacted on the endpoint. That answers which machines run a version below 2.1.260, which also hold a stored key, and which run builds older than 2.1.289. At the Claude Code PreToolUse hook, Anomity returns allow, deny or log before a tool call runs, and decisions land in a 90-day audit trail that routes to SIEM, Slack, email or Jira, so you have a record of what policy actually did. ## Related [Insights ### MCP Fetch Server SSRF - CVE-2026-104120: Fix Merged, No Release Yet CVE-2026-104120: the reference MCP fetch server can be steered to localhost and cloud metadata. A fix merged Oct 5 on v2/main; PyPI 2026.8.18 lacks it. Anomity Research · Oct 5, 2026 · 5 min](https://anomity.ai/blog/mcp-server-fetch-ssrf-cve-2026-104120/) [Insights ### Claude Fable 5.1 and Mythos 5.1: One Model, Two Safeguard Tiers, and a Fallback Your Security Team Will Hit Fable 5.1 and Mythos 5.1 are one model with two safeguard tiers. Flagged cyber requests in Claude Code fall back to Opus 4.8. What it means for you. Anomity Research · Oct 2, 2026 · 5 min](https://anomity.ai/blog/claude-fable-5-1-mythos-5-1-model-fallback-governance/) [Insights ### NVIDIA's Open Agent Safety Platform Puts Controls Outside the Agent. Now Count the Agents Outside It. OpenShell sandboxes agents with policy outside their reach, and Sentry watches from the DPU. Both cover the agents you enroll. The rest need a list first. Anomity Research · Oct 2, 2026 · 6 min](https://anomity.ai/blog/nvidia-open-agent-safety-platform-openshell-sentry/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Claude Code Managed Settings Skipped by a Stored API Key - CVE-2026-103012", "description": "CVE-2026-103012: a stored API key could make Claude Code skip your org's server-managed policy. Fixed in 2.1.260, plus the 2.1.285-2.1.289 deny-rule fixes.", "datePublished": "2026-10-05", "dateModified": "2026-10-05", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/anomity-logo.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/claude-code-managed-settings-bypass-cve-2026-103012/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/prompt-injection.jpg", "width": 1200, "height": 630 }, "articleSection": "Insights", "url": "https://anomity.ai/blog/claude-code-managed-settings-bypass-cve-2026-103012/" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Am I affected by CVE-2026-103012?", "acceptedAnswer": { "@type": "Answer", "text": "Your organization was exposed if it uses server-managed settings for Claude Code on Claude for Enterprise (Claude Code 2.0.68 or later) or Claude for Work Team (2.1.38 or later, when server-managed settings became available), and some machines run a version earlier than 2.1.260 while also holding a stored API key from an earlier /login or written directly to configuration. Anthropic says users on standard auto-update already have the fix; manual updaters should move to 2.1.260 or later." } }, { "@type": "Question", "name": "What exactly went wrong?", "acceptedAnswer": { "@type": "Answer", "text": "Claude Code chose a stored API key ahead of the user's valid Enterprise or Team sign-in when fetching the organization's server-managed settings, even though the session itself authenticated with the organization account. When the settings endpoint rejected the key, the session started without the server-managed policy, or kept applying a previously cached copy and stopped receiving later changes. The advisory classifies it as CWE-696, incorrect behavior order." } }, { "@type": "Question", "name": "Why is it rated Low if it removes the whole policy?", "acceptedAnswer": { "@type": "Answer", "text": "Triggering it required local access to a device that held such a stored API key, and the no-policy case also required that no managed settings had been cached on the machine before. The CVSS 4.0 vector reflects local access, low privileges and low integrity impact. The practical risk for security teams is less about attackers and more about assurance: you could not tell from the admin console that a given session ran without your rules." } }, { "@type": "Question", "name": "Were MDM or file-based managed settings affected?", "acceptedAnswer": { "@type": "Answer", "text": "No. The advisory says endpoint-managed settings delivered by MDM or a managed settings file were not affected. Only server-managed settings fetched at session start were. That is a useful design input: rules you cannot afford to lose can be delivered by both channels." } }, { "@type": "Question", "name": "What changed in Claude Code 2.1.285 to 2.1.289?", "acceptedAnswer": { "@type": "Answer", "text": "The changelog for those five releases lists fixes including: PowerShell permission checks skipping deny and ask rules when the command parser failed to start (2.1.285); organization per-tool permission ceilings dropped for an MCP tool named __proto__ (2.1.287); PreToolUse and PermissionRequest hooks being skipped when matching failed or tool input could not be serialized, now blocked instead (2.1.288); a dangerous rm inside bash -c running without a prompt in bypassPermissions mode or under a shell allow rule (2.1.288); and Bash deny rules missing commands behind an environment-variable prefix under sandbox auto-allow (2.1.289). None of these has a CVE." } }, { "@type": "Question", "name": "Which Claude Code version should we pin?", "acceptedAnswer": { "@type": "Answer", "text": "At minimum 2.1.260 for CVE-2026-103012. For the permission fixes, 2.1.289 was the latest release on October 5, 2026, while the npm stable tag pointed to 2.1.285. Machines that install the stable tag are fixed for CVE-2026-103012 but do not yet have the 2.1.287 to 2.1.289 fixes. Decide deliberately which channel your fleet tracks, and check the version that actually runs on each endpoint." } }, { "@type": "Question", "name": "How does Anomity help with this?", "acceptedAnswer": { "@type": "Answer", "text": "The Anomity Endpoint Sensor inventories Claude Code and other agents on every managed endpoint with their versions, hooks and configured MCP servers, plus secrets such as stored API keys with values redacted on the endpoint. That answers which machines run a version below 2.1.260, which also hold a stored key, and which run builds older than 2.1.289. At the Claude Code PreToolUse hook, Anomity returns allow, deny or log before a tool call runs, and decisions land in a 90-day audit trail that routes to SIEM, Slack, email or Jira, so you have a record of what policy actually did." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Claude Code Managed Settings Skipped by a Stored API Key - CVE-2026-103012", "item": "https://anomity.ai/blog/claude-code-managed-settings-bypass-cve-2026-103012/" } ] } ```