Checkmarx KICS Docker Hub Compromise, What to Do If You Pulled the Affected Images

Socket Research, alerted by Docker's internal monitoring of the official checkmarx/kics Docker Hub repository, reports that attackers overwrote multiple legitimate KICS image tags with poisoned versions and published counterfeit v2.1.21 / v2.1.21-debian tags with no corresponding upstream release. Two related Checkmarx VS Code / Open VSX extensions (cx-dev-assist and ast-results) were also affected. Socket frames this as part of a broader supply-chain compromise across multiple Checkmarx distribution channels and has now published concrete network and host-side IOCs, summarized below.

Why KICS matters

KICS, short for "Keeping Infrastructure as Code Secure," is a popular open-source IaC scanner that audits Terraform, CloudFormation, Kubernetes manifests, Helm charts, Ansible, Dockerfiles, and similar configuration files for misconfigurations and security issues. It is typically run as a Docker container inside CI/CD pipelines, in pre-merge checks, and on developer workstations through the VS Code extension.

The thing that makes a KICS compromise expensive is the same thing that makes KICS useful: it reads everything in your IaC tree, including the secrets you accidentally committed. A poisoned scanner is in the ideal position to harvest those secrets and quietly upload them somewhere, because the scanner already has a legitimate reason to be reading every line of every file. From an EDR or DLP perspective, the activity looks like normal scan output.

Pattern context: this is Checkmarx's second supply-chain incident in 30 days

On March 23, 2026, Checkmarx disclosed a supply-chain incident affecting two of their Open VSX plugins and two of their GitHub Actions workflows (checkmarx/ast-github-action and checkmarx/kics-github-action). The compromise window for Open VSX was 02:53 to 15:41 UTC; for the GitHub Actions, 12:58 to 16:50 UTC. The attacker-controlled exfiltration domain was checkmarx[.]zone. After remediation, Checkmarx pinned the verified GitHub Actions to ast-github-action v2.3.33 and kics-github-action v2.1.20.

The version overlap is worth flagging. The same version string, v2.1.20, that Checkmarx published as the verified post-incident release of kics-github-action on March 23 is now the version that was overwritten in checkmarx/kics on Docker Hub. Whether that is coincidence (Checkmarx using consistent versioning across artifacts) or signal (an attacker deliberately targeting the version that carries post-remediation trust) is not something I can determine from the public sources, but it is the kind of detail that operators and incident responders should keep in mind when scoping exposure.

Socket's framing of "another" supply-chain compromise, combined with the version overlap and the pattern across distribution channels (Open VSX in March, Docker Hub and VS Code extensions in April), is at minimum consistent with sustained interest in Checkmarx's distribution surface. Whether that interest is one actor or several, public reporting does not yet say.

Am I affected?

Socket has not published the precise exposure window yet, so for now assume any pull or scan during the period leading up to the April 22 disclosure could be in scope. That window will likely tighten as Checkmarx and Socket publish more detail; this guide will need to be updated once they do.

Quick checks

Inventory of where KICS runs in your environment:

grep -r 'checkmarx/kics' .github/ .gitlab-ci.yml Jenkinsfile* .circleci/ 2>/dev/null

What tag a CI pipeline pulled most recently can usually be found in that pipeline's run logs (look for the docker pull line). For local Docker hosts:

docker images checkmarx/kics --format '{{.Repository}}:{{.Tag}} {{.ID}} {{.CreatedAt}}'

For VS Code extension versions across a fleet of dev machines, the installed extensions list is at ~/.vscode/extensions/ on macOS and Linux, and %USERPROFILE%\.vscode\extensions\ on Windows. Look for directories matching checkmarx.cx-dev-assist-1.17.0, checkmarx.cx-dev-assist-1.19.0, checkmarx.ast-results-2.63.0, or checkmarx.ast-results-2.66.0.

Response, if you used the affected artifacts

