Terrascan's SSRF Bug Lets Attackers Pivot Through Your IaC Scanner

Your IaC Scanner Is Now an Attack Surface

If you're running Terrascan in server mode — which is how most CI/CD integrations work — you've got a high-severity SSRF sitting in your infrastructure right now. CVE-2026-47356 (CVSS 7.5) lets an attacker abuse the webhook_url parameter to make your Terrascan server send arbitrary requests to internal services. That's not a theoretical risk. That's cloud metadata endpoints, internal APIs, and anything else reachable from wherever you deployed your scanner.

The irony of a security tool becoming the vulnerability is not lost on me.

What Happened

Terrascan versions v1.18.3 and prior have an SSRF vulnerability in the file scan endpoint:

POST /v1/{iac}/{iacVersion}/{cloud}/local/file/scan

When running in server mode, this endpoint accepts a webhook_url parameter that tells Terrascan where to send scan results. The problem: there's no validation on that URL. An attacker can point it at http://169.254.169.254/latest/meta-data/ or any internal service, and Terrascan will happily make the request on their behalf.

This is textbook SSRF. The server trusts user-supplied URLs without checking whether they resolve to internal/private IP ranges.

Why This Is Worse Than It Looks

Let me paint the picture of where Terrascan typically lives:

• Inside your CI/CD pipeline network
• With access to cloud metadata services
• Often running with elevated permissions (it needs to pull modules, access registries)
• Behind your firewall, trusted by other internal services

That's the perfect pivot point. An attacker who can reach your Terrascan server endpoint — maybe it's exposed for PR scanning webhooks, maybe there's another vulnerability upstream — can now use it as a proxy into your internal network.

In AWS, that means hitting the instance metadata service for IAM credentials. In Kubernetes, that means probing the kubelet API or the metadata endpoint. In any cloud, that means mapping internal services that should never be reachable from outside.

The CVSS score of 7.5 feels about right for the base case, but in a poorly segmented network? This is a full compromise waiting to happen.

Who's Affected

You're vulnerable if:

1. You run Terrascan in server mode (the terrascan server command)
2. You're on version v1.18.3 or earlier
3. The server endpoint is reachable by untrusted clients (or anything that's been compromised)

If you only use Terrascan as a CLI tool in your pipeline (no server mode), you're not affected by this specific CVE. But if you've set up the server for centralized scanning — which is the recommended architecture for larger teams — you need to act.

What To Do Right Now

1. Check if you're running server mode

# Check running processes
ps aux | grep "terrascan server"

# Check your docker-compose or k8s manifests for server mode
grep -r "terrascan server" /path/to/your/deployment/

2. Network-level mitigation (immediate)

While you wait for a patched version or plan your upgrade, restrict outbound traffic from your Terrascan server:

# Example: Kubernetes NetworkPolicy to block metadata and internal ranges
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: terrascan-egress-restrict
spec:
  podSelector:
    matchLabels:
      app: terrascan
  policyTypes:
    - Egress
  egress:
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 169.254.169.254/32  # AWS metadata
              - 10.0.0.0/8          # Internal RFC1918
              - 172.16.0.0/12
              - 192.168.0.0/16
              - 100.64.0.0/10       # CGNAT range

3. Upgrade or patch

Check for a version newer than v1.18.3 that addresses this. If your version is pinned (and it should be), bump it. If no patch is available yet, consider whether you actually need server mode or if CLI-mode scanning in your pipeline is sufficient.

4. Audit your webhook configurations

If you have a reverse proxy in front of Terrascan, add URL validation there:

# At minimum, log all requests to the scan endpoint for audit
location ~ ^/v1/.*/local/file/scan$ {
    access_log /var/log/nginx/terrascan-scan-audit.log;
    proxy_pass http://terrascan-backend;
}

Better yet, if you control the webhook destinations, allowlist them at the proxy layer.

The Bigger Pattern

This is part of a trend I keep seeing: security tools deployed with implicit trust and zero hardening. We treat scanners, SAST tools, and policy engines as trusted infrastructure, but they're software with bugs like everything else. They often have broad network access and elevated permissions — making them high-value targets.

My rule: treat your security tooling with the same zero-trust posture you apply to everything else. Segment it. Restrict its egress. Monitor its outbound connections. Don't let it talk to your metadata service.

If you're running any scanning tool in server mode, go check its egress rules today. Terrascan isn't the last security tool that'll have an SSRF.