Your Dependency Scanner Reads package.json. The 4 August Attack Sat Next to It, in Your Editor's Config Folder.
On 4 August 2026, more than 400 npm packages were compromised. The technically notable part is not the way in, which has been known for years, but the way to stay: persistence through configuration files of AI agents and development environments, files no dependency scanner opens.
Fabian Weiss Key Takeaways
- From 09:00 UTC on 4 August 2026, according to Wiz, more than 400 npm packages were compromised, including keyv 6.0.0, cache-manager 7.2.10 and cacheable-request 13.0.20.
- Entry ran through a compromised GitHub maintainer account. Persistence payloads were introduced into the repository before the package versions were published.
- Persistence used Claude Code hook configuration and VS Code tasks.json, files that dependency scanners do not read.
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, including 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 maintainer account. That has been the standard route for years, and what helps against it is what has helped for years, namely hardware keys, protected branches and publishing from a traceable pipeline rather than from a laptop.
The sequence is the interesting part. According to the analysis, persistence payloads were introduced into the repository first, and new package versions published shortly afterwards. The goal was therefore not only to distribute malicious code but to remain on developer machines even after the affected package version is pulled.
And the location of that persistence is the point here: Claude Code hook configuration and VS Code tasks.json, specifically setup.mjs files in the .claude and .vscode directories.
A dependency scanner reads your project's manifest and lock files. It does not read the configuration folders of your editor and your agent. That is exactly where the persistence sat. This is not a gap in a product but a gap in the model of what counts as part of the project.
Why these files are an execution surface
Configuration sounds harmless. In developer tooling it stopped being harmless a long time ago.
A tasks.json describes tasks the development environment executes. An agent’s hook configuration describes commands that run at specific points. Both are executable by design, and both run with the rights of whoever opened the project. Which means with access to their cloud credentials, their keys, 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, and many teams are thinking about a .claude folder for the first time since it started existing.
The payload’s target list confirms the intent. According to the analysis it went after cloud credentials, infrastructure secrets, developer credentials, AI-related configuration files and cryptocurrency wallets, plus CI/CD environments and Kubernetes configurations. Explicitly named are the credential stores for Claude, OpenAI, Codex, Cursor and Gemini.
That is notable, because a model API key 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 category of file has moved into repositories, one with three properties at once, and that combination is new.
It is executable. 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, and not by people, because a change to a configuration file looks like noise in a review diff.
Code has all three properties too, but for code 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 is that the countermeasures are technically simple. The less good news is that they require a decision many teams have not taken yet.
Immediately, if affected. Search lock files and build artefacts for the named package versions, not just package.json. 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 equivalents from other tools belong in review like source code. A change there is a change to executable behaviour.
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 substantially reduce the value of a successful compromise.
Publish from a pipeline, not from a laptop. This addresses the way in rather than the persistence, but it is the measure with the best effect per unit of effort and it works against the whole class.
It is not an assessment of whether you were affected, and not a complete response procedure for a specific incident. For establishing exposure, the indicators published by vendors and security providers are authoritative, not an article. What is here is the structural consequence, which holds even if you were not affected this time.
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, it has to pass the same number of eyes, and 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 executable configuration formats grows. Every new tool brings its own, each of them sits in the repository, and none of them has an established review path.
If you want to prepare, do not wait for signatures matching one specific pattern. 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.
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.
Research for technical decisions
New reports, benchmarks and technical analyses on SaaS economics, AI engineering and owned infrastructure.
Original research Public sources No sales mail
By subscribing you receive new analyses and updates from FW Delta by email. You can withdraw your consent at any time. Further information is available in the privacy policy.