HowToFixMe
● Critical · CVSS 4.0 = 9.3

CVE-2026-47357: unauthenticated SSRF to local file read in archived Terrascan

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 4.0 base 9.3 (Critical); CVSS 3.1 base 7.5 (High)
CVSS 3.1 vectorAV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Exploitation statusSSVC Exploitation: none. Not on CISA KEV. SSVC marks it Automatable: yes
AffectedTerrascan, all versions <= 1.18.3 (defaultStatus affected)
Fixed inNo fix. Project archived August 2023, no patch will be released
Type (CWE)CWE-918 (SSRF), CWE-610, CWE-73
Reported byTristan Madani (@TristanInSec), Talence Security; published 2026-05-19

Exploitation status

As of the CVE record, CISA's SSVC assessment lists Exploitation: none, and CVE-2026-47357 is not on the Known Exploited Vulnerabilities catalog. The same SSVC block flags Automatable: yes with Technical Impact: partial, which is the part worth your attention: a single unauthenticated HTTP POST triggers the bug, so it scripts cleanly at internet scale once anyone bothers. "None" here means no confirmed in-the-wild abuse on record, not "safe".

The CVE's only reference is the archived Terrascan GitHub repository. There is no Metasploit module cited, but the exploitation primitive is trivial: stand up an HTTP server that answers with an X-Terraform-Get header pointing at a file:// path, then point a vulnerable Terrascan server at it. Researcher Tristan Madani (@TristanInSec, Talence Security) documented the chain, so a working proof of concept exists in the wild even if it is not packaged as a module.

What is CVE-2026-47357?

CVE-2026-47357 is an unauthenticated server-side request forgery in Terrascan, the open-source infrastructure-as-code (IaC) static scanner originally maintained by Tenable. It affects every version up to and including 1.18.3, and only matters when Terrascan runs in server mode (terrascan server), which binds to 0.0.0.0 with no authentication.

The vulnerable endpoint is the remote directory scan: POST /v1/{iac}/{iacVersion}/{cloud}/remote/dir/scan. When you send that request with remote_type set to "http", the remote_url parameter is handed straight to hashicorp/go-getter (v1.7.5) with no validation. That single missing validation step is the whole bug, and it opens two distinct doors.

Door one: go-getter's HttpGetter honors the X-Terraform-Get response header. An attacker's web server can answer the scan request with that header pointing at a file:// URL, redirecting go-getter into reading a local file off the Terrascan host. Door two: HttpGetter ships with Netrc set to true, so it reads ~/.netrc on the host and sends any stored credentials to whatever hostname the attacker supplies. That is straight credential exfiltration with one HTTP request.

Why this CVE matters

This one is worse than the bare "SSRF" label suggests, and the reason is the no-fix status. Tenable archived Terrascan in August 2023. The CVE record says it plainly: no patch will be released. So unlike most SSRFs where you upgrade and move on, here the upgrade path does not exist. You either stop running server mode or you accept the exposure.

The CVSS 3.1 base is 7.5 (High) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: network-reachable, low complexity, no privileges, no user interaction, high confidentiality loss, zero integrity or availability impact. The CVSS 4.0 reassessment pushes it to 9.3 (Critical), largely because the 4.0 model credits the subsequent-system confidentiality impact (SC:H) from the credential leak. Read together, the picture is a pure read primitive that is dead simple to fire and reaches secrets the box can see.

If a Terrascan server was ever internet-reachable, assume someone could have pulled ~/.netrc and any readable secrets. The remediation is not just "stop the service"; you also rotate whatever credentials lived in .netrc and any local files an SSRF could have reached.

Am I affected?

You are affected if you run any Terrascan version <= 1.18.3 and you start it in server mode. The binary used as a one-shot CLI scanner (terrascan scan ...) does not open the vulnerable HTTP listener, so the practical exposure is the terrascan server path specifically.

Check the version with the binary's own subcommand:

# Terrascan ships as a single Go binary. Ask it directly:
terrascan version

# If it's running in a container:
docker run --rm tenable/terrascan:latest version

# Find any server-mode process actually listening (this is the dangerous one):
ps aux | grep -i "terrascan server"
# Terrascan server defaults to port 9010 on 0.0.0.0; check what's bound:
ss -tlnp | grep -E ':9010|terrascan'

