PVD-20260906-3982: Trivy Implicit Rego Policies Can Disclose Secrets and Make Arbitrary HTTP Requests

Summary

Trivy loads trivy.yaml from its current working directory by default. In an untrusted repository checkout, that file can select an attacker-controlled custom Rego check. Trivy exposes its complete process environment through opa.runtime().env, while the embedded OPA evaluator permits http.send without an application-level network allowlist.

The policy can place environment values in scan output or send them to an attacker-selected HTTP endpoint. It can also reach loopback and internal services and issue HTTP over accessible Unix-domain sockets. This is a Trivy configuration trust-boundary issue, not an OPA vulnerability.

Reporter assessment: Medium.
Upstream report: GHSA-jf88-287j-qwvv (closed, unpublished).
Behavior present: Source history indicates Trivy 0.30.0 onward, including 0.75.0. The proof of concept was run against 0.74.0.

A repository contributor can use checkout-local configuration to load a policy that reads CI tokens, cloud or registry credentials, signing material, proxy credentials, and internal service addresses available to the Trivy process. The demonstrated policy disclosed a harmless canary through both an ordinary finding and a loopback-only HTTP request.

The same primitive can perform server-side requests to services reachable from the runner. If the Trivy process already has access to a Docker, Podman, or other privileged local socket, custom Rego can call that API; it does not bypass the socket's operating-system permissions.

Aqua Security closed the report as out of scope, explaining that Trivy treats its configuration and selected custom checks as trusted. Aqua recommends an absolute, pipeline-owned --config and policies from trusted sources when scanning untrusted content.

Trivy 0.75.0, released 2026-10-01, now documents that custom checks can access environment variables and make HTTP requests. It also supports --config="" to disable configuration-file loading. The environment and network capabilities remain available by design, and the default still loads checkout-local trivy.yaml; there is no patched release or CVE for this report.

On 2026-10-05, Aqua maintainer Dmitriy Lewen confirmed that publication did not need to be held and asked that Aqua's assessment be represented accurately. Aqua also emphasized that practical impact remains bounded by the calling job's existing permissions. We appreciate Aqua's clear public response and the added guidance.

• Pass an absolute path to a read-only, pipeline-owned configuration outside the checkout and use only trusted policy paths.
• With Trivy 0.75.0 or later, use --config="" when no configuration is needed. Also consider --ignorefile="" and --secret-config="" to exclude other checkout-controlled configuration.
• Remove credentials Trivy does not need, restrict egress, and do not expose privileged sockets to scans of untrusted content.
• Use an unprivileged, disposable runner and start Trivy from a trusted directory.

This was found while implementing native Ada/Alire dependency inventory and SBOM support in Trivy for use by Pragmatic Scanner. Pragmatic Scanner itself did not detect the issue. The related feature work is described in Trivy discussion #11244.

• Aqua's public disclosure and out-of-scope response.
• Trivy 0.75 configuration security considerations.
• Trivy 0.75 custom-check security considerations.
• Trivy PR #11278: clarify custom-check security considerations.
• Trivy 0.75 OPA runtime environment construction.
• Trivy 0.75 custom-policy capabilities.

• 2026-09-06: Behavior reproduced and privately reported to Aqua Security.
• 2026-09-21: Aqua closed the report as out of scope, merged custom-check security guidance, and the PVD record was reserved.
• 2026-10-01: Trivy 0.75.0 shipped the new guidance and --config="" mitigation.
• 2026-10-05: Aqua publicly confirmed its assessment and that publication need not be delayed.