Trivy, KICS, and the shape of supply chain attacks so far in 2026 | Docker

Secure, minimal container images for every team, free with enterprise features, if needed.
In the past few weeks we’ve worked through two supply chain compromises on Docker Hub with a similar shape: first Trivy, now Checkmarx KICS. In both cases, stolen publisher credentials were used to push malicious images through legitimate publishing flows. In both cases, Docker’s infrastructure was not breached. And in both cases, the software supply chain of everyone who pulled the compromised tags was briefly exposed.
This is our account of what happened with KICS, what affected users should do, and what the pattern says about where defenders need to invest.
On April 22, 2026 at approximately 12:35 UTC, a threat actor authenticated to Docker Hub using valid Checkmarx publisher credentials and pushed malicious images to the checkmarx/kics repository. Five existing tags were overwritten to malicious digests (latest, v2.1.20, v2.1.20-debian, alpine, debian) and two new tags (v2.1.21, v2.1.21-debian) were created. The images were built from an attacker-controlled source repository, not from Checkmarx’s.
The poisoned binary kept the legitimate scanning surface intact and added a quiet exfiltration path. Scan output was collected, encrypted, and sent to attacker-controlled infrastructure at audit.checkmarx[.]cx, with the User-Agent KICS-Telemetry/2.0. Because KICS scans Terraform, CloudFormation, Kubernetes and similar configuration files, its output routinely contains secrets, credentials, cloud resource names, and internal topology.
Affected malicious digests (any one of these in your pull history should be treated as malicious):
If your CI ran kics against any repository with credentials in scope during the exposure window, rotate those credentials now. Re-pull checkmarx/kics by digest, not tag, and pin your CI to the digest so a future overwrite cannot silently affect you again. Purge the malicious digests from local caches, CI runners, pull-through registries, and mirrors: a clean pull won’t remove what’s already been cached. Check egress logs for connections to audit.checkmarx[.]cx, or outbound traffic with the KICS-Telemetry/2.0 User-Agent, which are strong indicators that exfiltration occurred on your infrastructure.
The affected digests are disabled, the repository has been restored to its last known-good state, and pulls of checkmarx/kics today return the legitimate March 3, 2026 image. The publisher account used to push the malicious images has been suspended, and we’ve notified the small number of users our telemetry shows pulled the compromised digests.Socket’s technical analysis of the issue is here. Their post also covers what appears to be a broader Checkmarx compromise, including recent VS Code extension releases, which is worth reading if your developers use those extensions.
Within about half an hour of the push, a new image on a repository we monitor triggered a review. A check against the upstream source found no matching release, and the provenance showed the image had been built from a different source repository created one day before the push. That was enough to quarantine the repository and start forensics with Socket and Checkmarx.
The defense is in correlation, not any single signal. In this episode, we found a new tag without an upstream release, provenance from an unfamiliar source, and a timing pattern that did not appear to match normal publishing behavior. Since we happened to see these signals together, they bought us a narrow window in which to act. It has to be noted that layered defense shortens the window between push and takedown, it does not prevent the push.
The uncomfortable thing about this incident, and Trivy before it, is how little sophistication incidents such as these require these days. A stolen credential from an IDE extension compromise, a target chosen from a public profile, a push through the normal publishing flow, and the attacker is inside the software supply chain of every organization that pulls that tag. Our assumption is this attack did not require any zero-days, novel tradecraft, or nation-state level budgets. The ingredients are stolen credentials and time, and both are abundant right now.
Every registry, every package manager, and every publisher of any consequence is in the firing line, including Docker. This isn’t a Checkmarx problem or a Hub problem or an npm problem. It’s the new baseline, and defenders who aren’t planning for it as the default case are already behind.
There are two implications for our ecosystem.
Credential hygiene at the publishing boundary matters more than it used to: fine-grained tokens scoped to a single registry, shorter credential lifetimes, clean separation between personal and publisher identities.
And that no single layer will catch all of this. Publishing-time verification, provenance, signatures, registry-side monitoring, deep package inspection (the kind Socket does to catch malicious behavior in dependencies), runtime egress controls, and cross-registry signal correlation each have to do some of the work, because any of them alone will miss cases the others catch.
In the Docker Hardened Images catalog, images are built by Docker from source, with verified provenance and signed releases produced through a hardened build pipeline. The class of attack described above, where a valid publisher credential pushes a tag that diverges from its upstream source, is structurally much harder to execute against an image built this way. There is no external credential that can substitute its way in; the provenance and the signatures have to match, or the image doesn’t ship. The DHI catalog is expanding, and we’re investing in this layer precisely because of the scenario and reasons explored in this blog.
The reason this incident got caught quickly, the reason Socket was able to produce a technical analysis within hours, and the reason Checkmarx’s response could move in parallel with ours, is that all three teams shared