Claude Code Vulnerabilities: Deep Dive, Exploitation Paths and Proactive Defense

These are real vulnerabilities of Claude Code that have been disclosed and not hypothetical risks as a result of Claude Code's agentic execution model, shell access, file writes, and autonomous tool use. Within a span of just a year, all of these CVEs have been discovered, as has a half-million-line source code leak and a live proof-of-concept (Poc) for a reverse shell. Every known exploitation path and the defenses that deal with them: the trust-dialog bypass that shipped remote code execution, the project-load that leaked API keys, the npm packaging error that showed Claude Code's internals, and the runtime controls that deal with what static review does not.

Understanding Claude Code and Its Agentic AI Architecture

Understanding the operation of the tool is helpful in evaluating Claude Code's attack surface. The flexibility that Claude Code architecture provides the model over a standard chat assistant is the reason for the failure modes outlined in this article: 1. It can read, 2. it can write, and 3. it can execute.

How Claude Code Executes and Automates Developer Tasks

Anthropic Claude Code is an agentic coding tool designed to be used as a terminal program. The developer then provides it a command in natural language, and Claude Code handles all subsequent tasks, such as editing files, running shell commands, managing git operations, running build and test pipelines, and connecting to external services via Model Context Protocol (MCP) servers. What sets Claude Code & Anthropic apart from the “code completion”-style coding assistants is their focus on natural language. The uniqueness of Claude Code & Anthropic is its emphasis on natural language. The model doesn't only suggest a diff for a human to apply; it can open a terminal, run the command, read the output, and then determine what to do next, in dozens of steps without a human having to review each step.

Security Implications of Agentic AI in Development

That's autonomy, and that's what's dangerous. Such a tool that has shell access, file system access, and network access but works on content it did not write (READMEs, error messages, dependency manifests, issue threads) has a much greater attack surface than a code-suggestion tool. Each Claude Code permission decision (what to trust, what to run, what to send over the network) occurs in one reasoning loop, which can be impacted by anything the agent reads. This is the architectural cause of the Claude Code security problems reported below: The very design that makes the tool usable is what hackers attack.

Recent Claude Code Vulnerabilities: Technical Analysis

So far, the Claude Code CVE record is brief, but grim. Both of the vulnerabilities being disclosed are discovered by Check Point Research and are the two areas that an attacker covets from a developer's machine: code execution and credentials.

CVE-2025-59536: Code Injection via Untrusted Directory Initialization

CVE-2025-59536 (CVSS 8.7) is a startup trust dialog code injection bug that should prompt for permission before Claude Code executes something in a new directory. Since that implementation, a bug has existed that allowed project code to run before the user had confirmed the dialog. In reality, Claude Code remote code execution (RCE) could be achieved by just launching the tool inside a copied or downloaded repository, which had already been provided with a malicious project file, without having to do anything else further than opening it. In October 2025, the patch for the flaw was released as version 1.0.111, and all users who were set to auto-update got it.

CVE-2026-21852: API Key Exfiltration via Project-Load Flow

CVE-2026-21852 (CVSS 5.3) is not in the start-up dialog, but in the project-load flow. A rogue repository might have a settings file that changes the ANTHROPIC_BASE_URL, directing Claude Code’s API calls to the attacker's server. This redirection could occur before the user views or confirms anything, allowing for a way for the Anthropic API key to be exposed: a Claude Code attack would occur when the attacker's endpoint captured the key without the user seeing it. The issue has been addressed in 2.0.65 (January 2026). Teams exposed during the vulnerable period should consider any key used on an exposed version to be compromised and replace the key; a compromised key could expose a team's Anthropic Workspace-scoped resources as well.

The March 2026 Source Map Leak and Its Downstream Impact

