Raw vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:LSummary
CVE-2025-61916 is a high-severity Improper Input Validation (CWE-20) vulnerability in Linuxfoundation Spinnaker. Its CVSS base score is 7.9 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Network Sniffing (T1040); ranked at the 5th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to AC-4 (Information Flow Enforcement) and SA-11 (Developer Testing and Evaluation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2025-61916 is a server-side request forgery (SSRF) vulnerability affecting Spinnaker, an open source, multi-cloud continuous delivery platform. Versions prior to 2025.1.6, 2025.2.3, and 2025.3.0 are vulnerable, enabling unauthorized fetching of data from remote URLs that can be injected into Spinnaker pipelines via methods such as Helm or Kubernetes account manifests.
The vulnerability can be exploited by low-privileged local users (PR:L) in environments where an artifact provider allowing user-supplied URLs is enabled, such as GitHub file artifacts, BitBucket, GitLab, or HTTP artifacts; enabling the HTTP artifact provider alone introduces a no-auth HTTP provider exploitable for link-local data like AWS metadata. A pipeline consumer, such as Rosco for Helm values or Kubernetes manifests processing JSON, must also be present. Attackers can fetch remote data, call internal Spinnaker APIs via GET endpoints, inject extracted data like idmsv1 authentication into pipelines, or expose credentials such as GitHub auth headers to arbitrary endpoints, leading to credential exposure with high confidentiality impact in a changed scope (CVSS 7.9).
The vulnerability is fixed in Spinnaker versions 2025.1.6, 2025.2.3, and 2025.3.0. Advisories recommend disabling HTTP account types that permit user input of arbitrary URLs as a workaround, though this may not be feasible; artifact accounts like Git, Docker, or others with explicit URL configurations are safe as they restrict URL loading. Alternatively, vendors provide OPA policies to restrict pipelines from accessing or saving with invalid URLs. See GHSA-vrjc-q2fh-6x9h for details.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2025-206237
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 11 hardening rules · 3 OS baselines
V1.3.6V1.5.3V5.3.2V10.4.7
Mitigating Controls (NIST 800-53 r5) AI
SC-8 requires confidentiality protection for transmitted data, directly stopping credentials from traveling in plaintext.
Information flow enforcement can restrict which destinations the server is allowed to contact on behalf of users.
Developer testing and evaluation can discover missing input validation through analysis or test cases.
SI-10 directly requires validity checks on information inputs, structurally preventing improper or missing validation.
Requiring documented development standards and tools can embed input-validation practices into the engineering process.
Boundary protection limits the network reach of server-initiated requests even if SSRF occurs.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Encryption of data-in-transit directly prevents exposure of credentials during login.
Protecting identity assertions in transit covers credential transport but is narrower than the full control scope.
Secure SDLC practices directly require and enforce input validation during development.
Runtime monitoring of web applications and services can detect anomalous outbound requests indicative of SSRF.
Vulnerability identification processes can discover and record SSRF flaws in web applications.
Network segmentation and egress controls can limit the damage from successful SSRF requests.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Requires use of cryptography, directly enabling encryption of credentials in transit.
Testing against a defined set of requirements and using code review plus vulnerability scanning forces validation of inputs and handling of unanticipated conditions, reducing the chance that malformed data will be accepted.
Requires secure information transfer, which can include protecting credentials in transit.
Addresses management of authentication information, indirectly supporting protection during transmission.
Operational threat data describing SSRF campaigns can be used to tighten outbound-request allow-lists and detection rules before attackers exploit them.
Requires network security controls that can protect credential transmission.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
RHEL 8 (3 rules)
- V-230487 RHEL 8 must not have the telnet-server package installed. prevents CWE-523
- V-230265 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-20
- V-230492 RHEL 8 must not have the rsh-server package installed. prevents CWE-523