If terrascan version returns 1.18.3 or lower (every released version qualifies) and you see a terrascan server process bound to 0.0.0.0, you are exposed. Because no fixed version was ever published, do not waste time hunting for a "safe" build, because there isn't one.

How to fix CVE-2026-47357

There is no patch. Terrascan was archived by Tenable in August 2023 and the CVE record states no fix will be released. So "fixing" this means removing the exploitable surface, rotating anything that may have leaked, and migrating off Terrascan server mode. Here is the order I would work it.

  1. Stop server mode now. Kill the terrascan server process. This is the only path that opens the unauthenticated HTTP listener; the offline CLI scanner is not affected.
  2. Block reachability to the listener (default port 9010) at the host firewall or security group while you plan migration.
  3. Rotate credentials. Any secrets in ~/.netrc on the host, plus any tokens or keys stored in local files the host could read, should be treated as potentially exfiltrated and rotated.
  4. Migrate remote-scan workflows to a maintained IaC scanner (Checkov, tfsec/Trivy, KICS) so you keep the capability without the dead, vulnerable binary.
  5. Confirm no terrascan server instance comes back through automation, container restarts, or a CronJob.

Stop and remove the server-mode listener

Terrascan is a single Go binary, not an apt/dnf/npm/pip package, so you remove it the way you installed it: delete the binary, pull the container, or scale the workload to zero. The commands below cover the common install methods.

# 1. Find and stop the server-mode process
pkill -f "terrascan server" || true
ss -tlnp | grep ':9010'   # confirm nothing is still listening

# 2a. Binary install (GitHub release / Homebrew): remove it
which terrascan            # e.g. /usr/local/bin/terrascan
sudo rm -f /usr/local/bin/terrascan
brew uninstall terrascan 2>/dev/null || true   # if installed via Homebrew

# 2b. Container: stop and remove the running container
docker ps --filter "ancestor=tenable/terrascan" -q | xargs -r docker stop
docker ps -a --filter "ancestor=tenable/terrascan" -q | xargs -r docker rm

# 2c. Kubernetes: scale the deployment to zero (or delete it)
kubectl scale deployment/<terrascan-deployment> --replicas=0
kubectl get pods -l app=terrascan   # confirm none remain

If you genuinely must keep it running short-term

Server mode has no auth and no fix, so the only real mitigations are reachability controls. None of these patch the bug; they shrink who can reach it.

# Bind the listener away from 0.0.0.0 is NOT supported as a flag in archived builds,
# so put network controls in front instead.

# Host firewall: allow only a trusted CI runner to reach port 9010
sudo iptables -A INPUT -p tcp --dport 9010 -s <trusted-ci-ip> -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 9010 -j DROP

# Remove the .netrc credential-leak primitive: blank/rename the file the
# vulnerable HttpGetter reads (after migrating any tooling that needs it)
[ -f "$HOME/.netrc" ] && mv "$HOME/.netrc" "$HOME/.netrc.disabled"

# Egress filtering: deny the host's outbound HTTP to anything but known mirrors,
# so the X-Terraform-Get / netrc callback cannot reach attacker servers.

Migrate to a maintained scanner

# Checkov (Python) - maintained, broad IaC coverage
pip install checkov && checkov -d ./your-iac-dir

# Trivy (includes the former tfsec engine) - maintained, single binary
trivy config ./your-iac-dir

# KICS - maintained, container-friendly
docker run -t -v "$PWD":/path checkmarx/kics:latest scan -p /path

If you cannot remove it immediately

Because there is no patch, "cannot fix immediately" is the default state, not the exception. Treat the server-mode listener as a no-auth file-read endpoint exposed to whoever can route to it. Get it off any internet-facing interface today: firewall port 9010 down to a single trusted source, neutralize ~/.netrc on the host, and add outbound filtering so the SSRF callback cannot phone home. Then schedule the migration; these are stopgaps, not a fix.

How to confirm the exposure is gone

Since there is no version to confirm, verification here means proving the listener is dead and the SSRF endpoint no longer answers. Run these from a host that previously could reach it.

# 1. No process listening on the server-mode port
ss -tlnp | grep ':9010' || echo "OK: no terrascan server listening"

