Trivy, KICS, and the shape of supply chain attacks so far in 2026
Trivy, KICS, and the shape of supply chain attacks so far in 2026 | Docker
Insights on the state of AI agents from 800+ builders and leaders. Download your copy
✕
[](http://www.docker.com/)
- AI
AI
- Docker for AI Simplifying Agent Development
- Docker MCP Catalog and Toolkit Connect and manage MCP tools
- Docker Model Runner Local-first LLM inference made easy
- Docker Sandboxes New Isolated environments for coding agents
More resources for developers
Products
- Docker Hardened Images New Ship with secure, enterprise-ready images
- Docker Desktop Containerize your applications
- Docker Hub Discover and share container images
- Docker Scout Simplify the software supply chain
- Docker Build Cloud Speed up your image builds
- Testcontainers Desktop Local testing with real dependencies
- Testcontainers Cloud Test without limits in the cloud
- Docker MCP Catalog and Toolkit New Connect and manage MCP tools
- Docker Offload Break free of local constraints
- Developers
Developers
- Documentation Find guides for Docker products
- Getting Started Learn the Docker basics
- Resources Search a library of helpful materials
- Training Skill up your Docker knowledge
- Extensions SDK Create and share your own extensions
- Community Connect with other Docker developers
- Open Source Explore open source projects
- Preview Program Help shape the future of Docker
- Customer Stories Get inspired with customer stories
More resources for developers
Company
- About Us Let us introduce ourselves
- What is a Container? Learn about containerization
- Why Docker Discover what makes us different
- Trust Find our customer trust resources
- Partners Become a Docker partner
- Customer Success Learn how you can succeed with Docker
- Events Attend live and virtual meet ups
- Docker Store Gear up with exclusive SWAG
- Careers Apply to join our team
- Contact Us We’d love to hear from you
Search
Toggle menu
Trivy, KICS, and the shape of supply chain attacks so far in 2026
Posted Apr 23, 2026
Catching the KICS push: what happened, and the case for open, fast collaboration
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.
What happened
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):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15`For alpine, v2.1.20, v2.1.21 -> Index manifest digest: sha256:2588a44890263a8185bd5d9fadb6bc9220b60245dbcbc4da35e1b62a6f8c230d`
`Image digest (amd64): sha256:d186161ae8e33cd7702dd2a6c0337deb14e2b178542d232129c0da64b1af06e4`
`Image digest (arm64): sha256:415610a42c5b51347709e315f5efb6fffa588b6ebc1b95b24abf28088347791b`
`For debian, v2.1.20-debian, v2.1.21-debian -> Index manifest digest: sha256:222e6bfed0f3bb1937bf5e719a2342871ccd683ff1c0cb967c8e31ea58beaf7b`
`Image digest (amd64): sha256:a6871deb0480e1205c1daff10cedf4e60ad951605fd1a4efaca0a9c54d56d1cb`
`Image digest (arm64): sha256:ff7b0f114f87c67402dfc2459bb3d8954dd88e537b0e459482c04cffa26c1f07`
`For latest -> Index manifest digest: sha256:a0d9366f6f0166dcbf92fcdc98e1a03d2e6210e8d7e8573f74d50849130651a0`
`Image digest (amd64): sha256:26e8e9c5e53c972997a278ca6e12708b8788b70575ca013fd30bfda34ab5f48f`
`Image digest (arm64): sha256:7391b531a07fccbbeaf59a488e1376cfe5b27aef757430a36d6d3a087c610322`
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.
How we caught this breach
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 bar for this kind of attack has collapsed
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.
A note on where this is structurally harder
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.
No one catches this alone
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 signals and samples in real time. The Trivy response looked the same, as did the rapid notification to GitHub about the attacker-controlled source repository.
This is the posture the ecosystem needs more of, not less. Supply chain attackers are routing across registries, IDE marketplaces, source hosts, and CI systems in hours. Defenders who don’t share signals across those same boundaries are operating from a point of disadvantage. Formal standards for cross-registry coordination are still emerging, and they will matter eventually. What’s kept the windows short so far has been teams working with a spirit of openness, willingly sharing what they’re discovering, in real time.
Docker will keep investing in layered defenses on Hub, keep extending publishing-time verification to more of the catalog, and keep showing up to share signals, whether this is across a partner’s incident channel, a peer registry’s investigation, or the rooms where a more durable framework for coordination eventually takes shape.
We want to thank the Socket research team for fast, independent analysis, and to Checkmarx for moving alongside us on a tight timeline for this one.
Further reading
Socket blog: https://socket.dev/blog/checkmarx-supply-chain-compromise
Docker Hardened Images on Docker Hub: https://hub.docker.com/hardened-images/catalog
Table of contents
- Catching the KICS push: what happened, and the case for open, fast collaboration
- What happened
- How we caught this breach
- The bar for this kind of attack has collapsed
- A note on where this is structurally harder
- No one catches this alone
[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Ftrivy-kics-and-the-shape-of-supply-chain-attacks-so-far-in-2026%2F "Visit this Linkedin profile")[](https://twitter.com/intent/tweet?url=https%3A%2F%2Fwww.docker.com%2Fblog%2Ftrivy-kics-and-the-shape-of-supply-chain-attacks-so-far-in-2026%2F "Visit this X profile")[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.docker.com%2Fblog%2Ftrivy-kics-and-the-shape-of-supply-chain-attacks-so-far-in-2026%2F "Visit this Facebook profile")
Related Posts
- Mar 31, 2026 #### Docker Sandboxes: Run Agents in YOLO Mode, Safely Agents have crossed a threshold. Over a quarter of all production code is now AI-authored, and developers who use agents are merging roughly 60% more pull requests. But these gains only come when you let agents run autonomously. And to unlock that, you have to get out of the way. That means letting agents run… 
- Apr 16, 2026 #### Why MicroVMs: The Architecture Behind Docker Sandboxes Last week, we launched Docker Sandboxes with a bold goal: to deliver the strongest agent isolation in the market. This post unpacks that claim, how microVMs enable it, and some of the architectural choices we made in this approach. The Problem With Every Other Approach Every sandboxing model asks you to give something up. We… 
- Apr 14, 2026 #### Why We Chose the Harder Path: Docker Hardened Images, One Year Later We’re coming up on a year since launching Docker Hardened Images (DHI) this May, and in this blog we celebrate the milestones, talk about our approach, and look at some practices in the industry. 
- Apr 13, 2026 #### How to Analyze Hugging Face for Arm64 Readiness Learn how to scan Hugging Face Spaces for Arm64 readiness using Docker MCP Toolkit and Arm MCP Server in minutes. 
Products
- Products Overview
- Docker Desktop
- Docker Hub
- Docker Scout
- Docker Build Cloud
- Testcontainers Desktop
- Testcontainers Cloud
- Docker MCP Catalog and Toolkit
- Docker Hardened Images
Features
- Command Line Interface
- IDE Extensions
- Container Runtime
- Docker Extensions
- Trusted Open Source Content
- Secure Software Supply Chain
Developers
Pricing
Company
- About Us
- What is a Container
- Blog
- Why Docker
- Trust
- Customer Success
- Partners
- Events
- Docker System Status
- Newsroom
- Swag Store
- Brand Guidelines
- Trademark Guidelines
- Careers
- Contact Us
Languages
- [](http://twitter.com/docker)
- [](https://www.linkedin.com/company/docker)
- [](https://www.instagram.com/dockerinc/)
- [](http://www.youtube.com/user/dockerrun)
- [](https://www.facebook.com/docker.run)
- [](http://www.docker.com/blog/feed)
© 2026 Docker Inc. All rights reserved
Cookies Settings
By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts.
Cookies Settings Reject All Accept All Cookies
Privacy Preference Center
When you visit any website, it may store or retrieve information on your browser, mostly in the form of cookies. This information might be about you, your preferences or your device and is mostly used to make the site work as you expect it to. The information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies. Click on the different category headings to find out more and change our default settings. However, blocking some types of cookies may impact your experience of the site and the services we are able to offer.
Allow All
Manage Consent Preferences
#### Functional Cookies
- [x] Functional Cookies
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
#### Strictly Necessary Cookies
Always Active
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
#### Performance Cookies
- [x] Performance Cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
#### Targeting Cookies
- [x] Targeting Cookies
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Cookie List
Clear
- [x] checkbox label label
Apply Cancel
Consent Leg.Interest
- [x] checkbox label label
- [x] checkbox label label
- [x] checkbox label label
Reject All Confirm My Choices
