Skip to main content
Hackers Compromised a Security Tool to Steal the Secrets It Was ScanningIncident
5 min readFor Compliance Teams

Hackers Compromised a Security Tool to Steal the Secrets It Was Scanning

What Happened

On April 22, 2026, attackers replaced legitimate Docker images of Checkmarx's KICS (Keeping Infrastructure as Code Secure) tool with malicious versions. KICS is an open-source scanner that analyzes infrastructure-as-code files for security misconfigurations, accessing AWS credentials, API tokens, database passwords, and other secrets embedded in Terraform configs, CloudFormation templates, and Kubernetes manifests.

The compromised images included a malicious "MCP addon" that exfiltrated every credential and token it encountered to audit.checkmarx[.]cx, a domain designed to impersonate legitimate Checkmarx infrastructure. Socket's investigation revealed the breach after developers reported suspicious network activity. The hacking group TeamPCP claimed responsibility.

Timeline

April 22, 2026, 14:17:59 UTC: Malicious Docker images published to DockerHub under the official Checkmarx KICS repository.

April 22, 2026, 14:18-15:41 UTC: Developers worldwide pull and run compromised images during their CI/CD pipelines and local scans.

April 22, 2026, 15:41:31 UTC: Malicious images removed from DockerHub.

April 22-23, 2026: Socket begins investigation after receiving reports of anomalous network connections.

April 23, 2026: Checkmarx confirms breach and advises credential rotation.

The 84-minute window represents the documented availability period on DockerHub. Any organization that pulled the image during this window—or cached it in their container registry—became a potential victim.

Which Controls Failed or Were Missing

Image Signing and Verification

The compromised images weren't signed with Checkmarx's cryptographic keys. Organizations that pulled these images didn't verify signatures before execution. This failure allowed unverified container images to run in environments with access to production credentials.

Least Privilege Access

KICS scans ran with the same credential access as the environments they analyzed. The tool had read access to configuration files containing production AWS keys, GCP service account tokens, and database connection strings. However, there was no isolation limiting what the tool could do with that access once it read the secrets.

Network Egress Controls

The malware successfully exfiltrated data to an external domain that mimicked Checkmarx infrastructure. Network policies didn't restrict outbound connections from the scanning environment, and DNS filtering didn't flag the suspicious domain registration.

Supply Chain Integrity Monitoring

Organizations had no automated detection for when their trusted tools changed. No alerts fired when the KICS image digest changed, when new network connections appeared in the tool's behavior, or when the image began communicating with domains outside the expected pattern.

What the Relevant Standards Require

PCI DSS v4.0.1 Requirement 6.3.2 mandates that "bespoke and custom software are developed securely" and specifically calls out supply chain risk in Requirement 6.4.3: "All system components and software are protected from known vulnerabilities by installing applicable security patches/updates." While KICS isn't a payment application, the principle applies: if you're using third-party tools in your cardholder data environment, you must verify their integrity.

NIST 800-53 Rev 5 Control SR-3 (Supply Chain Controls and Processes) requires organizations to "employ supply chain risk management processes, procedures, and tools to protect against supply chain risks to organizational systems and system components." Control SA-12 specifically addresses supply chain protection and requires verification mechanisms for software and firmware integrity.

ISO 27001 Control 8.30 (Outsourced Development) states that "the organization shall direct, monitor and review the activities related to outsourced system development." When you run third-party security tools, you're outsourcing part of your security function—which means you need controls to verify what those tools actually do.

SOC 2 Type II Common Criteria CC6.1 requires that "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives." Running unverified container images in environments with credential access violates this control.

Lessons and Action Items for Your Team

Implement Image Signing Verification Today

Configure your container runtime to require signature verification. For Docker, use Docker Content Trust. For Kubernetes, implement admission controllers that reject unsigned images. If Checkmarx had signed their images, your runtime would have rejected the malicious versions automatically.

Add this to your Docker daemon config:

"content-trust": {
  "mode": "enforced"
}

Isolate Security Tool Execution

Run scanners like KICS in dedicated environments with read-only filesystem access and no network egress except to approved destinations. Use Kubernetes NetworkPolicies or AWS Security Groups to whitelist only the specific endpoints your tools legitimately need. The malware couldn't exfiltrate what it couldn't reach.

Rotate Credentials on a Schedule, Not Just Post-Incident

If you're rotating credentials only after breaches, you're already compromised. Implement 90-day rotation for all service accounts and API tokens. Use secret management tools (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) that support automated rotation. This limits the window of exposure when—not if—credentials leak.

Monitor for Supply Chain Mutations

Set up alerts when container image digests change for your trusted tools. Pin your dependencies to specific image SHAs, not tags. Create a baseline of expected network connections for each tool and alert on deviations. Socket detected this breach because they monitor for unexpected network behavior—you should too.

Audit What Your Tools Can Actually Access

Map every security tool in your pipeline to the credentials it can read. KICS needs to read your IaC files, but does it need write access to your AWS account? Does it need network access to your production database? Apply least privilege: give tools only the minimum access required for their function.

Verify Your Current KICS Images

If you ran KICS between April 22, 2026 14:17:59 UTC and 15:41:31 UTC, assume compromise. Rotate every credential and token that existed in any repository or configuration file the tool scanned. Check your container registry for cached versions of the malicious image and delete them. The safe image digests are documented in Checkmarx's security advisory—verify against those specific SHAs.

The attackers didn't exploit a zero-day vulnerability. They compromised a trusted distribution channel and relied on organizations running unverified code with privileged access. Every control that failed here is documented in existing standards. The question isn't whether you know what to do—it's whether you've actually implemented it.

Topics:Incident

You Might Also Like