CVE-2025-61916: Spinnaker Pipeline Artifact SSRF

CVE-2025-61916 exposes a critical flaw in the artifact management subsystem of Spinnaker, the open-source continuous delivery platform. The vulnerability is rooted in the clouddriver-artifacts component, which is responsible for resolving and fetching artifacts (files, manifests, images) required during pipeline execution.

Spinnaker pipelines often require external resources—such as Helm chart values files or configuration manifests—to be fetched from version control systems or HTTP endpoints. The system supports various artifact providers, including a generic HTTP provider. In vulnerable configurations, this provider lacks sufficient validation of user-supplied URLs.

An attacker with standard permissions to create or modify pipelines can define a new artifact that points to a sensitive destination, such as the loopback interface (127.0.0.1), internal services within the Kubernetes cluster, or the link-local addresses used by cloud providers for instance metadata (169.254.169.254). Because the request originates from the Clouddriver pod, it bypasses network perimeter firewalls, effectively bridging the external user into the internal trust zone.

The root cause of this vulnerability involves the improper handling of the "no-auth" HTTP artifact account type within Clouddriver. When an HTTP artifact provider is enabled, Spinnaker essentially acts as an open proxy for the pipeline creator, fetching whatever resource is specified in the artifact definition.

The Mechanics of Failure:

1. Unrestricted Input: The system allows users to manually specify the reference (URL) for an artifact without enforcing an allowlist of permitted domains or a blocklist of reserved IP ranges.
2. Implicit Trust: The HTTP provider defaults to a "no-auth" mode that does not perform adequate checks on the destination IP address. This allows the Java-based HTTP client to resolve and connect to restricted ranges like 169.254.0.0/16.
3. Data Consumption: Downstream components, particularly Rosco (the bakery service), often consume these artifacts. For example, if a pipeline contains a "Bake (Manifest)" stage, Rosco will request the artifact content from Clouddriver to use as a values.yaml file. If the artifact points to AWS IMDS, Clouddriver fetches the credentials and passes them to Rosco, where they may be exposed in error logs or rendered into the final manifest.

While specific code diffs are not provided in the disclosure, the architectural flaw lies in the ArtifactController and the HttpArtifactCredentials implementation within Clouddriver.

In the vulnerable logic, the flow proceeds as follows:

1. Request: User submits a pipeline execution request containing an artifact of type http/file with reference http://169.254.169.254/latest/meta-data/.
2. Resolution: Clouddriver identifies the artifact account. If no specific account is configured, it falls back to a default or anonymous HTTP client.
3. Execution: The download method is invoked. The standard Java RestTemplate or OkHttp client executes the GET request.
4. Failure to Validate: Crucially, there is no pre-flight check to verify that the resolved IP address of the target hostname is not within a private CIDR block (RFC 1918) or a reserved range.

The remediation (in versions 2025.1.6+) introduces strict validation logic. The patch likely enforces a requirement that artifact URLs must match a pre-configured allowlist of domains (e.g., github.com, bitbucket.org) or explicitly blocks access to link-local and loopback addresses at the application layer before the socket connection is attempted.

To exploit CVE-2025-61916, an attacker requires authentication and the READ and WRITE permissions necessary to create or trigger pipelines. The exploitation process does not require high privileges (like Admin).

Attack Scenario:

1. Pipeline Configuration: The attacker creates a new pipeline or edits an existing one via the Spinnaker UI or API.
2. Artifact Definition: They define a "Expected Artifact" using the HTTP provider. The URL is set to a sensitive target, such as http://169.254.169.254/latest/meta-data/iam/security-credentials/NodeRole (AWS) or http://metadata.google.internal/computeMetadata/v1/ (GCP).
3. Trigger Mechanism: The attacker configures a stage that consumes this artifact. A logical choice is a "Bake (Manifest)" stage (Helm), configuring the malicious artifact as a "Values File".
4. Execution: The attacker runs the pipeline manually.
5. Exfiltration: Clouddriver fetches the IAM credentials from the metadata service. When the Bake stage runs, these credentials are injected into the Helm rendering process. The attacker can then view the "Produced Artifact" (the rendered manifest) in the UI, which will now contain the stolen AWS credentials in plain text.

The impact of this SSRF is rated High (CVSS 7.9) because it facilitates a scope change (S:C). The vulnerability allows an attacker to breach the logical boundary of the Spinnaker application and interact with the underlying infrastructure.

Consequences:

• Cloud Credential Theft: Access to the Instance Metadata Service (IMDS) allows attackers to steal temporary credentials assigned to the Spinnaker nodes. This often leads to full control over the cloud environment, depending on the IAM role's permissions.
• Internal Reconnaissance: Attackers can port-scan internal services (e.g., databases, Redis, other microservices) by analyzing response times or error messages from the artifact fetcher.
• Information Disclosure: Sensitive internal API endpoints or configuration files hosted on the internal network can be retrieved and displayed to the attacker.

Remediation requires updating the Spinnaker platform to a patched version. The fix introduces stricter URL validation and prevents the implicit trust of the 'no-auth' HTTP provider.

Immediate Actions:

1. Upgrade: Update Spinnaker components to versions 2025.1.6, 2025.2.3, or 2025.3.0.
2. Audit: Review existing pipeline configurations for artifacts using the HTTP provider with suspicious URLs (e.g., IP addresses instead of domains).

Defense-in-Depth: If immediate patching is not feasible, administrators should implement Open Policy Agent (OPA) policies within Spinnaker. An OPA policy can be configured to deny pipeline executions if any artifact URL matches a blocklist of sensitive subnets (169.254.0.0/16, 10.0.0.0/8, 127.0.0.0/8). Additionally, network policies (e.g., Kubernetes NetworkPolicies or Istio Egress rules) should be applied to the Clouddriver pod to restrict outbound connectivity solely to required external domains.