Microsoft's Second Credential Stealer Week in a Month: The Decision Tree Builders Should Run Before the Next AI-Driven Install

The Ars Technica headline landed this morning — for the second time in a matter of weeks, Microsoft-signed or Microsoft-adjacent packages have been caught carrying credential-stealer payloads. We will not relitigate the technical post-mortem here. What we will do is route you. Three questions, yes/no answers, then a recommendation table. The reason for the format is that the population of readers facing this news is heterogeneous — a solo dev on Cursor has a different exposure profile than a team running Codex agents against a CI pipeline, and the generic "rotate everything" advice is both wrong and expensive. Answer the three questions in order. Do not skip to the table.

Question 1: Does Your AI Coding Tool Have Package-Install Authority Without Your Approval?

This is the load-bearing question. The 2026 generation of AI coding tools split into two camps along this axis, and the split maps almost exactly onto your blast radius today.

The shape of the incident matters here. A credential-stealing package does not fire when it sits on disk. It fires when it is installed and its post-install or import hooks execute. So the question of who can pull a package into your environment without your eyes on the manifest line is the question of who can detonate it on your machine.

If Yes

You are running Codex in agent mode, Claude Code with auto-apply on, Gemini CLI in agentic flow, or Cursor Composer with shell-execute approved. All four of these — and the per-call pricing on the underlying models is part of the operational reality, so worth naming — can issue `dotnet add package`, `npm install`, or `pip install` commands as part of a multi-step plan and run them without surfacing the package name for your review.

Cost context matters because it shapes how people configure these tools. Claude Code runs on Claude 4.7 Opus at $15/$75 input/output per million tokens — the same pricing Anthropic held flat from Claude 4 Sonnet's earlier tier, which is the unusual data point and the reason Opus runs hot on agentic loops in our shop. Codex, released in April 2026 as OpenAI's #1 coding-tool ship, runs on GPT-5.5 at $5/$25. The cheaper per-token cost translates directly into longer autonomous chains before someone hits a budget alert and looks at what the agent has been doing. Longer chains mean more package installs you did not personally type.

If you are in this branch, do three things in order before your next agent run. Disable auto-shell-execute. Pin your project to a known-good `packages.lock.json` or `requirements.txt` with hashes. Set the registry to a private mirror that holds packages for a 72-hour quarantine before promoting them. The 72-hour window is not arbitrary — it is roughly the median time from initial public report to credential-stealer takedown across the last six analogous incidents we have logged.

If No

You are running Aider with explicit confirmation on every command, Continue in IDE-suggestion mode, or GitHub Copilot's classic completion mode. Your blast radius from this specific incident is materially smaller. The package only enters your environment if you typed the install command yourself. Move on to Question 2 — your exposure is now downstream, not upstream.

Question 2: Have You Run `dotnet restore`, `npm install`, `pip install`, or Equivalent in the Last Seventy-Two Hours?

The reason this question is second, not first, is that the answer to Question 1 changes who you are asking it about. If your agent has install authority, "have you run install" really means "has your agent run install" — and the answer is almost certainly yes, possibly multiple times, possibly from prompts you do not remember writing.

This is where the calendar shape of the incident matters. The two incidents in recent weeks have followed a similar publication-to-takedown rhythm: package goes up, sits on the registry for hours to days, gets flagged by a researcher, gets pulled. The exposure window is bounded but real. If you pulled dependencies during that window, you are not necessarily compromised — most installs of a flagged package do not result in actual credential exfiltration because the payload has specific triggers — but you are in the set that needs to verify.

If Yes

Pull your shell history. On macOS or Linux, `history | grep -E 'install|restore|add'` will get you most of it. For agents, check the tool's conversation log — Claude Code keeps these under `~/.claude/`, Codex under its session directory. Get the list of packages installed in the window. Cross-reference against the published indicators-of-compromise list from the security researchers who broke the story. If you cannot find an IOC list yet, the conservative move is to revoke and rotate any credential that was sitting in your environment during the window — cloud provider keys, API tokens, SSH keys, git credentials.

Here is the part most checklists skip. Credential stealers in this category typically target the developer's home-directory token cache, not the project repo. So your `.aws/credentials`, your `~/.config/gh/hosts.yml`, your `.npmrc` auth tokens, your `.netrc`, your browser keychain — these are the targets. Rotate them in that order of likely value to the attacker.

If No

You have a holding pattern, not a clear pass. The agent in your other terminal may have installed something you do not know about. Run the same shell-history grep, run it across all your active project directories, and only then route to Question 3.

Question 3: Do You Have a Pinned, Hashed, Mirrored Dependency Path for Your Production Code?

The first two questions are about your immediate exposure. This one is about whether the second incident in weeks should change your build infrastructure permanently.

The honest answer for most shops is that they do not have any of these three things — pinned versions, content hashes, or a private mirror. The reasons are usually the same. Pinning is annoying when you want to take patch updates automatically. Hashes are a friction point for AI coding agents that want to drop in a new dependency on the fly. Mirrors cost money and require a person to maintain.

If Yes

