CVE-2025-61916: 
Java vulnerability analysis and mitigation

CVE-2025-61916 is a Server-Side Request Forgery (SSRF) vulnerability in Spinnaker, the open-source multi-cloud continuous delivery platform maintained by the Linux Foundation. It affects the io.spinnaker.clouddriver:clouddriver-artifacts Maven package in versions prior to 2025.1.6, 2025.2.0–2025.2.3 (exclusive), and all versions prior to 2025.3.0. The vulnerability was published and disclosed on January 5, 2026, with patches released the same day. It carries a CVSS v3.1 base score of 7.9 (High) per the GitHub Advisory, though NVD records 6.6 (Medium) with a different vector (GitHub Advisory, Spinnaker Advisory).

The root cause is improper input validation (CWE-20) in Spinnaker's artifact-fetching mechanism, which fails to restrict user-supplied URLs before making server-side HTTP requests (CWE-918), and may transmit authentication credentials to unintended endpoints (CWE-523). Exploitation requires two conditions to be met simultaneously: (1) an artifact provider that accepts user-controlled URLs must be enabled — such as GitHub file artifacts, BitBucket, GitLab, or HTTP artifact providers — and (2) a downstream system capable of consuming artifact output must be present, such as Rosco (Helm) or Kubernetes account manifests. When the HTTP artifact provider is enabled alone, it introduces a "no-auth" HTTP provider that can be used to reach link-local addresses (e.g., http://169.254.169.254/ for AWS IMDSv1 metadata). Depending on the artifact type configured, authentication headers (e.g., GitHub tokens) may be forwarded to attacker-controlled endpoints (GitHub Advisory, Spinnaker Advisory).

Successful exploitation allows authenticated Spinnaker users with low privileges to exfiltrate sensitive data including AWS IMDSv1 instance metadata, internal Spinnaker API responses, and authentication credentials such as GitHub auth headers. Fetched data can be injected into Spinnaker pipelines via Helm values or Kubernetes manifests, enabling further lateral movement within the CI/CD environment. Additionally, artifact fetch references pointing to infinite data streams can be used to conduct denial-of-service attacks against internal Spinnaker services, though this does not result in persistent compromise (GitHub Advisory, Spinnaker Advisory).

1. Reconnaissance: Identify a Spinnaker installation with an artifact provider that accepts user-supplied URLs enabled (e.g., HTTP artifact provider, GitHub file artifacts, BitBucket, or GitLab artifacts).
2. Identify a consumer: Confirm that a downstream system capable of consuming artifact output is configured — such as Rosco (Helm) for values files or a Kubernetes account that processes JSON manifests.
3. Craft a malicious artifact URL: Construct a pipeline or artifact reference pointing to an internal target, such as http://169.254.169.254/latest/meta-data/ (AWS IMDSv1) or an internal Spinnaker API endpoint (e.g., http://gate:8084/applications).
4. Inject via pipeline: Submit the crafted artifact URL through a Spinnaker pipeline stage (e.g., a Helm bake stage using a remote values file URL), causing the Spinnaker server to fetch the target URL server-side.
5. Exfiltrate data: Retrieve the response data — which may include cloud instance metadata, internal API responses, or forwarded authentication headers — from the pipeline output or by directing the artifact fetch to an attacker-controlled server to capture forwarded credentials (GitHub Advisory, Spinnaker Advisory).

• Network: Outbound HTTP requests from Spinnaker's clouddriver service to link-local addresses (e.g., 169.254.169.254) or unexpected internal endpoints; outbound requests to attacker-controlled external URLs originating from the Spinnaker backend.
• Logs: Clouddriver application logs showing artifact fetch requests to unusual or internal URLs (e.g., http://169.254.169.254/, http://gate:8084/); pipeline execution logs referencing remote artifact URLs not matching approved domains.
• Pipeline Activity: Spinnaker pipeline configurations containing HTTP artifact references with non-standard or internal IP addresses/hostnames as artifact URLs; unexpected Helm bake stages or Kubernetes manifest stages consuming artifacts from external or link-local URLs.

Upgrade the io.spinnaker.clouddriver:clouddriver-artifacts package to patched versions: 2025.1.6, 2025.2.3, or 2025.3.0 (or later). As a workaround where upgrading is not immediately feasible, disable HTTP artifact account types that allow user input of arbitrary URLs. Git, Docker, and other artifact providers with explicit, administrator-controlled URL configurations are safer alternatives. Additionally, OPA (Open Policy Agent) policies from Spinnaker vendors can be used to restrict pipelines from saving or executing configurations with invalid or unauthorized artifact URLs. Setting strict HTTP timeout and size limits is also recommended to mitigate potential DoS abuse (GitHub Advisory, Spinnaker Advisory).

The vulnerability was reported by security researchers jake-ciolek and CodeWobbler, with remediation developed by jasonmcintosh and reviewed by Jaimeoby from the Spinnaker project. Brief coverage appeared on TheHackerWire and Infosec Exchange shortly after disclosure, but no significant broader media coverage or notable researcher commentary beyond the advisory itself has been observed (GitHub Advisory).