Posts

Showing posts from April 5, 2026

The Claude Code Leak

The Claude Code Leak: When .npmignore Breaks Your IP Strategy A source map, 512K lines of exposed TypeScript, an AI-powered clean-room rewrite in hours, and a copyright paradox that could reshape software IP forever. April 2026  |  Elusive Thoughts  |  AppSec & AI Security What Happened On March 31, 2026, Anthropic shipped Claude Code version 2.1.88 to npm. Bundled inside was a 59.8MB .map source map file — a debugging artifact that reconstructs original source code from minified production builds. This single file exposed 512,000 lines of unobfuscated TypeScript across roughly 1,900 files. The entire agent harness architecture of what is arguably the most sophisticated AI coding tool on the market was now public. This was not a sophisticated attack. No zero-day. No insider threat. A missing .npmignore entry, a known Bun bug (#28001 filed on March 11 and still open at the time of the leak), and nobody on the release team catching it. Bun g...

How CLI Automation Becomes an Exploitation Surface

How CLI Automation Becomes an Exploitation Surface Securing Skill Templates Against Malicious Inputs There’s a familiar lie in engineering: it’s just a wrapper . Just a thin layer over a shell command. Just a convenience script. Just a little skill template that saves time. That lie ages badly. The moment a CLI tool starts accepting dynamic input from prompts, templates, files, issue text, documentation, emails, or model-generated content, it stops being “just a wrapper” and becomes an exploitation surface. Same shell. Same filesystem. Same credentials. New attack path. This is where teams get sloppy. They see automation and assume efficiency. Attackers see trust transitivity and start sharpening knives. The Real Problem Isn’t the CLI The shell is not new. Unsafe composition is. Most modern automation stacks don’t fail because Bash suddenly became more dangerous. They fail because developers bolt natural language, templates, or tool-chaining onto CLIs without rethinking ...

When LLMs Get a Shell: The Security Reality of Giving Models CLI Access

When LLMs Get a Shell: The Security Reality of Giving Models CLI Access Giving an LLM access to a CLI feels like the obvious next step. Chat is cute. Tool use is useful. But once a model can run shell commands, read files, edit code, inspect processes, hit internal services, and chain those actions autonomously, you are no longer dealing with a glorified autocomplete. You are operating a semi-autonomous insider with a terminal. That changes everything. The industry keeps framing CLI-enabled agents as a productivity story: faster debugging, automated refactors, ops assistance, incident response acceleration, hands-free DevEx. All true. It is also a direct expansion of the blast radius. The shell is not “just another tool.” It is the universal adapter for your environment. If the model can reach the CLI, it can often reach everything else. The Security Model Changes the Moment the Shell Appears A plain LLM can generate dangerous text. A CLI-enabled LLM can turn dangerous text i...