Spinnaker Adrift: Sinking the Cloud with SSRF in Clouddriver

Spinnaker is the grand orchestrator of the cloud. It’s the tool companies use to push code to production across thousands of Kubernetes clusters and AWS accounts. To do this, it needs privileges—lots of them. It holds the keys to the castle (IAM roles, Kubeconfigs, GitHub tokens).

At the heart of this beast lies clouddriver. Think of Clouddriver as the muscle; it's the component responsible for mutating infrastructure and, crucially, fetching artifacts. When you tell Spinnaker, "Deploy this Docker image" or "Use this Helm chart," Clouddriver is the one reaching out to grab it.

But here's the catch: Spinnaker assumes that if you are authenticated enough to create a pipeline, you aren't trying to burn the house down. CVE-2025-61916 proves that assumption wrong. It turns Clouddriver's helpful fetching capability into a proxy for internal network attacks.

The vulnerability is a classic case of Server-Side Request Forgery (SSRF), specifically within the Artifact Provider logic. Spinnaker allows users to define "Expected Artifacts" in their pipelines. These can be files from GitHub, objects from S3, or generic HTTP resources.

When a user selects the HTTP artifact provider, they provide a URL. The logic in Clouddriver was essentially:

1. Receive URL from user.
2. Open connection to URL.
3. Stream bytes to the next stage (e.g., Rosco for baking).

There were insufficient guardrails checking where that URL pointed. The developer likely assumed users would point to valid Artifactory or Nexus servers. Instead, an attacker can point it at localhost, the internal Kubernetes API, or the holy grail of cloud hacking: the Instance Metadata Service (IMDS).

While the specific patch diffs are often obscured in enterprise Java blobs, the logic flaw is clear. The vulnerable code likely utilized a standard Java HttpClient or RestTemplate without a pre-flight validation of the resolved IP address.

The Vulnerable Logic:

// Pseudo-code of the flaw
public InputStream fetchArtifact(String artifactUrl) {
    // Trusting the user input implicitly
    URL url = new URL(artifactUrl);
    return url.openStream();
}

The Fix Logic: The remediation involves implementing a strict allowlist or a deny-list for sensitive ranges (RFC 1918, link-local). The patched versions likely introduce a network interceptor that resolves the DNS hostname before the connection is established and checks it against a blocklist.

// Pseudo-code of the fix
public InputStream fetchArtifact(String artifactUrl) {
    URL url = new URL(artifactUrl);
    InetAddress ip = InetAddress.getByName(url.getHost());
    
    if (isLinkLocal(ip) || isLoopback(ip) || isPrivate(ip)) {
        throw new SecurityException("Access to internal network denied");
    }
    return url.openStream();
}

[!NOTE] Proper SSRF mitigation is hard. Just checking strings for "127.0.0.1" isn't enough due to DNS rebinding and redirect chains. The fix must validate the destination IP after DNS resolution but before the HTTP request is sent.

Let's weaponize this. We assume we have access to the Spinnaker UI (a common scenario for developers). We want to steal the AWS IAM credentials of the node running Spinnaker.

Step 1: The Pipeline Create a new pipeline. In the Configuration stage, add an Expected Artifact.

• Type: HTTP
• URL: http://169.254.169.254/latest/meta-data/iam/security-credentials/SpinnakerManagedRole

Step 2: The Consumer We need to see the output. The easiest way is to pass this artifact into a Bake (Manifest) stage using the Rosco component. We configure the Bake stage to use this artifact as a "Values File" for a Helm chart.

Step 3: Execution Trigger the pipeline manually. Clouddriver sees the HTTP artifact, dutifully requests the AWS metadata IP, and downloads the JSON containing the AccessKeyId and SecretAccessKey.

Step 4: Exfiltration Spinnaker will attempt to render the Helm chart using the credentials as values. Even if the rendering fails (because the JSON structure is wrong for Helm), the error logs in the UI often dump the content of the values file to help you debug. There, in plain text in your deployment logs, are the AWS credentials.

The impact here is catastrophic if the Spinnaker instance is running in a cloud environment with attached IAM roles (which it almost always is). The CVSS:3.1/AV:L vector is deceptive—it marks it "Local" because the attacker technically needs privileges within the application, but in a DevOps context, "Local" access is possessed by hundreds of engineers.

The Domino Effect:

1. SSRF Execution: Fetch metadata.
2. Credential Theft: Obtain temporary IAM keys for the Spinnaker node.
3. Lateral Movement: Use those keys to list S3 buckets, describe EC2 instances, or assume other roles.
4. Persistence: If the stolen role has iam:CreateUser or iam:PassRole, the attacker creates a backdoor administrator account.

Furthermore, this can be used to scan the internal network. Attackers can map out other unexposed services (like Redis or unauthenticated admin panels) by brute-forcing artifact URLs and analyzing the response times.

Patching is mandatory. If you are running Spinnaker clouddriver versions prior to 2025.1.6, 2025.2.3, or 2025.0.9, you are exposed.

Immediate Actions:

1. Upgrade: Update clouddriver to a fixed version immediately.
2. IMDSv2: Enforce AWS IMDSv2 (Instance Metadata Service Version 2) on all nodes. IMDSv2 requires a PUT request to get a token before reading metadata. This simple change kills 99% of SSRF exploits because the attacker can usually only force a GET request.
3. Network Policies: Why does Clouddriver need to talk to the internet and the internal network? Use Kubernetes NetworkPolicies or Istio Sidecars to restrict Clouddriver's egress traffic to only known, necessary domains (e.g., github.com, docker.io, and specific cloud APIs). Block access to 169.254.169.254 at the firewall level.