1. Stop using the affected artifacts immediately. Remove the poisoned images from any CI/CD pipeline that references them by tag. Uninstall the affected VS Code extension versions on any machine that has them. Pull and rebuild any container images that were layered on top of the poisoned KICS images.
2. Identify the exposure window for your environment. Audit Docker pull logs (registry mirrors, host-level Docker daemon logs, CI runner caches) for any pulls of checkmarx/kics with the affected tags. Note when each scan ran. Until Checkmarx and Socket publish a precise exposure window, treat any pull in the days leading up to April 22, 2026 as potentially in scope.
3. Rotate any secret that lived in the IaC files KICS scanned. That includes Terraform variables and tfvars, CloudFormation parameter files, Kubernetes Secrets manifests (encoded base64 is not encryption), Helm values files, Ansible vault contents that were unsealed at scan time, Dockerfile build args, and any .env or credential file present in the scanned directory tree. Cloud credentials, database connection strings, API keys for managed services, registry tokens, signing keys, anything that could appear in a config file. If you don't know exactly what was scanned, scope to "everything in the repo and submodules at the time of the scan." Tightening that scope is harder and slower than rotating the credentials.
4. Pin Docker images by digest, not tag, going forward. Replace checkmarx/kics:latest in pipelines with checkmarx/kics@sha256:<digest> for a known-good version. Mutable tags are exactly the attack surface that got exploited here. Any image you depend on in CI should be pinned to a digest you have verified, with renovation of the digest done deliberately and reviewed.
5. For VS Code / Open VSX extension users, downgrade and audit. If you ran checkmarx/cx-dev-assist 1.17.0 or 1.19.0, or checkmarx/ast-results 2.63.0 or 2.66.0, uninstall them. Per Socket, cx-dev-assist 1.18.0 is reported clean (between the two malicious releases), but until Checkmarx publishes a verified post-incident release I would treat 1.18.0 as "less suspicious, not blessed" rather than actively trusted, and disable the extension entirely until guidance catches up. On the affected machines, audit outbound network connections and proxy logs for connections to the IOCs in the box above.
6. Hunt for indicators on affected hosts and CI runners. Per Socket's IOC and hunt-item list, look for: outbound connections to audit.checkmarx[.]cx/v1/telemetry or to the IP 94[.]154[.]172[.]43; presence of the dropper at ~/.checkmarx/mcp/mcpAddon.js; Bun runtime invocations from VS Code extension contexts; reads of .npmrc, .git-credentials, .env files, and cloud credential stores; unexpected use of gh auth token, gcloud, az, or azd from non-interactive contexts; unauthorized creation of public GitHub repositories; injected GitHub workflows; and suspicious artifacts like format-results.txt appearing where they shouldn't. Push the network IOCs into your DNS sinkhole, EDR, and SIEM rules. Ingest the file hashes Socket published for mcpAddon.js and the trojanized KICS ELF.
7. If a CI runner was the host that pulled the image, treat the runner as compromised. CI runners are credential-rich environments with cloud OIDC tokens, registry credentials, signing keys, and (often) overly broad permissions. A poisoned scanner running on a runner inherits all of that. Rebuild ephemeral runner images from a known-clean base, rotate any long-lived runner credentials, and review the runner's recent activity for unauthorized actions.
8. Document the rotation. Whatever you rotate, keep a record of what was rotated and when. If a downstream incident surfaces in three weeks, you want to be able to answer "yes, that secret was rotated on April 22 at 16:00 UTC" without having to reconstruct it from memory.

The broader lesson

Three things to take away from this one, beyond the immediate response:

First, security tooling is increasingly the target, not the defender. LiteLLM, Telnyx SDK, xinference, and now Checkmarx KICS, all in roughly the last month, all hijacked through their own legitimate distribution channels. The pattern is "compromise the thing that has elevated trust and reads sensitive data," and it works because nobody scans the scanner. If you have a security tool that runs in CI, treat it as part of your supply-chain attack surface, not as something that lives outside it.

Second, mutable tags are a structural weakness. :latest, :alpine, :debian are convenient and attractive in pipelines. They are also the exact mechanism that lets an attacker silently swap a poisoned image into a legitimate reference. Pin to digests. The friction of bumping a digest manually is tiny compared to the cost of being silently fed a poisoned image for an unknown number of pipeline runs.

Third, when the same vendor is hit twice in 30 days across different distribution channels, the right reaction is "what else might be affected" rather than "patch this and move on." The April incident surfaced through Docker Hub monitoring; future incidents may surface through registries that don't have the same monitoring discipline. A vendor-wide trust review for any DevSecOps tool you depend on is a reasonable thing to do once the dust settles here.