Anthropic was carelessly releasing Claude Code's source code to the public npm registry on March 31, 2026. The reason was simple: the @anthropic-ai/claude-code 2.1.88 package version included a 59.8 MB JavaScript source map, a 1,906-file, 513,300-line unobfuscated TypeScript source file. It was found by a security researcher within hours of publication, and a direct download link was posted, while the code was mirrored on GitHub and forked tens of thousands of times before Anthropic pulled the package. The incident was not a data breach, but a packaging error, said Anthropic, adding that no data or user credentials were exposed. The threat was more real than the leak itself: within days, threat actors were distributing fake "leaked Claude Code" repositories along with the infostealer malware; they were hoping that interested developers would run an unofficial build without paying attention to the other software included in the package. The Claude Code source code leak serves as a case study in how risk in the AI coding supply chain is a two-way street: between the tool and your environment, and between the tool's build pipeline and the public.

Supply Chain and Dependency Risks in Claude Code

In addition to the two CVEs and the source leak, ordinary supply chain risk comes into Claude Code, as does an agent-specific twist: The access to the Claude Code repository means that the tool regularly downloads and executes code, configuration, and documentation from third parties it has no relation with. A developer skimming a repository will likely see the hook, MCP server definitions, and environment variable references as nothing more than configuration, but they are all executable. But, given the abuse of these mechanisms, the only posture you can take is treating everything you cloned, and anything it included, as untrusted until you have been proven otherwise.

How Attackers Exploit Claude Code: Real-World Scenarios

Knowing the CVEs is just half the battle. A successful Claude Code attack doesn't use a single vulnerability; it's just a sequence of normal agent actions, normal error handling, and content the agent takes for granted that it's safe.

Prompt Injection and Tool Call Manipulation

The majority of the scenarios below involve undesirable direct prompt injection. Most of the scenarios below are examples of undesirable direct prompt injection. It does not embed instructions in the content that the agent processes; instead, it's embedded in a README, code comment, error message, etc., not in what the user has typed. The importance of Claude Code prompt injection is that once the content is in context, the agent will be unable to reliably distinguish between “information to reason about” and “instructions to follow”. OWASP recently lists prompt injection as the top vulnerability class for LLM applications, and in March 2026, researchers reported the first major, large-scale, indirect prompt injection attacks in the wild. The consequence of an agentic coding tool is not a nutter of an answer from a chatbot; it's a tool that the agent was directed to make that has real filesystem and network privileges.

Case Study: The Indirect Injection Reverse-Shell PoC (June 2026)

In June 2026, researchers from Mozilla's Zero Day Investigative Network (0DIN) released a proof of concept that a completely clean-looking GitHub repository (with no malicious code anywhere in it) can compromise a developer's machine. The chain went like this: The chain was a package designed to fail with a seemingly innocuous error, and the notes in the repository told the agent how to “fix” that error by executing an initialization script that was controlled by the attacker and that fed the output of a DNS TXT record directly to bash. The payload was never present in the repository; thus, not even a static scanner, a code reviewer, or even the agent itself would have seen it before it ran. The outcome was a completely interactive reverse shell running in the developer's own privileges, and with access to any secrets that they had in the environment they were running in: ANTHROPIC_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN. Prompt injection Claude Code attacks are not ones that require the agent to "decide" on something bad; the agent decided to correct an error, and after that, each step was 2-3 inferences away from what the agent actually evaluated.

Silent Command Execution and Consent Bypass

CVE-2025-59536 revealed the possibility of bypassing the trust dialog, but the bigger picture was that of consent bypass through configuration. In Check Point's studies on the two disclosed CVEs, it was determined that any user action short of opening a project could lead to shell command execution and credential exfiltration via hooks, MCP server definitions, and environment variables. The issue here is that many configuration files in the repository are treated as executable instructions by Claude Code, but not by most developers. Closing that gap requires as much care with auditing configuration files as you do with application code—don't just assume that a JSON or YAML file is safe to open.

"YOLO Mode" and the Risk of Unreviewed Auto-Execution

