DEV Community: Gavriliuc Vlada

The npm Worm That Keeps Coming Back — And Why Governments Are Finally Procuring a Fix

Gavriliuc Vlada — Tue, 08 Sep 2026 11:22:08 +0000

On August 28, 2026, a npm package called @7nohe/openapi-react-query-codegen — a TanStack Query codegen tool with over 150,000 weekly downloads — started shipping malware. Ten malicious versions went out in twenty minutes. If that timeline sounds familiar, it should: this is the same Shai-Hulud worm family that's been eating through the npm and PyPI ecosystems since September 2025, now on its latest variant, nicknamed Trinitite.

What's actually interesting here isn't just "another supply chain attack." It's how the attack got in, how little changed about the fix, and — maybe more relevant if you build software that governments end up buying — how regulators are starting to respond with actual procurement, not just guidance documents.

How Trinitite Got In

The compromised release workflow had a genuinely dumb weak point: it treated a pull request comment containing the literal string "npm publish" as authorization to publish a release. No check that the commenter was a maintainer. The attacker checked out the PR, and GitHub Actions OIDC did the rest, publishing straight through the project's own trusted, legitimate pipeline.

This is the pattern that's defined the whole Shai-Hulud campaign since the original TanStack compromise in May 2026 (CVE-2026-45321, CVSS 9.6): attackers aren't targeting the package anymore, they're targeting the pipeline. That May incident chained a pull_request_target trigger, GitHub Actions cache poisoning, and OIDC token extraction from runner process memory — and the packages it produced carried valid SLSA Build Level 3 provenance attestations. Read that again: a worm that produces validly signed, attested malicious packages. Provenance confirms where an artifact was built. It says nothing about whether attacker-controlled code executed inside that trusted environment.

Once installed, Trinitite runs a fairly elaborate obfuscation chain — an XOR-wrapped loader, a hidden binding.gyp execution path that fires even when you run npm install --ignore-scripts, AES-256-GCM encrypted payload blobs — before dropping into familiar Shai-Hulud territory: stealing GitHub, npm, PyPI, RubyGems, cloud, Vault, and Kubernetes credentials, then republishing itself through any package the stolen credentials can reach.

One detail that puts the scale in perspective: a report from early September found that the latest Shai-Hulud variant now scans 469 distinct credential locations across developer machines, CI/CD tooling, cloud configs, and even AI tool configs, up from 189 in earlier versions. The attackers aren't breaking trust relationships anymore. They're just harvesting the credentials that make those relationships work in the first place.

Why "Just Review Your Dependencies" Isn't Really an Answer Anymore

Every writeup on this campaign converges on roughly the same mitigation list: lock down GitHub Actions cache and fork PR behavior, restrict which workflows can mint OIDC publish tokens, don't trust a passing provenance check as proof of safety, treat every secret reachable from a build environment as already exposed.

All correct. All also things a single team can only partially control, because the actual risk isn't your code — it's the 500+ transitive dependencies you didn't write, sitting in a supply chain you can't fully see. That's exactly the gap a Software Bill of Materials (SBOM) is meant to close: a structured, machine-readable inventory of every component and dependency in a piece of software, so when the next Trinitite-style compromise hits, you can actually answer "are we exposed?" in minutes instead of days of manually grepping lockfiles.

SBOMs for traditional software are already a regulatory requirement in the EU under the Cyber Resilience Act. What's newer, and what makes this genuinely current, is that the same idea is now being extended specifically to AI systems — where the "dependency graph" includes not just packages but models, datasets, and fine-tuning pipelines, none of which fit cleanly into a traditional SBOM format.

A Government Is Already Procuring This

Here's where it stops being abstract. Germany's Federal Office for Information Security (BSI) has an open tender for a project called SBOM4AI, published August 28, 2026 — the same day Trinitite started shipping, though the timing there is coincidental rather than causal.

The scope is specific: take the "SBOM for AI – Minimum Elements" concept published under the G7 framework and turn it into an actual technical implementation — a system that automatically generates a machine-readable SBOM for AI systems, in a format usable by developers, auditors, and regulators, explicitly designed to support Cyber Resilience Act auditability requirements. Contract duration is 18 months, deadline for bids is September 28, 2026.

What I find worth paying attention to isn't the tender itself so much as what it signals: a national cybersecurity authority is treating "we don't have a standard, automatable way to know what's inside an AI system's supply chain" as a problem serious enough to fund directly, rather than waiting for the private sector or a nonprofit consortium to solve it. Given that AI coding assistants are themselves accelerating how fast new dependencies get pulled into codebases — often outside standard package managers entirely — that's not a bad instinct.

What This Actually Means for Your Pipeline

You don't need a government contract to take the lesson here. A few concrete things worth doing regardless of team size:

