The Bitwarden CLI got backdoored last Wednesday. For 93 minutes, anyone who installed @bitwarden/cli@2026.4.0 from npm got a trojanized version that scraped secrets from their machine. Standard supply chain attack stuff — except for one detail that stopped me cold.
The payload specifically targets ~/.claude.json, MCP server configs, Cursor settings, and Kiro configs. This is the first npm compromise that treats AI coding tools as first-class exfiltration targets. Not cloud credentials and SSH keys. Your AI agent configs.
I checked my setup within the hour
I run Claude Code on two active SaaS projects. My MCP config connects to a Postgres database, a Stripe test environment, and a custom analytics API. That config file contains connection strings, API keys, and webhook secrets. Everything an attacker needs to impersonate my backend.
I wasn't hit. I don't use Bitwarden's CLI through npm. But "I wasn't hit" isn't the point. The point is I had no idea how much sensitive data was sitting in my AI tool configs until I actually looked.
Here's what I found in mine: a database connection string with credentials in the URL, two API keys with no expiration, and an MCP server config that exposed my Stripe test key. All in plaintext, all readable by any process running under my user account.
AI tool configs are the new .env files
A year ago, the sensitive stuff on a developer's machine was predictable: ~/.aws/credentials, ~/.ssh/, .env files, npm tokens. Security tooling knows to watch these. Secret scanners flag them. .gitignore templates cover them.
But AI tool configs slipped in under the radar. I've been building up my Claude Code setup for months, adding MCP servers, connecting data sources, storing preferences. Each addition felt small. I never once thought "this file is now a high-value target for attackers."
The Shai-Hulud campaign (that's what researchers are calling this family of attacks) figured it out before most of us did. They enumerated Claude Code, Cursor, Kiro, Codex CLI, and Aider configs alongside traditional secrets. Someone on that team understood that the average AI-assisted developer in 2026 has more exploitable data in their agent configs than in their .env files.
What I changed in three hours
First, I moved every secret out of my MCP config files. Connection strings now reference environment variables instead of inline credentials. My MCP servers read from a .env file that's chmod 600 and excluded from any sync or backup.
Second, I rotated every key that had been sitting in those configs. Two Stripe keys, a database password, and an API token for my analytics service. None of them had been compromised, but I couldn't prove that without checking npm install logs going back months. Rotating was faster than auditing.
Third, I set up a dead-simple cron job that checksums my Claude and MCP config files daily and alerts me if anything changes unexpectedly. Twelve lines of bash. If a supply chain attack modifies my configs to exfiltrate somewhere new, I'll know within 24 hours.
The whole exercise took about three hours. Most of that was figuring out which secrets were exposed and rotating them. The actual hardening was maybe 40 minutes.
The uncomfortable pattern
This is the second supply chain incident I've reacted to in a month. CanisterWorm hit CI/CD pipelines. Now Shai-Hulud is going after developer workstations, specifically the AI tooling we've wired into everything.
The pattern is clear: attackers are following the same adoption curve we are. We adopted AI coding tools. We connected them to our databases, APIs, and deployment pipelines. We stored credentials in their configs because that's how the getting-started guides told us to set them up. And now attackers are harvesting those configs.
If you're using Claude Code, Cursor, or any AI coding tool with MCP servers or external integrations, open your config files right now. Search for anything that looks like a credential. If you find connection strings, API keys, or tokens in plaintext, move them to environment variables today. Not next week.
The 93-minute window on the Bitwarden attack was short. The next one might not be.