Claude Code also has a flag that is known as YOLO mode or --dangerously-skip-permissions, which will skip all permission prompts, allowing the agent to execute file edits, shell commands, and MCP tool calls end to end without asking for permission. It has a valid purpose - because it interrupts long repetitive tasks. All but one of the attack paths listed above, however, is now neutralized when the one checkpoint is combined with any of the above, and with dependencies that aren't familiar, instructions that get inserted, and the configuration that's malformed, YOLO mode takes away the last barrier to the action running. But Anthropic says the flag should be used only inside an isolated container or VM, and the middle ground of an allowlist of allowed tools plus Anthropic's built-in Auto mode exists just because auto-execution and untrusted content are a recipe for peril.

Limitations of Traditional Mitigation Approaches

None of the above incidents were picked up by linter. It's not by accident, and it helps to explain why static analysis is different when it comes to AI agents than it is to regular applications.

Why Static Analysis and Manual Review Fall Short

Static analysis tools rely on rules – they compare code to a pattern – this works well for detecting obvious injection sinks, deprecated function calls, or hardcoded secrets. Each of these three CVE-2025 exploits—the CVE-2025.59536 key exfiltration path, the CVE-2026.21852 reverse-shell, and the 0DIN reverse-shell chain—had something in common: They were not even present as code within the repository being scanned. If someone had manually checked the 0DIN repository, there would be no reason to mark anything as wrong, as there wasn't - it was downloaded at runtime from a DNS record. These are the sorts of problems that pattern-matching tools simply do not detect, from the scanner or the human who is skimming a diff file.

The Need for Runtime and Behavioral Security

If the vulnerability only shows up when the agent operates, the only way to detect the vulnerability is at the time of operation, not before. That implies not just a single-time review of the code it was handed, but monitoring what tools an agent calls, what it sends across the network, and what it runs, in production as well as in CI. It's the basis of modern-day application security for GenAI — static review will still be relevant to the code that Claude Code is writing, but it won't tell you anything about the actions that Claude Code is performing when it's writing it.

Proactive Security Testing and Runtime Protection for Claude Code

Getting Claude Code deployments past the initial check – and into runtime-aware testing that aligns with how the agent will actually be used when it has access to tools – demands a change in the way you approach testing.

Continuous Discovery and Red Teaming of Agentic Workflows

There are no guarantees of what you don't inventory. Many organizations don't realize that there are numerous AI agents, MCP servers, and LLM-powered tools already deployed throughout their employee laptops and CI pipelines, likely without security's awareness. That's where AI agent vulnerability testing should begin: Automatically identify all the agents, MCP tools, and LLM integrations in the environment and then test them continuously over time, not just during rollout. Akto's platform does this natively in agentic environments, finding AI agents and MCP tools across infrastructure, cloud, and employee devices, and deploying thousands of adversarial probes within injection, privilege escalation, data leakage, and misuse of tools, with the results validated in CI/CD, not as a single audit.

Real-Time Detection and Blocking of Prompt Injection and Tool Abuse

Discovery and testing give you the location of a risk; runtime protection is what prevents an active exploit from causing damage, such as the 0DIN reverse-shell chain during its operation. It involves looking for behavioral indicators of an attack, unknown tool usage, outbound connections you don't expect, an agent with a task that is taking an action that is not in the instructions, etc., instead of waiting for a signature match. Akto's runtime layer's sole purpose is to observe real-time interactions between agents and tools, and to prevent agents from looping, making unauthorized tool calls, or using tools excessively or in abnormal ways — providing an interface to the teams that sits after the code is written but before the impact is felt.

What Anthropic's Own Tooling Does - and Doesn't - Cover

The problem has been addressed directly by Anthropic. It reduces security-related PR comments by 30 to 40 percent during its internal rollout, according to Anthropic, and has a free security-guidance plugin for Claude Code that reviews code changes at three points: at a time before the change, at the time of the change, and at a time after the change. It's a valuable initial enhancement; it's not a full answer, it's an answer on top of what Anthropic expects Claude Code to produce, and it's not what every MCP server and/or third-party agent and/or shadow AI tool a team might be running along with Claude Code. Typically, the Claude Code vendor-side plugin needs to be complemented by an independent tool for discovering and testing all end-user-facing surfaces in the environment, because a vendor-side plugin focused on a single tool's code review won't be able to see how things are going everywhere else in the organization's AI stack. Platforms such as Akto are designed to fill that void.

