| name | fix-security-issue |
| description | Handle CVE/vulnerability reports from security linters (trivy, osv-scanner, etc.). Tries to upgrade first; ignores only when safe and justified. |
| allowed-tools | Read Grep Glob Edit Write Bash WebFetch WebSearch |
| argument-hint | [CVE-ID or vulnerability description] |
| model | sonnet |
Investigate and fix the security issue $ARGUMENTS reported by trivy, osv-scanner, or another security linter.
Step 1 — Research the CVE
Browse the internet to gather full context:
- Visit the CVE URL from the scan output (e.g.
https://avd.aquasec.com/nvd/<cve-id>)
- Check the fixed version, affected component, and attack vector
- Understand the exploit mechanism: what input/behavior triggers the vulnerability?
Step 2 — Locate the vulnerable dependency
Find where the vulnerable package comes from:
- Go binary (e.g.
stdlib): check which linter binary embeds it — the scan output names the file (e.g. usr/bin/actionlint). Find the linter's descriptor in megalinter/descriptors/ and its pinned version.
- Python package: check
pyproject.toml, uv.lock, .config/python/dev/requirements.txt, server/requirements.txt.
- npm package (direct): search descriptors for
npm: blocks containing the package name.
- npm package (transitive): identify the top-level npm package that brings it in, then check its upstream changelog/release notes.
- OS package (Alpine apk): find the descriptor that installs it.
Step 3 — Try to upgrade
Check whether a fixed version is available and reachable:
- For linter binary CVEs (Go stdlib, etc.): check if a newer release of the linter exists that was compiled with a fixed runtime. Look at GitHub releases.
- For Python packages: update the version pin in
pyproject.toml / requirements files, then run uv lock --python 3.12 to regenerate uv.lock.
- For npm packages (direct descriptor): bump the
ARG ..._VERSION= line in the descriptor, then run make megalinter-build.
- For npm packages (transitive): upgrade the parent package to a version whose
package.json lists a fixed transitive version.
- For OS packages: bump the apk package version in the descriptor if pinned.
If an upgrade is possible and available: do it, then stop here. No ignore entry needed.
Step 4 — Assess impact when upgrade is not possible
If no fixed version exists yet (latest release is still affected), analyze whether the vulnerability is exploitable in MegaLinter's context:
Ask:
- How is the vulnerable code path triggered? (e.g. parsing attacker-controlled input, making network requests, running a server)
- Does MegaLinter invoke that code path? Linters run as static analysis tools — they read source files, they do not serve HTTP, process untrusted templates, or accept external network connections.
- What is the actual impact? Consider:
- DoS / resource exhaustion → generally not exploitable in a one-shot CI linter
- Credential theft / data exfiltration → only relevant if the linter makes outbound connections or reads secrets from env
- Arbitrary code execution → serious; check if the attack vector reaches the linter's execution environment
Step 5 — Decide: block or ignore
Stop and warn the user if:
- The vulnerability involves credential theft, secret exposure, or supply-chain compromise
- The attack vector is reachable (e.g. a linter that fetches remote configs or calls an external API)
- The severity is CRITICAL and the exploit mechanism is not ruled out
Add an exception only when the CVE is genuinely not exploitable in MegaLinter's context. Acceptable reasons:
- DoS via crafted input that the linter never receives (e.g.
crypto/tls in a tool that makes no TLS calls)
- Template/injection attack requiring untrusted user-controlled input that MegaLinter never passes
- Server-side vulnerability in a tool used only as a CLI client
- Debug/tooling CVE (e.g.
cilium-bugtool) in a package imported only for its data types
Step 6 — Add the exception
.trivyignore (for trivy findings)
Append to the appropriate section (or create a new one):
# <linter/package>: <one-line explanation of why not exploitable in MegaLinter>
CVE-XXXX-XXXXX
osv-scanner config (for osv-scanner findings)
Check for an osv-scanner config file (e.g. .osv-scanner.toml or osv-scanner.toml) and add an ignore entry following its schema.
General rule
Always include:
- The CVE ID
- A comment naming the affected package and the specific reason it is not exploitable
- A note if the ignore should be revisited (e.g. "remove when releases a version compiled with Go X.Y.Z")
Step 7 — Update CHANGELOG
Do not update CHANGELOG.md for:
- CVE ignore entries — not user-facing
- Linter version bumps — the auto-upgrade workflow owns Linter versions upgrades
If you made a real behavior change (e.g. a linter disabled due to a security incident, a config workaround added), add one line under Fixes in the beta section:
- Fix <linter/component>: <what changed and why, one sentence for users>
