checkmarx kics, round two: eighty minutes to trojanized docker

on april 22 at approximately 12:35 utc, a threat actor authenticated to docker hub using valid checkmarx publisher credentials and pushed malicious images to the official checkmarx/kics repository. five existing tags were overwritten. two new tags were created. the malicious images ran for roughly 80 minutes before being caught and pulled. the threat actor is tracked as teampcp. this is the second successful attack on checkmarx's supply chain in two months.

the first round happened in march. teampcp compromised two of checkmarx's github actions workflows, ast-github-action and kics-github-action. different vector, same vendor, same target: the trust that security-tooling vendors earn by being the piece of the pipeline that watches everything else.

what actually shipped

the tags overwritten on april 22 were latest, v2.1.20, v2.1.20-debian, alpine, and debian. two new tags were published: v2.1.21 and v2.1.21-debian. "latest" is the one that hurts most — any ci pipeline that pulls checkmarx/kics:latest got the trojanized build.

the malicious binary keeps doing the job of kics — it runs a scan, it produces an output that looks reasonable to the human who requested it. the attack happens underneath. the binary generates a second, uncensored version of the scan report, encrypts it, and exfiltrates it to an attacker endpoint.

that is the surprising detail. the attackers did not go for credentials or cloud keys directly. they went for the scan reports themselves. a kics scan report contains, by design, every secret that kics believes might be a secret: api keys in config files, connection strings in helm charts, hard-coded tokens in test fixtures, service account json blobs in ci fixtures. the scan report is a consolidated, structured inventory of the worst exposure in your repos. exfiltrating the uncensored version from thousands of organizations over 80 minutes is a credential goldmine.

the vs code and open vsx extensions for kics got hit too, with a slightly different payload: a hidden component called an "mcp addon" that the extension downloaded silently and used to fetch a separate secret-stealer. model context protocol-adjacent tooling has become normalized in developer environments in the past year, which turns any "i installed a helper thing" moment into a broader attack surface than it used to be.

teampcp is running a campaign

two compromises of the same vendor in two months by the same threat actor is not a coincidence. it is a campaign.

march: teampcp landed on two github actions workflows used to build and distribute kics. they used the actions-level access to inject code into published artifacts. checkmarx disclosed, rotated, cleaned up.

april: teampcp came back through a different vector — docker hub publisher credentials — and hit the same product again. this time they were faster, used a more targeted payload (scan-report exfil, not broad credential theft), and got a wider distribution surface (the latest tag plus four others, plus two vs code extension marketplaces).

the pattern is familiar. once a threat actor gets into a vendor's ecosystem and gets comfortable with their release process, they come back. the first intrusion teaches them the vendor's internal handoffs, the second intrusion exploits the next handoff out.

what security teams should actually do

if you used checkmarx/kics between 14:17 utc and 15:41 utc on april 22 — and "used" includes automated ci/cd runs, not just developer laptops — you should assume the scan output is in the attacker's possession. that means every repo scanned, every secret kics flagged, every path that kics walked. rotate accordingly.

specifically rotate:

• source control tokens that kics had access to during the scan run
• any cloud credential that appeared in scanned code, including as an env var reference
• ci/cd system secrets that the kics run had in scope
• any registry, artifact store, or package publisher tokens that the scan environment could see
• openai, anthropic, or other llm provider api keys that live in ai-adjacent repos

remove all kics images you pulled on april 22 from developer systems, ci runners, and container registries. remove the kics vs code and open vsx extensions. repull clean builds from checkmarx only after their post-incident verification lands.

treat this as a scoping exercise, not a patching exercise. the difference between "i applied the patch" and "i know what the attacker saw" is the difference between closed and actually closed.

the broader lesson

security tooling vendors are a high-value target because they sit at a unique junction: they have privileged access to private source code, they read ci/cd secret stores, they run with elevated permissions, and their customers generally trust them by default. any supply chain compromise against a scanner vendor, a sast or dast product, a software composition analysis tool, or a secrets manager is systemically worse than a compromise of a less-privileged vendor.

the correct defensive posture for 2026 is to treat security tooling artifacts with the same skepticism you apply to any other critical supply chain input. pin by digest, not by tag. review release notes and signing material. monitor the vendor's public incident feed. and pressure-test your assumption that "oh that tool is already there, it's fine" — because the base rate of security vendors getting supply-chain-hit has climbed fast enough in 2025 and 2026 that the "already there" assumption has lost most of its weight.

teampcp will be back. the next compromise of checkmarx — or of a different scanner vendor in the same class — is already on somebody's calendar. plan accordingly.

Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if your team needs help auditing what your devsecops stack has access to.

Related reading

On TeamPCP's first hit against Checkmarx this quarter: Your AI Stack Has a Supply Chain Problem — and TeamPCP Just Proved It

On scanner vendors as supply-chain targets: Your Vulnerability Scanner Just Became the Vulnerability

On supply-chain compromise through trusted AI vendor pipelines: Vercel Got Popped Through an AI Tool Nobody Was Tracking as a Vendor