Trivy CVE-2026-104994

Exploitation requires a specific operational pattern: Trivy misconfiguration ('misconf'/config) scanning must be run against untrusted input - concretely, a third-party Terraform configuration such as one submitted in an external pull request - AND sensitive data must reside at a pathname above the scan root that the attacker can reference. The attacker leverages Terraform filesystem functions (file(), filebase64(), fileexists(), and related file-reading functions) with a relative path like '../shared/secret' that escapes the scanned directory, and the disclosed value must then appear within scan output visible to the adversary. Limiting factors that reduce realistic risk: the attack only works where Trivy is run on attacker-controlled configs (not when scanning trusted first-party code), the sensitive file must already exist at a guessable traversal path outside the scan root (AC:H), impact is confined to disclosure of that file's contents (C:L, no integrity/availability impact), and it affects only Trivy versions before 0.71.0.

All exploitation signals point to a low-priority issue. The CVSS 3.1 base score is only 2.5 (Low), driven by AV:L (the attack triggers when Trivy processes a file locally/in CI rather than over the network), AC:H (success requires sensitive data to exist at a predictable pathname above the scan root and a config crafted to reach it), PR:L, and impact limited to C:L with no integrity or availability effect (I:N/A:N). No EPSS score was supplied, so exploitation probability cannot be quantified; this is a data gap rather than a low score. The vulnerability is NOT in CISA KEV and no proof-of-concept was provided - so this is 'no public exploit identified at time of analysis.' The signals are internally consistent (low severity, information-disclosure-only, high-complexity, non-default attack path) and nothing conflicts, so there is no high-CVSS-but-low-risk tension here - it is simply a genuinely low-risk, narrowly-scoped information-disclosure bug. The one factor that could elevate real-world concern is the specific usage pattern: organizations that run Trivy misconfiguration scanning automatically against untrusted third-party pull requests in CI, where secrets may live just outside the scanned subdirectory. Missing data: no EPSS, no KEV, no POC.

An attacker opens a third-party pull request containing a Terraform configuration that calls a filesystem function such as file("../../etc/secret") referencing a sensitive file located above the scan root. When the victim's CI pipeline automatically runs Trivy misconfiguration scanning on the untrusted PR, the function resolves the traversal path and the file's contents are surfaced in the scan output, disclosing the secret to the attacker. No public PoC was provided, and exploitation depends on sensitive data existing at a reachable path (AC:H).