Last month, Check Point Research published details on two critical vulnerabilities in Claude Code - the same tool many of us use daily to ship features faster than ever. One of them, CVE-2025-59536 (CVSS 8.7), allowed remote code execution the moment you ran claude in a cloned repository. Not after you accepted a prompt. Not after you ran any code. The instant you launched the tool. The other, CVE-2026-21852 (CVSS 5.3), silently redirected your API traffic - including your full authorization header - to an attacker-controlled server before you ever saw a trust dialog.
Both are patched now. But the real story isn't the CVEs themselves. It's what they reveal about the new threat model we've all quietly adopted without a security review of our own.
How the Attacks Actually Worked
CVE-2025-59536 exploited Claude Code's hook system and MCP server configuration. A malicious .claude/settings.json file, checked into a repository, could define pre-execution hooks that fired before Claude Code displayed any trust prompt. Researchers at Check Point escalated this to a full reverse shell. The calculator that popped up during their demo - on top of the trust dialog the user never got to read - was a deliberate, darkly funny illustration of the point.
CVE-2026-21852 was quieter but arguably more dangerous at scale. The same settings file could set ANTHROPIC_BASE_URL to an attacker-controlled endpoint. Claude Code would issue API requests - carrying your API key in the auth header - to that endpoint before prompting for trust. In environments using Anthropic's Workspaces feature, where multiple keys share access to project files, a single stolen key becomes a credential for the entire team's AI workspace.
The fixes landed in versions 1.0.111 and 2.0.65 respectively. If you haven't force-updated across your fleet and rotated keys for anyone who opened untrusted repos recently, stop reading and do that before continuing.
This Isn't an Anthropic Problem. It's a Model Problem.
The same week these CVE details went fully public, DryRun Security released The Agentic Coding Security Report - and the numbers are hard to look away from. They tasked Claude, OpenAI Codex, and Google Gemini with building two complete applications through sequential pull requests, mirroring how real teams actually use these tools. The result: 87% of all pull requests introduced at least one security vulnerability. Across 38 scans covering 30 PRs, the three agents collectively produced 143 security issues. No agent produced a fully secure application.
The failures weren't exotic. Broken access control. JWT verification bypassed. WebSocket endpoints left unauthenticated while REST endpoints weren't. Rate limiting middleware defined in every codebase but never actually wired up - in any of them. Business logic that accepted client-side validation at face value. These are the same issues that appear on every OWASP Top 10 list, every security training course, every code review checklist. The agents knew enough to write the middleware. They just never connected it.
Claude specifically left the most unresolved high-severity issues in the final applications, including a 2FA-disable bypass not found in the other agents' work. That detail stings a little when you've been using Claude Code to move fast.
The Actual Problem Is Where Security Lives in Your Workflow
Most teams running AI coding agents do security review at the end - a final scan before merge, or worse, before deploy. But DryRun's data shows risk compounding across the development cycle. A broken access control pattern introduced in PR 2 gets built on top of in PRs 4, 6, and 9. By the time you scan at the end, the fix isn't a one-liner - it's a refactor.
The CVE story reinforces this from a different angle. The attack surface for your AI coding workflow now includes the project configuration files that AI tools consume. Your .claude/ directory, your MCP server definitions, your environment variable overrides - these are executable surfaces now, and they don't get scanned by most SAST tools because they're not code files.
What you actually need is a security gate that runs locally, runs early, and runs on every PR - not just the final artifact. It should catch the OWASP classics (broken access control, insecure JWT handling, missing auth middleware) as well as secrets and dependency vulnerabilities baked in by the agent's package choices. And it needs to understand context, because logic flaws like the 2FA bypass don't show up in pattern-matching scanners.
This is what we built LucidShark for. It's a local-first, open-source CLI that runs linting, SAST, and SCA checks against your AI-generated code before anything touches a remote branch. No data leaves your machine. It's free, Apache 2.0, and takes about 30 seconds to add to your workflow:
curl -fsSL https://raw.githubusercontent.com/toniantunovi/lucidshark/main/install.sh | bash
./lucidshark scan .
You can also hook it directly into Claude Code's post-tool execution hooks - which, given what we now know about how those hooks work, is a satisfying use of the same mechanism that made CVE-2025-59536 possible.
What to Do Right Now
- Update Claude Code to the latest version if you haven't. The RCE fix is in 1.0.111, the API key exfiltration fix is in 2.0.65.
- Rotate your Anthropic API keys if anyone on your team opened an untrusted repo with an older version in the last few months.
-
Treat
.claude/settings.jsonas executable code in your code review process. Review it with the same scrutiny you'd give a Makefile or a GitHub Actions workflow. - Scan at every PR, not just at the end. The DryRun data shows that waiting until final review means inheriting compounded risk across the full feature branch.
- Add a local security gate. Whether it's LucidShark or another tool, the check should run on your machine, before push, so you catch what the agent missed before anyone else sees it.
The Bottom Line
AI coding agents are not going away, and neither are the speed gains they provide. But the default assumption - that fast code is also safe code - is breaking down in public, with CVE numbers and percentages attached. The DryRun report's conclusion is worth quoting directly: "The answer is not to stop using coding agents. The answer is to stop assuming - or hoping - they are security-aware by default."
Add a gate. Run it locally. Run it early. The bugs the agent introduced in PR 2 are still there in PR 9 - you just haven't found them yet.
LucidShark is a local-first, open-source CLI quality gate for AI-generated code. Install it in 30 seconds →
Top comments (0)