Verified, Signed and Malicious

On 4 August 2026 a compromise of one of the most widely used packages in the JavaScript ecosystem took thirty-three minutes to go from a quiet commit to a published release built to harvest credentials. The detail that should concern boards is not the malware. It is that the two signals most organisations rely on to prove software integrity both returned green.

What happened

At 09:02 UTC, a commit landed in the keyv repository adding two files and one line to the package manifest. Keyv is a caching library pulled in transitively across the Node.js ecosystem, which is to say most organisations running it did not choose it and do not know they have it. The library code itself was untouched, which is precisely what kept the change small enough to skim past in review.

Two minutes later, a second commit planted five configuration files wiring the payload to run when a developer opens the project in an editor or starts an AI coding agent session inside it. Nineteen minutes after that, a test file that pointed directly at the new install script was quietly deleted. At approximately 09:35 the poisoned version was published to the registry under the default tag. Four minutes later, the payload was staged across all nineteen packages in the same workspace, ready for the next routine release.

The first community issue was filed at 09:49. Detection came from the ecosystem, not from the release pipeline.

Researchers disagree on the total footprint. One firm verified 353 poisoned versions across 79 package names and put the wider figure at 442 versions across 353 names. Another counted at least 868 packages across 1,381 versions. No complete public list existed at the reporting cutoff against which the larger totals could be checked, so they should be treated as reported rather than established. All of these figures count malicious artefacts, not victim systems. They establish scale, not impact.

Why this one is different

Most supply chain incidents have a single entry point: you installed the thing, so you are exposed. This one had two, and the second is the reason it deserves board attention.

Alongside the install script, the attacker committed an editor task configured to run on folder open and an AI coding agent hook configured to run at session start. The two files were cross-wired, each pointing at a script in the other’s directory, so reading either one in isolation never revealed a self-contained loop. The task was labelled “Environment Setup” to survive a glance.

The people most likely to open that repository were the ones doing their jobs properly: engineers who cloned it to read the source once the compromise went public.

Modern editors and coding agents do apply workspace trust prompts, so this is not unconditional execution in every environment. But a trust prompt is a control that depends entirely on an engineer declining a routine dialogue at speed, on a repository they cloned deliberately. That is a weak place to put your last line of defence.

The assurance signals that returned green

The poisoned release carried valid build provenance, because it passed through the project’s genuine automated release workflow. The attestation was accurate. It recorded where the artefact was built and by which pipeline. It could not, and was never designed to, establish that the source entering that pipeline deserved trust.

Likewise, the commit that planted the editor hooks displayed a valid platform signature, with its author field set to an automation account and a commit message reading “chore: update config”. Platforms sign commits created through their own interfaces, and the caller supplies the author name as free text. A write credential is therefore sufficient to produce a verified commit attributed to a bot.

Two controls that most organisations treat as proof of integrity were both technically correct and both operationally useless in this incident. That is the finding worth carrying into your next risk review.

Not an isolated technique

This is not a one-off. Researchers documented the same configuration-file execution technique, the same setup script filename and the same runtime download behaviour in a compromise of a Python machine learning package in April 2026, and have placed the August activity within an established malware family that has repeatedly targeted package registries this year.

The pattern is consistent and it is commercially significant: attackers have moved up the stack, from poisoning the artefact you download to poisoning the environment in which your engineers and your AI tooling work. Config files that execute commands are the new payload delivery mechanism, and almost no organisation currently governs them.

Where the exposure lands

Frame this as credential exposure rather than as a malware event, and the commercial picture becomes clear. Four exposures follow, in the order a UK board is likely to meet them.

Regulatory. Under NIS2 and DORA, supply chain and ICT third-party risk management are explicit, auditable obligations with board-level accountability. “We consumed a poisoned dependency and could not evidence which builds ran it” is not a defensible position in front of a supervisor. UK organisations in scope through European operations or customers carry the same exposure, and the Cyber Security and Resilience Bill will extend comparable duties to a wider UK population.

Contractual. Enterprise customers increasingly require software bill of materials evidence and defined incident notification windows. An inability to answer “did this run in your pipeline, and when” converts a technical incident into a commercial one within days.

Financial. The expensive part of this class of incident is rarely the removal. It is the credential rotation programme, the forced pause on releases while the pipeline is cleaned, and the customer assurance exercise that follows.

Governance. Repository configuration files that execute commands are a new category of executable asset. Most change control processes do not treat them as code. That gap is now an audit finding waiting to be written.

What leaders should do now

Three points bear emphasis. First, search resolved lockfile versions, not declared ranges: registry tags changed hour by hour during the incident, so a cached list of current tags is misleading in both directions. Second, revoke publishing credentials and freeze the release workflow before cleaning the repository, so that a routine release cannot fire mid-remediation. Third, if an affected version executed on a workstation or a build runner, treat that environment as credential-exposed and rotate accordingly.

Three questions for the board

1. If a widely used dependency were poisoned tomorrow, how long would it take us to answer, with evidence, which builds and which machines executed it?

2. Which of our integrity controls actually validate the input to a build, as opposed to attesting to the build process itself?

3. Who owns the security review of repository configuration that our editors and AI coding agents execute automatically?

If any of the three cannot be answered clearly in a single meeting, the gap is not in the tooling. It is in the assurance model.

The strategic takeaway

Most organisations have optimised for proving where an artefact was built. Very few have invested in proving that what went into the build deserved trust. Those are different problems, and this incident demonstrated that only one of them is solved.

The organisations that handle the next one well will not be the ones with the most scanning tools. They will be the ones that can evidence, on demand and within hours, exactly what ran in their pipeline and on whose machine. That capability is a commercial asset in a security questionnaire, a regulatory submission and a diligence process alike.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification, and specialist technology recruitment as one integrated capability. We are a young firm, the founder personally runs the work, and our perspective comes from a career spent inside cybersecurity and compliance across the sales, marketing and technical sides of the industry.