You are in the good-discipline branch. Your audit cost from this incident is bounded — you can diff your lockfile against the IOC list, and the diff is the answer. The work today is small. The work you did six months ago is what's saving you. The model-pricing context is relevant here too: Claude 4.6 Sonnet at $3/$15 and GPT-5.4 at the same $3/$15 are both cheap enough to run as a CI gate that lints lockfile diffs for anomalous package additions — most shops that have pinned dependencies also have one of these running as a guardrail, and the marginal cost is small enough that no one notices it on the bill.

If No

This is the branch where the second-incident-in-weeks pattern is doing the most work. One incident is an incident. Two in a row, from the same publisher ecosystem, is a category signal. The right read is not "patch this specific package" — it is "the package-supply-chain attack vector against Microsoft-ecosystem developers is now a regular event, and your build path needs to assume that some non-zero number of installs in any given month will pull a payload." Add a private NuGet mirror. Enforce lockfile commits in CI. Block direct registry pulls from production builds. The cost of doing this in calm weather is roughly one engineer-week. The cost of doing it during incident response, with a credential rotation happening in parallel, is roughly four.

If You Answered Everything

The combinatorics give eight branches. Here is the routing table. Each recommendation is a one-line action — the full reasoning is in the section above for that question.

A note on the table. The first row — the highest-discipline shop with the highest-authority agent — is not the safest combination. It is the combination most likely to find that the agent installed something during the window that the developer did not see. The agent's autonomy moves the install action out of the human's attention surface, and the discipline of pinning dependencies does not help if the agent is also the one updating the lockfile. This is the pattern we expect to see more of as agentic coding tool adoption deepens through the rest of 2026.

What Changes If a Third Incident Lands

The interesting question, sitting on this side of the news cycle, is whether the second incident is a coincidence or a regime. The honest answer is that we do not know yet. What we can say is that the AI coding tool landscape has shifted blast-radius profile faster than the supply-chain discipline of the average shop has caught up. Codex, Claude Code, Gemini CLI, and Cursor Composer all shipped or matured their autonomous-install capabilities inside the last eight months. The package-registry attack surface has been there forever. The combination is new. The second incident is the first data point that lets you start drawing the line.

If a third lands inside the next thirty days, the table above collapses into one row: stand up the mirror, pin the dependencies, disable agent shell-execute by default. We will write that piece if and when the third incident lands.

FAQ

Should I uninstall my AI coding tool over this?

No. The credential-stealer payloads land via the package registry, not via the AI tool itself. The tools are an amplification factor when they install packages without surfacing them for review — turning off auto-execute neutralizes the amplification without losing the tool. Claude Code, Codex, Gemini CLI, and Cursor all have a confirm-before-shell setting. Use it. The productivity hit is real but small.

Which credentials are highest priority to rotate if I think I was exposed?

In order: cloud-provider keys held in `~/.aws/credentials` or equivalent, GitHub personal access tokens, npm or NuGet auth tokens, SSH private keys without passphrases, then browser-stored credentials for any developer-facing SaaS. The reason for the order is that credential stealers in this category have historically targeted the developer's home directory first because the value-per-byte is highest there.

Does pinning my lockfile actually prevent this attack?

Pinning by version alone does not. Pinning with content hashes does, because a malicious update to an existing version number will hash-mismatch and fail the install. `package-lock.json` with integrity fields, `Pipfile.lock`, `poetry.lock`, and NuGet's `packages.lock.json` with `RestoreLockedMode` all support this. Pin to the hash, not just the semver.

Is this only a NuGet problem, or are npm and PyPI in the same blast radius?

The two recent incidents both involved Microsoft-ecosystem packages, which is why the headline reads that way. The pattern — laced post-install scripts targeting developer credentials — has been recurring on npm and PyPI for over two years. The Microsoft surface is newly hot. The other registries were never cold.

My agent installed something during the window. What is the first command I should run?

Pull the agent's session log and grep for install verbs. For Claude Code, that is `grep -E 'install|add|restore' ~/.claude/projects/*/messages.jsonl`. For Codex, check the session directory under your home. Get the package name list. Then cross-reference. The grep takes a minute. The cross-reference is what tells you whether to rotate.

Will the AI tool vendors do anything to prevent this?

None of the vendors named in this piece are positioned to prevent registry-side compromise — the packages are not theirs. What they can do is harden the install-without-confirmation path. We expect to see that ship in Q3, possibly sooner if a third incident lands. Until then, the configuration is in your hands.

How long is the typical exposure window for one of these packages?

Across the analogous incidents we have logged, the median time from upload to takedown sits at roughly seventy-two hours. The outliers are longer — the worst case we have on file ran nine days before takedown. If you installed during a wider window than three days, assume the IOC list is incomplete and verify against multiple researcher publications, not just the first one that broke the story.

What is the single highest-leverage change to make today?

For most shops in the no-mirror, no-pinning, agent-install-on branch — which is most shops — the highest-leverage change is to set agent shell-execute to confirm-before-run for any command containing the strings `install`, `restore`, or `add`. It is one config flag. It moves you from the worst row of the table to a substantially safer row immediately, while you plan the mirror.

Two incidents in weeks. The Ars Technica byline is on record. The receipts speak for themselves.