CISA added CVE-2026-33634 to KEV on March 26 after active exploitation evidence. Teams using Trivy in CI/CD should treat this as an immediate exposure review.
On March 26, 2026, CISA added CVE-2026-33634 to the Known Exploited Vulnerabilities catalog. That matters because KEV inclusion means there is evidence of real-world exploitation, not just a high score on a vulnerability scanner. The KEV entry identifies an embedded malicious code issue in Trivy and explicitly warns that exploitation can expose sensitive CI/CD material, including tokens, keys, and cloud credentials. For any organization that uses Trivy in GitHub Actions or pipeline automation, this instantly becomes an incident-response question rather than a routine dependency upgrade task.
The technical sequence is documented by NVD and vendor advisories. On March 19, an attacker used compromised credentials to publish malicious Trivy v0.69.4, force-push 76 of 77 tags in aquasecurity/trivy-action, and replace all 7 tags in aquasecurity/setup-trivy with malicious commits. Affected ranges and known-safe versions are clearly listed: Trivy v0.69.4 is affected, while v0.69.2 and v0.69.3 are identified as safe in guidance; trivy-action is safe at v0.35.0; setup-trivy is safe at the recreated v0.2.6. This is why defenders should verify exactly what ran, not assume a tag reference was trustworthy.
A key lesson from this incident is that mutable action tags are not integrity controls. Many teams reference actions as @v0.x or @v1 because that appears operationally simple, but those references can be redirected. In the Trivy case, malicious code was inserted into trusted automation paths without changing how most workflows looked at first glance. Build jobs can still complete, and teams may interpret successful job status as evidence of safety. That assumption is dangerous when the attacker objective is secret theft rather than immediate service disruption.
The KEV entry describes the possible blast radius in practical terms: compromise of CI/CD tokens, SSH keys, cloud credentials, database passwords, and sensitive configuration in memory. In most mid-market environments, these secrets connect to more than one system: container registries, infrastructure-as-code backends, deployment pipelines, and cloud APIs. This turns a development pipeline event into an external attack-surface event very quickly. If leaked credentials allow authenticated access from the internet or partner networks, exploitation can move from build systems into production-facing infrastructure, admin planes, and data stores.
First, establish scope with evidence: where exactly are aquasecurity/trivy-action, aquasecurity/setup-trivy, and Trivy binaries used across repositories, reusable workflows, and self-hosted runner templates. This should include inherited workflow references and copied pipeline snippets, not just direct references in active repositories. Then map execution history for the known risk window around March 19-20 and identify any jobs that used affected tags or binaries. Without this timeline, organizations either underreact and miss compromise paths or overreact and burn time on unnecessary blanket rebuilds.
Second, investigate compromise indicators before you declare containment. Advisories explicitly suggest reviewing for suspicious artifacts such as unexpected repositories named tpcp-docs, unusual outbound patterns from runners, and unauthorized token usage. Even if no clear indicator is found, treat all secrets that were accessible to affected jobs as potentially exposed, because successful exfiltration is not always visible in standard CI logs. The fastest defensible approach is to document scope assumptions, rotate credentials tied to that scope, and preserve logs for deeper review if downstream abuse appears later.
Remediation has two parallel tracks: software integrity and secret integrity. On software integrity, move every affected workflow to known-safe versions and, more importantly, pin actions to full commit SHAs instead of mutable tags. Pinning does not remove all supply-chain risk, but it removes a major class of silent tag redirection. On secret integrity, rotate every credential that could have been read by impacted jobs, including cloud access keys, registry tokens, Git credentials, SSH keys, and deployment service-account secrets. If rotation is staged, track dependency order so old credentials are invalidated quickly.
After immediate containment, run a short hardening cycle focused on runner privilege and segmentation. Separate build identities from production deployment identities, restrict token scope to minimum required permissions, and avoid long-lived static credentials where federation or short-lived tokens are possible. Add controls that detect unexpected outbound communication from runners and unauthorized repository or release operations. Finally, capture evidence of what changed and why. That documentation is not bureaucracy; it is required for reliable post-incident learning and for proving due care to auditors, customers, and leadership.
For DACH and broader European organizations, this incident aligns with a wider governance shift under NIS2-style expectations: boards and management must demonstrate active oversight of cyber risk, including supply-chain dependencies and timely incident handling. A KEV-listed event with confirmed exploitation is exactly the scenario where leadership decisions, not only technical actions, are scrutinized. Even if CISA due dates do not legally apply in your jurisdiction, they provide a practical external urgency marker that can help security teams accelerate change windows and cross-team coordination.
The long-term takeaway is straightforward. Vulnerability management can no longer stop at CVE ingestion and patch backlog metrics. Teams need a joined process that links vulnerability intelligence, CI/CD asset inventory, credential exposure analysis, and external attack-surface monitoring. Run periodic exercises for CI pipeline compromise, require evidence-based closure criteria, and make sure incident communications include both technical and business impact context. Organizations that institutionalize this discipline will handle the next supply-chain event with less uncertainty, less downtime, and fewer governance surprises.
Get a comprehensive threat briefing for your organization — exposures, breached credentials, and actionable recommendations.
CISA has KEV-listed CVE-2026-20131 after active exploitation. Security teams should treat Cisco firewall management exposure as an immediate remediation priority.
Thousands of FortiGate firewalls are still running with factory default credentials. Here's why this keeps happening and what attackers do with that access.
Most organizations don't know what attackers can see. External Attack Surface Management closes this gap — before threat actors exploit it.