On 14 October 2026 Palo Alto Networks published two advisories for Checkov, the open source infrastructure as code scanner. CVE-2026-0312 covers path traversal flaws that let an unauthenticated local user write files to arbitrary locations on the scanning filesystem. CVE-2026-0311 is a lower severity SSRF that lets requests reach internal services from the scanning host.
Neither is exploited in the wild, according to the vendor, and the scores are modest. The reason to act anyway is where Checkov runs: inside CI, on pull requests, often with cloud credentials and a writable workspace nearby. The vendor's workaround says it plainly: avoid running Checkov on untrusted content.
What's affected
| CVE | Issue | Affected | Fixed | Severity |
|---|---|---|---|---|
| CVE-2026-0312 | Path traversal, arbitrary file write on the scanning host | Before 3.3.25 (the vendor's table lists 3.2.0 through 3.3.24) | 3.3.25 | Medium, CVSS-BT 4.3 (CVSS-B 6.8) |
| CVE-2026-0311 | SSRF from the scanning host to internal services | 3.2.0 through 3.2.532 | 3.2.533 | Low, CVSS-BT 1.1 (CVSS-B 4.8) |
Both advisories say no special configuration is required to be affected. Upgrading to 3.3.25 or later covers both. On PyPI, 3.3.25 was published on 6 October 2026 and the current release at the time of writing is 3.3.29. The vendor notes that Checkov integrations inside Prisma Cloud update automatically, so this is mainly about the copies you install yourself: pip installs, container images, pre-commit hooks and CI actions.
Muhammad Ibrahim and Yuze Pan are credited with reporting CVE-2026-0312.
How to check if you're exposed
Find every place Checkov is pinned. It tends to hide in several layers of a repo.
# Local or runner installs
pip show checkov 2>/dev/null | grep -i '^version'
checkov --version
# Pins in repos you own
grep -rnE "checkov[=~><]*[0-9]" requirements*.txt pyproject.toml poetry.lock 2>/dev/null
grep -rn "checkov" .pre-commit-config.yaml .github/workflows .gitlab-ci.yml Jenkinsfile 2>/dev/null
grep -rn "bridgecrew/checkov" --include=Dockerfile* --include=*.yml --include=*.yaml .
Then answer the exposure question for each pipeline: does it run Checkov on code that someone outside your team controls? Pull requests from forks, public contributions, third party Terraform modules pulled in at scan time and repositories you scan on behalf of customers all count as untrusted content.
The second check is configuration. Checkov's README says that by default it looks for a .checkov.yaml or .checkov.yml file in this order: the directory being scanned, the current working directory, then the user's home directory. If the scanned repo contains that file, the repo is choosing settings for its own scan. The README itself recommends that the config be "loaded from a trusted source composed by a verified identity". You can see where each setting came from:
checkov --show-config
What to do now
- Upgrade to Checkov 3.3.25 or later everywhere you install it yourself. Update pins in requirements files, pre-commit
revvalues and container image tags, not just the runner. - Pass config explicitly. The vendor's mitigation is to supply a trusted config file instead of letting Checkov auto-load one from the scanned directory. When a config path is given on the command line, the README says other config files are ignored:
checkov --config-file /etc/checkov/ci.yaml --directory "$CI_PROJECT_DIR"
Keep that file in a location the pull request cannot modify, such as a separate repo, a base image or a protected path on the runner.
- Isolate scans of untrusted code. Run them in an ephemeral container with no cloud credentials, a read-only mount of the source where possible, and no write access to caches that later jobs reuse.
- Restrict egress from scan jobs so the SSRF in CVE-2026-0311, or anything like it, cannot reach metadata endpoints or internal services.
- Check fork pull request settings. Make sure workflows that run on contributions from forks do not get secrets or write tokens by default.
Why it matters
Security scanners parse hostile input for a living, and they usually run with more trust than the code they inspect. A path traversal in a scanner is a write primitive inside your CI runner, and in CI a write in the right place (a cached dependency, a script a later step executes, a shell profile on a persistent runner) can become code execution in a job that does hold secrets.
The config file detail is the bigger lesson. Any tool that reads its settings from the directory it is scanning hands the scanned party a say in how it is scanned. That includes which checks are skipped and which external checks are loaded. Treat repo-local tool config as untrusted input, the same as the code.
Try it yourself
Pick one pipeline that scans pull requests. Write down three things: the Checkov version it really runs, where its config comes from, and which credentials the job can read. If any answer is "the pull request", you have found the fix to make this week. To check the Python side of your toolchain for known CVEs, drop a requirements.txt into https://gold.safeguard.sh/scan. It runs in the browser, the file never leaves your machine, and no login is needed.
Click through it at your own pace, or open it full screen.
Quick check
Which Checkov version fixes both October 2026 advisories?
Version 3.3.25 or later. CVE-2026-0312 is fixed in 3.3.25 and CVE-2026-0311 was fixed earlier, in 3.2.533.
Where does Checkov look for a config file by default?
In the directory being scanned first, then the current working directory, then the user's home directory, looking for .checkov.yaml or .checkov.yml. Passing an explicit config file path makes it ignore the others.
What is the vendor's workaround if you cannot upgrade yet?
Avoid running Checkov on untrusted content, and pass configuration through an explicit, trusted config file instead of letting it load automatically from the scanned directory.
