dbcve.org
SpinnakerApplication · Linuxfoundation

CVE-2025-61916

MEDIUM · 6.6 CVSS v3.1 Published 2026-01-05
Fix available
A fix is available. Upgrade to 2025.1.6 / 2025.2.3 or later.
See remediation →
68/100
Remediation priority · Elevated
Zero-click

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
Spinnaker is an open source, multi-cloud continuous delivery platform. Versions prior to 2025.1.6, 2025.2.3, and 2025.3.0 are vulnerable to server-side request forgery. The primary impact is allowing users to fetch data from a remote URL. This data can be then injected into spinnaker pipelines via helm or other methods to extract things LIKE idmsv1 authentication data. This also includes calling internal spinnaker API's via a get and similar endpoints. Further, depending upon the artifact in question, auth data may be exposed to arbitrary endpoints (e.g. GitHub auth headers) leading to credentials exposure. To trigger this, a spinnaker installation MUST have two things. The first is an artifact enabled that allows user input. This includes GitHub file artifacts, BitBucket, GitLab, HTTP artifacts and similar artifact providers. JUST enabling the http artifact provider will add a "no-auth" http provider that could be used to extract link local data (e.g. AWS Metadata information). The second is a system that can consume the output of these artifacts. e.g. Rosco helm can use this to fetch values data. K8s account manifests if the API returns JSON can be used to inject that data into the pipeline itself though the pipeline would fail. This vulnerability is fixed in versions 2025.1.6, 2025.2.3, and 2025.3.0. As a workaround, disable HTTP account types that allow user input of a given URL. This is probably not feasible in most cases. Git, Docker and other artifact account types with explicit URL configurations bypass this limitation and should be safe as they limit artifact URL loading. Alternatively, use one of the various vendors which provide OPA policies to restrict pipelines from accessing or saving a pipeline with invalid URLs.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

This is a Server-Side Request Forgery (SSRF) vulnerability in Spinnaker where enabled artifact providers (HTTP, GitHub, BitBucket, GitLab) allow user-supplied URLs to be fetched by the server. Attackers can exploit this to access internal services, cloud metadata endpoints (e.g., AWS IMDS), and internal Spinnaker APIs, potentially exfiltrating authentication credentials stored in headers or environment variables.

MitigationUpgrade Spinnaker to version 2025.1.6, 2025.2.3, or 2025.3.0. Alternatively, disable HTTP and similar artifact accounts that allow user-provided URLs, though this may impact pipeline functionality.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
SpinnakerApplication
Affected:< 2025.1.6>= 2025.2.0, < 2025.2.3

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
Low
Availability
Low

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Check Spinnaker version
    Determine the installed Spinnaker version by inspecting the deployment manifests, Helm values, or by querying the Spinnaker API (e.g., /health endpoint). Compare the version number against the affected ranges: < 2025.1.6 OR >= 2025.2.0 and < 2025.2.3.
    Affected if The installed version falls within the affected version ranges.
  2. Identify enabled artifact providers
    Review Spinnaker configuration (typically in ~/.spin/config, or in the halyard/deck service configuration) to list all enabled artifact providers. Look for entries under artifact/providers or similar configuration sections.
    Affected if Any of the following artifact providers are enabled: HTTP, GitHub, BitBucket, or GitLab.
  3. Check for HTTP artifact account configuration
    Examine the artifact account configurations for the HTTP artifact provider. Look for accounts defined in the artifact http section of the Spinnaker configuration. Identify if any accounts have settings that allow user-supplied URLs (e.g., any account with userEmail or API token configuration that accepts external input).
    Affected if An HTTP artifact account exists and accepts user-supplied URLs for fetching artifacts.
  4. Check for GitHub artifact account configuration
    Examine the artifact account configurations for the GitHub artifact provider. Look for accounts defined in the artifact github section. Determine if these accounts are configured to allow pipeline artifacts from arbitrary GitHub repositories.
    Affected if A GitHub artifact account is enabled and configured to accept user-provided repository URLs.
  5. Check for BitBucket or GitLab artifact accounts
    Review the artifact configurations for BitBucket and GitLab providers. Look for accounts in the artifact bitbucket and artifact gitlab sections of the configuration.
    Affected if BitBucket or GitLab artifact accounts are enabled and configured to accept user-supplied URLs.
  6. Verify artifact credential exposure
    Inspect the configured artifact accounts to determine whether they expose authentication credentials (such as API tokens, SSH keys, or tokens) that could be exfiltrated via SSRF requests. Check headers or environment variables referenced in account configurations.
    Affected if Artifact accounts contain credentials that would be sent along with requests to user-supplied URLs, enabling potential credential theft.

A user is affected if their Spinnaker version is vulnerable AND any of the HTTP, GitHub, BitBucket, or GitLab artifact providers are enabled with accounts that accept user-supplied URLs.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 2025.1.6 / 2025.2.3 or later
Fixed in 2025.1.62025.2.3
Interim mitigation

Upgrade Spinnaker to version 2025.1.6, 2025.2.3, or 2025.3.0. Alternatively, disable HTTP and similar artifact accounts that allow user-provided URLs, though this may impact pipeline functionality.

Recommended fix High confidence

2025.2.3 (or 2025.1.6 for 2025.1.x branch installations; 2025.3.0 also available as fixed release)

  1. 1. Identify the current Spinnaker version by checking the deployment configuration or using 'hal version list' if using Halyard, or 'kubectl get deployment -n spinnaker' for Kubernetes installations.
  2. 2. Determine which release branch is in use (2025.1.x or 2025.2.x) to select the appropriate target version.
  3. 3. For Halyard-based deployments: Run 'hal config version edit --version <target-version>' with the appropriate fixed version (2025.1.6 or 2025.2.3).
  4. 4. For Kubernetes Operator-based deployments: Update the SpinnakerKind custom resource with the new version in the spec.version field.
  5. 5. Apply the configuration changes and monitor the rollout: 'hal deploy apply' for Halyard, or 'kubectl apply' for Kubernetes operator deployments.
  6. 6. Verify all Spinnaker components (Deck, Gate, Orca, Clouddriver, etc.) have successfully restarted with the new version.
  7. 7. Test that artifact providers (especially HTTP artifacts) still function correctly post-upgrade.
  8. 8. As a defense-in-depth measure after upgrading, review and restrict artifact accounts to use explicit URL configurations rather than user-provided URLs where possible.
Caveat Review release notes for 2025.2.x or 2025.1.x to confirm no breaking changes affecting custom pipelines or integrations; minor version upgrades typically preserve compatibility

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Spinnaker Scoped from the published advisory
  • Consultation4.0 h
  • Implementation8.0 h
  • Testing6.0 h
  • Review / QA3.0 h
21.0 hours of engineering $3,680
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $5,888.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2025-61916 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2025-61916 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data