GHSA-mcj4-mphf-j9ff is a high-severity (CVSS 7.5) Path Traversal vulnerability in github.com/aquasecurity/trivy. O3 Security confirms whether GHSA-mcj4-mphf-j9ff is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Trivy has a path traversal via a crafted vulnerability database or other downloaded artifacts
Real-World Exposure
github.com/aquasecurity/trivyReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
When Trivy downloads an OCI artifact, it uses the org.opencontainers.image.title annotation from the artifact manifest as the destination filename without validation. An attacker who can make Trivy fetch an attacker-controlled artifact can supply a crafted annotation that resolves to a path outside the intended destination, causing Trivy to write the layer content to an arbitrary location on the host filesystem.
Affected configurations
Exploitation requires the attacker to direct Trivy at an attacker-controlled OCI artifact via one of the following inputs:
| Input | Used for |
|---|---|
--db-repository flag, TRIVY_DB_REPOSITORY environment variable, or db.repository in trivy.yaml | Vulnerability database |
--java-db-repository flag, TRIVY_JAVA_DB_REPOSITORY environment variable, or db.java-repository in trivy.yaml | Java vulnerability database |
--checks-bundle-repository flag (and the deprecated --policy-bundle-repository alias), TRIVY_CHECKS_BUNDLE_REPOSITORY environment variable, or misconfiguration.checks-bundle-repository in trivy.yaml | Misconfiguration checks bundle |
Repository argument to trivy module install <REPO> | WASM module installation |
Realistic scenarios in which an attacker may influence these inputs include a copy-pasted command or documentation snippet pointing to an untrusted mirror, or a third-party mirror that turns out to be hostile.
Trivy's default configuration, which downloads these artifacts from Aqua-operated repositories, is not affected. The risk applies only when one of the inputs above is overridden to download a different artifact.
Impact
An attacker who satisfies the conditions above can overwrite or create arbitrary files on the host filesystem within the privilege boundary of the user running Trivy. The vulnerability does not grant any privileges beyond what that user already has.
The practical impact depends on the deployment. In environments where the running user can overwrite files such as SSH authorized_keys, shell startup files, cron entries, or binaries on PATH, the file write may be leveraged to achieve code execution as that user. In more restricted deployments, the impact is bounded to the user's writable scope but may still allow tampering with scan results, build artifacts, or other files consumed by subsequent steps in the same pipeline.
Patches
Fixed in Trivy 0.71.1. Users should upgrade to that release or later.
Workarounds
If upgrading is not immediately possible, do not download Trivy artifacts (vulnerability database, Java database, misconfiguration checks bundle, modules, etc.) from OCI repositories you do not operate or trust.
Credits
Reported by @ikkebr.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/aquasecurity/trivy | all versions | 0.71.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/aquasecurity/trivy. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/aquasecurity/trivy to 0.71.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mcj4-mphf-j9ff is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-mcj4-mphf-j9ff is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-mcj4-mphf-j9ff. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-mcj4-mphf-j9ff in your dependencies?
O3 detects GHSA-mcj4-mphf-j9ff across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.