AI coding tools are your new attack surface, and two live CVEs prove it

01 Why your dev tools are now a boundary

Claude Code is having what analysts call its ChatGPT moment. A January 2026 developer survey from UC San Diego and Cornell University ranks it beside GitHub Copilot and Cursor as one of the three most adopted AI platforms among professionals. The adoption story runs past engineering. At Epic, more than half of Claude Code usage comes from non-developer roles: product managers, analysts and operations staff. Microsoft, which sells the competing Copilot, has rolled Claude Code across its own engineering teams.

Read what those teams actually do with it and the security picture snaps into focus. They scrape LinkedIn profiles and competitor intelligence. They automate CRM updates and email campaigns. They build dashboards and data pipelines on the fly. They reach into payment processors, customer databases and cloud infrastructure. A tool with terminal access, file-system reach and command execution has become the everyday interface to sensitive business operations, and much of that use sits with staff who were never trained to judge whether a repository is safe to open.

02 The two flaws that open a shell

Check Point Research disclosed both vulnerabilities in February 2026 [ Check Point 2026 ] . They exploit the configuration mechanisms every modern AI coding tool relies on: hooks, Model Context Protocol servers and environment variables. Give the tool a project that carries hostile settings, and the settings run.

The high-severity flaw needs almost nothing from the victim. An attacker publishes a legitimate-looking repository with hostile Claude Code configuration inside it. A developer clones it. The developer starts the tool in that directory. Malicious hooks then execute arbitrary commands with the developer's full system privileges [ Dark Reading 2026 ] . No prompt is approved, no warning is dismissed. Opening the project is the whole exploit.

Check Point framed the second-order risk plainly. A single compromised developer account or insider can inject malicious configuration into company codebases and reach entire development teams, which makes it a supply chain attack. In a shared engineering organisation, one poisoned config file lives in version control and propagates to every developer who pulls the code. One compromised key becomes a gateway to broader exposure, and CVE-2026-21852 is built to lift exactly the keys, tokens and secrets that business teams leave sitting in project directories.

03 How far one poisoned config reaches

Claude Code is not a special case. The whole category of AI development tools opens attack surface that traditional security models never scoped. GitHub Copilot carried CVE-2025-53773 in 2025, a remote code execution reachable through prompt injection, exposing the machines of millions of developers who lean on it for code generation. Microsoft Copilot's EchoLeak flaw introduced a new class again: zero-click prompt injection. An attacker sent an email with hidden instructions, Copilot ingested it automatically, and the assistant pulled data out of OneDrive, SharePoint and Teams, exfiltrated over trusted Microsoft domains that slide past network controls.

Open-source agents raise the ceiling. OpenClaw, an AI agent with more than 135,000 GitHub stars, triggered the first major AI agent security crisis of 2026, with multiple critical vulnerabilities, hostile marketplace exploits and over 21,000 exposed instances left reachable on the internet. Prompt injection sits under most of these, and it is not a corner case. It affects roughly 73% of production AI applications [ OWASP LLM 2025 ] . OpenAI has said plainly that prompt injection is unlikely to ever be fully solved.

The blast radius is the honest measure here, the same as with any breach. Not how clever the entry was, but how far the access carried. The McKinsey Lilli breach makes the shape concrete: the firm ran the system in production for two years without detecting 22 unauthenticated endpoints [ The Hacker News 2026 ] . AI systems are being deployed faster than they are being secured, and AI coding tools are the sharpest version of that gap, because non-developer staff bring less caution to which repositories they trust and where they store a key.

04 Close the gap before it is used

None of this needs a large budget to close. It needs someone to treat the configuration as executable code and test it that way. Start by knowing what is in use. Inventory every AI development tool, who runs it, and with what permissions. Then audit the configs already sitting in your repositories: the .claude/ directories, the MCP server definitions, the hook files. Those are the doors the two CVEs walk through.

From there the controls map onto the risk. Restrict configuration changes to trusted contributors, because not every developer needs to alter how a tool behaves for the whole team. Put AI tool configs into code review the same as any other change to hooks, MCP servers or environment variables. Test the integrations as part of your security assessment, drawing on current attack methods from the OWASP Top 10 for LLMs and the NIST AI Risk Management Framework [ NIST AI RMF ] , rather than a static checklist. Monitor API key usage for the anomalous patterns that mark exfiltration. Then write the policy down: approved tools, configuration standards, and the trust rules for opening a repository. Once the findings are closed, RTP Robin lets your team re-run the same attacks as the tools and configs change, so the picture stays current between formal assessments.