Operationalizing Defense: Best Practices for Securing Claude Code Deployments

Making the above risks into policy requires a Claude Code security checklist that engineering teams can (and do) follow, not a document on a wiki that no one reads.

Guardrails, Policy Enforcement, and Least Privilege

Tackle configuration choices that eliminate whole attack classes. If a code change affects the production or shared infrastructure, disable auto-commit or YOLO-style flags and require review before merging, no matter how the code was written. Instead of an allowlist, use a whitelist of tools for Claude Code; repository configuration files, hooks, and MCP server definitions are code that needs to be reviewed and cannot be avoided. Use CLAUDE.md or other configuration to explicitly add security restrictions to the queries, like enforcing parameterized queries, and let the agent's defaults benefit you. Automated scans should be run against forked or contributed repositories and need manual approval to run, as comments or documentation in the repository could be prompt injection, which is scanned when the agent runs the scan.

Continuous Monitoring and Incident Response

The blast radius is narrowed by least privilege, and monitoring is what will let you know when it did. This involves logging agent tool calls and outbound network activity in a way that would enable a comprehensive reconstruction of a session at a later stage, alerting to suspicious network events (such as outbound calls to an unknown site or DNS lookups for an unusual domain name), and having a clear process for rotating API keys as soon as a compromise is suspected, not after it is confirmed. This is indeed the practice with enterprise security programs that use the Claude Code: the plan for an agentic tool should assume that there will be some incursion attempts that will be successful, and then work on the detection and containment of those incursions in a timely fashion.

Coordinated Disclosure and Staying Current

Claude Code security updates are swift, and a policy implemented 6 months ago might be outdated. To keep up to date, one must have a means to report new discoveries and a means to differentiate between confirmed and contested discoveries.

Reporting Vulnerabilities to Claude Code

Anthropic employs a coordinated disclosure model for security researchers reporting problems with Claude Code, similar to its approach for vulnerability disclosure in all its products. The CVEs disclosed were all in this pattern: an external research team (in this case, Check Point Research) discovered and privately reported the vulnerability, Anthropic released a patch, and the details were released only after a patch was available. Security teams that are reviewing or using Claude Code should be aware of the channel and treat any new reported and unpatched vulnerability the same way a security team would treat any other developer product with shell access.

Separating Confirmed CVEs from Disputed Claims (the 2026 "Backdoor" Report)

Not all security assertions made about Claude Code are equal, and the July 2026 squabble with China's Ministry of Industry and Information Technology (MIIT) serves as a good example. Claude Code versions 2.1.91 to 2.1.196 had a “security back-door”, the National Vulnerability Database of China said, allowing them to send a user's location and ID-related information to a remote server without permission, and urged users to immediately remove or upgrade their versions. Anthropic said that the flagged code was part of an earlier anti-distillation experiment, designed to detect and prevent unauthorized attempts to extract its models' capabilities, not a stealthy data-collection tool to be used by anyone, and that in any case, entities that are majority-owned by China-based companies are already prohibited by usage policy. It was possible both that the code existed and that it acted as described, and both sides were in dispute as to its origin and intent. This report is not an independently verified, patched, and technically accepted vulnerability with other teams; the teams will follow it as a geopolitical/policy issue, not as an equivalent, verified, and technically accepted vulnerability.

Tracking New Threats and Security Updates

A static read of 'what is vulnerable in Claude Code' goes stale pretty quickly, as in less than a year since a trust-dialog bypass to a source code leak to a DNS-based reverse shell PoC. Look at Anthropic's official changelog and security announcements for any CVEs or fixes that are only for specific ranges of versions – some of the above are only applicable to a very limited range of versions. Rely on independent research, such as that conducted by Check Point and Unit 42, which has been responsible for most of the big releases to date, and on internal policy whenever a new technique is published, not on an annual cycle.

Securing Claude Code Starts With Visibility

