The join between these two PyPI projects and the rest of the campaign rests on access rather than on a published payload signature. Datadog's reading is that one operator moved from project to project, siphoning credentials and spending them on the next target, with each stage reusing tradecraft or tokens from the one before it [7]. There is one concrete infrastructure overlap in the write-up: the callback domain from the March 20 npm worm was, by March 22, also serving a Kubernetes script that sorted victims into a destructive and a non-destructive path [15]. Shared infrastructure is decent evidence that stages belong to one operation. It says very little about what any individual victim lost, which is why the response guidance, not the attribution, is the load-bearing part of the report.
The best-documented payload in the campaign is the Trivy stage, and it explains that guidance. The malicious trivy-action and setup-trivy commits dumped Runner.Worker memory, scraped common credential locations, encrypted the results with AES and RSA, and shipped them to a look-alike domain, scan.aquasecurtiy[.]org [10]. When direct exfiltration failed and a usable GitHub token was present on the runner, the code created a public repository called tpcp-docs and uploaded the stolen data there instead [11]. A team that blocked the exfiltration domain and called the matter contained has misread the design, because the fallback leaves through the same service the build already talks to. Uninstalling a version restores the dependency tree without undoing an exfiltration.
Scale, where the report gives numbers. On March 19 the actor force-pushed 76 of 77 aquasecurity/trivy-action tags to malicious commits and replaced all seven setup-trivy tags [8]; that is 98.7% of the action's tags [1]. The npm stage covered 28 packages in @EmilGroup and 16 in @opengov plus three named singletons [12], 47 in total across the scopes listed [2]. The worm resolved which packages each stolen token was allowed to publish, bumped patch versions, and re-fetched the original READMEs so the listings looked untouched [13]. From the first poisoned Trivy release to the telnyx backdoor is eight days [3].
The thing this doesn't tell you is your own denominator. The write-up publishes no install or download counts for the four backdoored versions [4], so exposure has to be rebuilt from your CI logs rather than read off the report. Nor does it state how the maintainer credentials for either PyPI project were obtained [5], which is the fact that would tell a downstream team whether the way in is shut. And the branching in the Kubernetes script is worth holding onto for anyone inclined to read a quiet host as an untouched one: it checked timezone and locale, deleted the filesystem and force-rebooted on systems it judged Iranian [16], and installed persistent backdoor logic on everything else [17].
My view, with its condition attached. If any of those four versions touched a runner, treat every credential that runner could see as burned and rotate on that basis [6]. If the job held nothing beyond a short-lived, narrowly scoped token, the blast radius really is smaller, but that is a claim about your CI hygiene, not about the package.
