The mechanism was a checkout swap. Commit `1885610c` repointed the workflow's `actions/checkout` reference at an imposter commit, `70379aad`, which was a composite action that downloaded malicious Go source files from a typosquatted domain [6]. The same change added `--skip=validate` to goreleaser, removing the binary validation step [7]. Tagging that commit was enough to fire the release pipeline [8], and the output went out through GHCR, ECR Public, Docker Hub on both the version and `latest` tags, deb and rpm packages, and get.trivy.dev [9]. Nothing landed on `main`: the malicious code was fetched and built on the ephemeral runner and copied to a `v0.70.0` branch that was never tagged or released [10]. A reviewer reading the default branch would have seen a clean tree. The attempted v0.70.0 release was stopped before it shipped [11].
Across the two action repositories there were 84 published tags. 83 of them pointed at malicious commits and one did not [1]. The survivor is trivy-action 0.35.0, published after GitHub's immutable releases feature was enabled on March 4 [13]. Trivy v0.69.3 held for the same reason, with immutability turned on in the main repository on March 3; v0.69.2 predates that but can still be checked against its sigstore signatures [12]. In both cases the protection was a platform setting applied before publication.
Pinning is where consumers will get this wrong twice. A commit SHA is the standard answer to tag hijacking, and here it works only on the right side of a date: trivy-action began pinning its own dependency in a pull request merged 2025-04-09, so a pin to any earlier commit gives you a safe action that then pulls a malicious setup-trivy during that repository's exposure window [15]. setup-trivy is exposed at every unpinned version [16]. Clear, per the advisory: images referenced by digest, binaries built from source, and the official Homebrew formula, which compiles from source [17]. One custom tap was also compromised, but it needs a deliberate install and is not in the documentation [18].
March 19 is 18 days after the March 1 disclosure [2]. The rotation window that the maintainers say gave the attacker a path back lasted a few days, long enough for a still-valid token to exfiltrate the freshly issued secrets [5]. Everything malicious has been removed from the sources and destinations, and the advisory says it may still sit in intermediary caches [19]. That is the live part now: runner caches, registry mirrors, internal proxies that pulled `latest`. Whatever ran the rewritten `entrypoint.sh` ran an infostealer ahead of the legitimate action code [20], so the scope is set by what those jobs could read.