The list of vulnerabilities that Claude Code has suffered to date (two CVEs, one major source leak, a live reverse-shell PoC) has a pattern: it did what it was designed to do and that design allowed an attacker to exploit it. None of them ever fill that gap completely since next time they will chain regular agent behavior in the same fashion as the previous patch. With AI agents, MCP servers, and LLM-powered tools like Claude Code, it is time to break out of that cycle with Akto: uncover all agents and MCP integrations running across your environment, continuously red-team their workflows, and prevent abuse in real-time, not after the fact. If you are already using Claude Code or other agentic tools in your engineering workflow, schedule a AI Security demo to learn how Akto ensures these technologies are available in production.

FAQs: Claude Code Vulnerabilities

1. What are the main known vulnerabilities in Claude Code?

The two most important of the disclosed vulnerabilities are arbitrary shell command execution when Claude Code is launched in an untrusted directory (CVE-2025-59536) and information disclosure via the project-load flow that may reveal a user's Anthropic API key (CVE-2026-21852).

2. How can opening a malicious repository compromise a developer's system?

Claude Code can make requests, such as those that expose the user's API key, even before a trust prompt is displayed, making it possible to open a crafted repository and trigger credential theft.

3. What is indirect prompt injection in the context of Claude Code?

Indirect prompt injection occurs when the agent's external content to which he is given access contains malicious instructions, such as a README file or an error message, which he reads and reasons about in the course of a normal task, and that cause him to execute commands controlled by the attacker, without him being aware of them in any way.

4. What happened with the Claude Code source code leak?

Anthropic accidentally published around 513,000 lines of unobfuscated Claude Code source code in a JavaScript source map included in a public npm package, mirrored to GitHub and forked thousands of times within hours, providing a much greater window of insight into the hook and permission logic of the tool.

5. What is "YOLO mode" and why is it a security risk?

YOLO means setups where Claude Code automatically approves actions such as commits without human oversight. If this is coupled with weak input validation or untrusted content, then human checks are lost, and the malicious or unintended action can run before someone is even aware of it.

6. Can traditional static analysis tools catch Claude Code's agentic risks?

Not reliably. Static analysis is usually rule-driven and will flag up common problems such as exposed passwords but would not detect more complex vulnerabilities, such as broken access control or business logic flaws that are created through the behavior of an agent during its runtime.

7. What mechanisms do attackers abuse to compromise Claude Code?

Configuration mechanisms such as hooks, Model Context Protocol (MCP) servers, and environment variables have been targeted by attackers to run arbitrary shell commands and steal API keys when developers clone and open untrusted repositories.

8. Has Anthropic released its own defenses for these risks?

Yes. During its internal testing, Anthropic has reported seeing a 30 to 40 percent reduction in security-related PR comments after implementing its free Claude Code Security plugin, which provides multi-stage review (instant checks, post-turn diff analysis, and deep pre-commit review).

9. What was the China MIIT "backdoor" claim about Claude Code?

In July 2026, the Ministry of Industry and Information Technology of China made a public warning that versions 2.1.91-2.1.196 of Claude Code included a security back-door that would allow for the transmission of sensitive data to a remote server without the user's consent. In response, Anthropic wrote that this was an earlier anti-distillation experiment, rather than a malicious backdoor.

10. How should teams reduce exposure to Claude Code vulnerabilities right now?

Turn off auto-commit ("YOLO") modes in production workflows; explicitly review changes before merging; only allow security-related changes in trusted repositories or by internal contributors; make explicit security constraints (e.g. parameterized queries) part of the configuration files (e.g. CLAUDE.md).

11. Should organizations block automated security scans on forked repositories?

Yes. An automated scan of a fork where an adversary has control over the fork's codebase should be subject to manual approval prior to running, since prompt injection can be included in code comments or documentation that Claude takes as part of the actual instructions to execute in a scan.

12. How can teams stay current on new Claude Code vulnerabilities?

Keep an eye on Anthropic's official Security Advisories and changelog for security patches for CVEs, refer to independent security research (Check Point, Unit 42, etc.) for new exploit techniques, and closely follow version-specific advisories as some patches have been linked to very specific version ranges.