Generate an SBOM as part of your build, not as an afterthought. Tools like Syft, CycloneDX, or GitHub's own dependency graph can do this automatically; the point is having it before an incident, not scrambling to reconstruct it during one.
Stop trusting provenance as a safety signal. SLSA attestations tell you where something was built. They don't tell you the build wasn't compromised in-flight, as Trinitite proved twice now.
Isolate fork PR workflows from cache and publish permissions. The pull_request_target and comment-triggered-publish patterns behind both major TanStack incidents are avoidable with a few lines of workflow config.
Treat any secret reachable from a CI runner as already leaked. Rotate on a schedule, not just on suspicion.

Trinitite won't be the last variant. The people behind the original TeamPCP toolkit were reportedly arrested in Australia shortly before this wave shipped, using the same core malware with new keys and new graffiti strings — which tells you the tooling outlives the individuals running it. The realistic goal isn't preventing the next worm. It's making sure that when it lands, you can answer "what do we actually have deployed, and what depends on it" faster than the worm can spread.

The State Machine Hiding Inside Every Construction Project

Gavriliuc Vlada — Mon, 17 Aug 2026 12:01:31 +0000

Here's a distributed systems problem you probably haven't thought about: dozens of independent teams, each editing their own piece of a shared 3D model, over a timeline of years, where a stale read can mean someone pours concrete based on the wrong version of a structural drawing.

That's the problem Building Information Modeling (BIM) has to solve, and the system that solves it is called a Common Data Environment, or CDE. It's worth understanding, because it's one of the cleaner real-world examples of a versioned, permissioned, multi-writer data system with the state machine spelled out as an actual international standard instead of left to whatever a team improvised.

Why plain file storage doesn't work here

A typical BIM project involves architects, structural engineers, MEP contractors, the client, and external consultants, all editing models that constantly reference each other. A structural engineer's model has to line up with the architect's, which has to line up with the electrical contractor's, across design, approval, and construction phases spanning years.

Dropbox or SharePoint can hold the files. What they can't answer natively is the question every contributor actually needs answered: is this specific revision of this specific file the one I'm allowed to build from right now, or is it still a draft someone's iterating on? Get that wrong on a construction site and the cost isn't a merge conflict, it's a physical rebuild.

The data model: containers, not files

The standard that governs this, ISO 19650, doesn't treat a file as just a file. It defines an "information container": a unit of data with mandatory structured metadata attached:

State: exactly one of four values at any time: Work in Progress, Shared, Published, or Archived
Status code (suitability): what the container is currently allowed to be used for, e.g. "for coordination" or "authorized for construction"
Revision: a tracked version number
Classification: a category code so containers can be filtered and queried systematically, usually against a scheme like Uniclass

The four states form a directed workflow, not just labels. A container in Work in Progress is visible only to the team producing it. Once it's stable enough for others to reference (but not yet final), it moves to Shared. Once it's contractually approved, it moves to Published. Transitions are meant to be one directional, with defined exceptions for rejection back to an earlier state.

If you've built approval workflows for a CMS or a PLM system, this pattern will look familiar: draft, review, publish, archive. What's different here is that the states, the metadata schema, and the transition rules are externally standardized, so a CDE built by one vendor and a CDE built by another are expected to expose the same conceptual model, even if the implementation differs.

The hard engineering problems

A few things make this genuinely nontrivial to build well, beyond just implementing a four-state enum:

Access control that depends on lifecycle state, not just role. A permission model here isn't "editor vs viewer." It's "this user can read this container, but only because it's in the Shared state, and only certain fields of its metadata, and that access should change automatically the moment the container moves to Published." That's state-dependent authorization, layered on top of normal role-based access, and it has to be enforced consistently across every client that touches the data.

Interoperability across authoring tools. Contributors use different BIM software (Revit, ArchiCAD, Civil 3D, and others), each with its own native file format. To avoid vendor lock-in on the authoring side, CDEs generally need to support IFC (Industry Foundation Classes), an open, schema-based exchange format that represents building elements as structured entities with relationships, not just geometry. Round-tripping data through IFC without losing information is its own hard problem, since different tools implement the schema with slightly different interpretations.

Multi-project isolation at scale. A CDE is rarely built for one project. It's typically operated as a platform serving many concurrent projects for the same organization, which means project spaces need to be cleanly isolated from each other while still sharing common infrastructure, user directories, and organizational permission structures. Get the isolation boundary wrong and you risk cross-project data leakage, which in a public infrastructure context is a real liability, not just a bug.

Auditability as a first-class requirement, not a feature. Every state transition and revision needs a traceable record: who moved it, when, and under what authorization. This isn't optional logging. In regulated or public-sector contexts, "who approved this exact version, and when" is often a contractual and legal requirement, which means the audit trail has to be tamper-evident, not just present.

Seeing the spec in the wild

If you want to see what a real-world requirement for one of these platforms actually looks like, Germany's state highway authority for North Rhine-Westphalia currently has an open tender for a cloud-based CDE, meant to support around 90 BIM projects over a four year framework. It's a useful read if you want to see how these architectural requirements (multi-tenant isolation, managed cloud delivery, structured functional evaluation) get translated into a concrete specification instead of staying abstract.