Poisoned artifact: how one Artifactory token taints every build

A poisoned artifact is a supply-chain weapon. The harm does not land on the repository, it lands on every downstream build that resolves the dependency and executes attacker code.

How the attack works

A stolen Artifactory access token deploys to a shared repo from an unfamiliar client. It publishes a new version of a widely-consumed internal package with an added post-install payload. CI pipelines that float to the latest version pull the poisoned artifact and run its payload during build, and the affected build agents begin beaconing outbound. In ATT&CK terms this is T1195, Supply Chain Compromise, riding on T1078, Valid Accounts.

Why it works

The artifacts were not signed or verified on resolve, a single long-lived token had deploy rights to a shared repo, and consumers floated to latest. Anyone holding that token could publish, and every build trusted whatever was newest, so a stolen credential became a path into every pipeline at once.

How to fix it

Revoke the token, then remove or quarantine the poisoned version and block its resolution so builds stop pulling it. The move that actually protects consumers is to republish a clean signed artifact and explicitly warn downstream teams to pin a known-good version. Do not take the whole instance offline or wipe version history, both are overbroad. Scope the blast radius from the Artifactory download log, which names every client that resolved that exact version, and treat their build secrets and signing material as compromised. As a class fix, require artifact signing with verification on resolve, restrict publish to a dedicated CI identity with scoped short-lived tokens, pin dependency versions, and scan on publish.

Practice it

We built this as a GraphLattice Range scenario so developers can rehearse pulling the poison, republishing signed, and scoping consumers from the download log.