Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-33634 is a critical-severity Embedded Malicious Code (CWE-506) vulnerability in Litellm Litellm. Its CVSS base score is 9.4 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Embedded Payloads (T1027.009); ranked in the top 1.0% of CVEs by exploit likelihood; CISA has added it to the Known Exploited Vulnerabilities catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SC-44 (Detonation Chambers) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-33634 is a supply chain compromise affecting Trivy, an open-source security scanner, stemming from a threat actor's use of compromised credentials to publish a malicious Trivy version 0.69.4 release on March 19, 2026. The attack also involved force-pushing 76 of 77 version tags in the aquasecurity/trivy-action GitHub Action (versions 0.0.1 through 0.34.2) to credential-stealing malware and replacing all 7 tags in the aquasecurity/setup-trivy GitHub Action (versions 0.2.0 through 0.2.6, prior to recreation of 0.2.6 with a safe commit). This incident continues a supply chain attack that began in late February 2026, exacerbated by non-atomic credential rotation after an initial March 1 disclosure, allowing the attacker to exfiltrate newly rotated secrets. Affected components include the aquasecurity/trivy Go binary and container image at version 0.69.4.
Users integrating the affected Trivy components into CI/CD pipelines, particularly those referencing version tags rather than commit SHAs in GitHub Actions workflows, could unwittingly execute the credential-stealing malware. An attacker with low-privilege access (PR:L) could exploit this over the network (AV:N) with low complexity (AC:L) and no user interaction (UI:N), achieving high confidentiality, integrity, and availability impacts (CVSS 8.8). Exploitation enables theft of secrets accessible to the compromised pipelines, with a fallback exfiltration mechanism potentially creating a repository named tpcp-docs in the victim's GitHub organization as an indicator of successful compromise.
Advisories recommend immediate rotation of all secrets accessible to affected pipelines if there's any chance a compromised version was pulled or executed, removal of affected artifacts, and review of workflows using aquasecurity/trivy-action or aquasecurity/setup-trivy. Organizations should verify whether Trivy v0.69.4 was obtained from any source, check workflow run logs from March 19–20, 2026 for signs of compromise if version tags were used, and pin GitHub Actions to full, immutable commit SHA hashes instead of mutable tags. Known safe versions include Trivy 0.69.2 and 0.69.3, trivy-action 0.35.0, and setup-trivy 0.2.6 (recreated).
This vulnerability saw real-world exploitation on March 19, 2026, as part of an ongoing supply chain campaign, with detailed discussions available in Aquasecurity's GitHub advisories and related security notices.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-14601
Vulnerability Data
Trivy is a security scanner. On March 19, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.4 release, force-push 76 of 77 version tags in `aquasecurity/trivy-action` to credential-stealing malware, and replace all 7 tags in `aquasecurity/setup-trivy`…
more
with malicious commits. This incident is a continuation of the supply chain attack that began in late February 2026. Following the initial disclosure on March 1, credential rotation was performed but was not atomic (not all credentials were revoked simultaneously). The attacker could have use a valid token to exfiltrate newly rotated secrets during the rotation window (which lasted a few days). This could have allowed the attacker to retain access and execute the March 19 attack. Affected components include the `aquasecurity/trivy` Go / Container image version 0.69.4, the `aquasecurity/trivy-action` GitHub Action versions 0.0.1 – 0.34.2 (76/77), and the`aquasecurity/setup-trivy` GitHub Action versions 0.2.0 – 0.2.6, prior to the recreation of 0.2.6 with a safe commit. Known safe versions include versions 0.69.2 and 0.69.3 of the Trivy binary, version 0.35.0 of trivy-action, and version 0.2.6 of setup-trivy. Additionally, take other mitigations to ensure the safety of secrets. If there is any possibility that a compromised version ran in one's environment, all secrets accessible to affected pipelines must be treated as exposed and rotated immediately. Check whether one's organization pulled or executed Trivy v0.69.4 from any source. Remove any affected artifacts immediately. Review all workflows using `aquasecurity/trivy-action` or `aquasecurity/setup-trivy`. Those who referenced a version tag rather than a full commit SHA should check workflow run logs from March 19–20, 2026 for signs of compromise. Look for repositories named `tpcp-docs` in one's GitHub organization. The presence of such a repository may indicate that the fallback exfiltration mechanism was triggered and secrets were successfully stolen. Pin GitHub Actions to full, immutable commit SHA hashes, don't use mutable version tags.
- CWE(s)
- KEV Date Added
- 26 March 2026
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 3 hardening rules · 2 OS baselines
—
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover embedded malicious code before release.
Detonation chambers can reveal embedded malicious code through controlled execution analysis.
Integrity verification tools directly detect unauthorized or malicious code insertions.
Tamper-resistance and detection mechanisms identify malicious code introduced via the supply chain.
Component authenticity requirements reduce the chance malicious code is embedded by developers or suppliers.
Component authenticity controls stop introduction of malicious or counterfeit code into the product.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Assessing authenticity and integrity before acquisition catches embedded malicious code.
Secure SDLC practices directly prevent introduction of malicious code during development.
Due diligence prior to supplier relationships helps avoid sources of embedded malicious code.
Supplier risk assessment reduces likelihood of receiving products containing malicious code.
Pre-acquisition assessment of critical suppliers mitigates risk of malicious code in procured software.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Requiring suppliers to furnish component lists, attestations, and cryptographic verification of delivered artefacts makes it harder for an attacker to embed hidden malicious code that would otherwise go undetected through the supply chain.
Checks that executed code has not been tampered with and monitoring for malware-associated activity reduce the likelihood that hidden malicious code remains active.
Banning unapproved or unknown software and requiring testing plus authorization reduces the chance that hidden malicious code will be introduced into production environments.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
Oracle Linux 9 (1 rule)
- V-271452 OL 9 must use a Linux Security Module configured to enforce limits on system services. prevents CWE-506
RHEL 9 (1 rule)
- V-258078 RHEL 9 must use a Linux Security Module configured to enforce limits on system services. prevents CWE-506