Your dependency scanner reads package.json. The 4 August attack sat next to it, in the config folder.

What happened on 4 August

The Wiz analysis of the incident dates the start to 09:00 UTC on 4 August 2026. More than 400 npm packages were affected, meaning building blocks that developers install into their own software. Among them keyv at version 6.0.0, @cacheable/utils 2.5.1, cache-manager 7.2.10 and cacheable-request 13.0.20.

The way in was unspectacular and all the more serious for it: a compromised GitHub account of the package maintainer. That has been the standard route for years. What helps against it is what has helped for years: hardware keys for sign-in, protected main branches in the repository and publishing from a traceable pipeline rather than from a laptop.

The sequence is the interesting part. According to the analysis, files that keep the malicious code on the machine were added to the repository first. New package versions were published shortly afterwards. The goal was therefore not only to distribute malicious code. The goal was to stay on developer machines even after the affected package version is pulled.

The location of those files is the point here: Claude Code hook configuration and the VS Code tasks.json. Specifically, setup.mjs files sat in the .claude and .vscode folders.

Why these files execute commands

Configuration sounds harmless. In developer tooling it stopped being harmless a long time ago.

A tasks.json describes tasks the development environment executes. A hook is a command that an AI agent starts automatically at a certain point, for example before it changes a file. Both are built to execute commands. Both run with the rights of whoever opened the project. Which means with access to their cloud credentials, their keys and their repositories.

The difference from a postinstall script in an npm package is attention. postinstall has been discussed for years, there are switches against it, scanners check for it, security teams know it. Almost nobody thinks about the contents of a .vscode folder in a cloned repository. Many teams are thinking about a .claude folder for the first time since it started existing.

The target list of the malicious code confirms the intent. According to the analysis it went after cloud credentials, infrastructure secrets, developer credentials, AI-related configuration files and cryptocurrency wallets, plus access to build pipelines and Kubernetes configurations. Explicitly named are the credential stores of Claude, OpenAI, Codex, Cursor and Gemini.

That is notable because an API key for a language model is by now a credential like any other. It costs money, it carries rights and it appears in no classical access management system.

The structural point

Over the past two years a new kind of file has moved into repositories. It has three properties at once and that combination is new.

It executes commands. Hooks, tasks and agent rules are instructions, not just settings.

It is distributed. It sits in the repository and travels with every clone, every fork and every pull request.

It is not reviewed. Not by tools, because scanners do not know it. Not by people, because a change to a configuration file looks like noise in a review.

Code has all three properties too. For code, however, a mature apparatus exists: reviews, tests, signatures, scanners, release gates. For agent configuration almost none of that exists, even though it runs with the same permissions.

Our report on licence and governance risk looks at the procurement side of this problem, at who decides about a critical component. The 4 August incident shows the operational side of the same question. Knowing which packages you use is not enough. You also have to know which executable instructions arrive with them.

What to do concretely

The good news: the countermeasures are technically simple. The less good news: they require a decision many teams have not taken yet.

Immediately, if affected. Search the lock files and the built artefacts for the named package versions, not just package.json. A lock file records which version of each building block was actually installed. On a hit, the usual procedure for compromised development environments applies: rotate credentials, including the ones you do not think of first, meaning model API keys, registry tokens and personal access tokens.

Bring configuration folders into review. .vscode, .claude and the counterparts from other tools belong in review like source code. A change there is a change to what runs on the machine.

Check whether your scanners read those paths at all. For most tools the current answer is no. That is not a criticism of the tools but information you need before relying on them.

Separate what makes no sense together. A development machine holding production cloud credentials is a decision, not a law of nature. Short-lived sessions instead of long-lived keys make a successful compromise worth much less.

Publish from a pipeline, not from a laptop. This works against the way in rather than against staying. But it is the measure with the best effect per unit of effort and it works against the whole class of such attacks.

The part nobody enjoys discussing

It is tempting to turn this incident into an argument against AI-assisted development. That would be convenient and wrong.

The attack did not work because a model did something wrong. It worked because a tool reads executable configuration from a repository that came off the internet. And because nobody reviews those files. Editors and build systems had the same weakness long before agents existed. What is new is only that more such files are in circulation and that they sit in repositories cloned every day.

Our evidence review on AI-assisted software delivery arrives at a related observation elsewhere: the bottleneck moves from writing to reviewing. This incident shows the same shift on the security side. More executable content is produced and it has to pass the same number of eyes. Some of it does not look like code.

The honest consequence is uncomfortable for everyone involved. If agent configuration runs with the same permissions as code, it has to take the same path through review as code. That costs attention. And attention is exactly the scarcest resource in these teams right now.

Why this was not the last incident of its kind

The attack surface grows because the number of configuration formats that execute commands grows. Every new tool brings its own. Each of them sits in the repository. None of them has an established review path.

If you want to prepare, do not wait for detection patterns matching one specific attack. Set a rule that holds independently of the tool: any file that can cause a command to run on a development machine is code and is treated as code. That rule is inconvenient because it captures files previously waved through. Its advantage is that it also covers the tool that arrives next year.

What you can check this week

Open any repository of your team and look for folders such as .vscode, .claude or similar. Ask who changed them last and whether anyone looked at that change. Ask your security team or your service provider whether the dependency scanner reads those folders. And look at which credentials sit permanently on the development machines. The answers to these three questions say more about your situation than any list of affected package versions.

How to arrange credentials, access and release paths so a compromised development machine does not immediately mean production is described on our security and hardening page. The 4 August incident invented nothing. It merely tested an assumption many teams held without ever stating it.