# 2. The vulnerable endpoint should refuse the connection (not 200/4xx)
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST "http://<host>:9010/v1/terraform/v14/aws/remote/dir/scan" \
  || echo "OK: connection refused"

# 3. Confirm the binary/container/deployment is gone
which terrascan || echo "OK: binary removed"
docker ps --filter "ancestor=tenable/terrascan" | grep -q terrascan \
  && echo "STILL RUNNING" || echo "OK: no container"

If the server was internet-reachable at any point, treat log review as part of the remediation, not an optional follow-up. The tells for this specific bug are POSTs to /v1/.../remote/dir/scan with a remote_type of http pointing at an unfamiliar host, followed by outbound HTTP from the Terrascan box to that host. Any file the process could read, and anything in .netrc, should be assumed disclosed.

Frequently asked questions

Is there a patch for CVE-2026-47357?

No. Tenable archived the Terrascan project in August 2023, and the CVE record states no patch will be released. Every version up to and including 1.18.3 is affected with no fixed version. The durable fix is to stop running terrascan server and migrate to a maintained IaC scanner.

Does CVE-2026-47357 require authentication?

No. The terrascan server process binds to 0.0.0.0 with no authentication, so any remote attacker who can reach the port can hit the POST /v1/{iac}/{iacVersion}/{cloud}/remote/dir/scan endpoint. The CVSS 3.1 vector confirms it: AV:N/AC:L/PR:N/UI:N means network, low complexity, no privileges, no user interaction.

What can an attacker actually read with this SSRF?

Two things. By returning an X-Terraform-Get header that redirects to a file:// URL, the attacker makes hashicorp/go-getter read local files off the Terrascan host. Separately, go-getter's HttpGetter has Netrc enabled, so it reads ~/.netrc and sends any stored credentials to the attacker-controlled hostname. Impact is confidentiality only (C:H/I:N/A:N): no write or crash.

I only use the Terrascan CLI scanner. Am I exposed?

The exploitable surface is server mode specifically. A one-shot terrascan scan run does not open the unauthenticated HTTP listener. That said, the binary is dead software with no security maintenance, so migrating off it is still the right call.

Related weaknesses in the same component worth addressing at the same time:

References

This guide is grounded in the MITRE CVE record for CVE-2026-47357 (assigned by Tenable, published 2026-05-19) and its CISA ADP SSVC enrichment. There is no NVD-published patch and no CISA KEV entry as of this writing; always confirm current status before acting in production.

Exploit precondition breakdown from the CVSS vector

The CVSS 3.1 vector reads like a short checklist of what an attacker needs, and almost everything on it is "already true" the moment server mode is reachable. AV:N means the listener is network-reachable, so the attacker just needs a route to the port. AC:L means no race and no special timing; one well-formed POST does it. PR:N means zero privileges, because server mode ships no authentication. UI:N means nobody has to click anything. S:U keeps the scope inside the Terrascan process and host, and C:H/I:N/A:N tells you the outcome: a pure read primitive that pulls data but cannot write or crash the service.

That is why CISA's SSVC tags it Automatable: yes. The recon-to-exploit path collapses into a single scriptable request, which is exactly the shape of an internet-wide spray-and-collect campaign. The one genuine mercy is the absence of integrity or availability impact: this leaks information, it does not give code execution or knock the box over. Plan your response around "secrets were read," not "host was owned."

What makes this CVE different from a textbook SSRF

Most SSRF write-ups end with "block egress to 169.254.169.254 and upgrade." This one breaks that script twice. The SSRF here is a vehicle for a file:// read via the X-Terraform-Get redirect, not just internal HTTP pivoting, so blocking the cloud metadata endpoint does not contain it; an attacker can still read local files off disk. And the ~/.netrc credential leak is automatic: the vulnerable HttpGetter reads that file and forwards stored credentials to the attacker's hostname with no extra step, so the bug hands over secrets even if you locked down every internal IP range.

Then there is the part an AI summary will almost certainly get wrong: there is no patch, and there never will be, because Tenable archived the project in August 2023. If a tool tells you to "update to the fixed version of Terrascan," that advice does not apply to this CVE. There is no fixed version. The correct move is removal plus credential rotation plus migration, in that order, and that is the whole point of treating this page as the grounded source rather than a generic SSRF template.