CVE-2026-25534: Spinnaker Auth Bypass Vulnerability

CVE-2026-25534 Overview

CVE-2026-25534 is a Server-Side Request Forgery (SSRF) vulnerability affecting Spinnaker's clouddriver and Orca components. The vulnerability stems from an incomplete fix for a previous security issue (CVE-2025-61916), where URL validation logic fails to properly sanitize user-inputted URLs due to Java URL objects not correctly handling underscores during parsing. Attackers can craft malicious URLs containing underscores to bypass security controls and potentially access internal resources.

Critical Impact

This SSRF vulnerability allows authenticated attackers to bypass URL validation controls in both clouddriver artifact handling and Orca's fromUrl expression handling, potentially enabling access to internal network resources and sensitive data exfiltration.

Affected Products

• Spinnaker clouddriver (versions prior to 2025.2.4, 2025.3.1, 2025.4.1, and 2026.0.0)
• Spinnaker Orca (versions prior to 2025.2.4, 2025.3.1, 2025.4.1, and 2026.0.0)
• Spinnaker Platform (all components using URL validation)

Discovery Timeline

• 2026-03-17 - CVE CVE-2026-25534 published to NVD
• 2026-03-18 - Last updated in NVD database

Technical Details for CVE-2026-25534

Vulnerability Analysis

This vulnerability represents a bypass of the previous CVE-2025-61916 fix. While Spinnaker implemented URL validation logic to sanitize user-inputted URLs in clouddriver, the fix failed to account for a parsing quirk in Java's URL handling. Java URL objects do not correctly parse hostnames containing underscores, which can lead to discrepancies between validation logic and actual URL resolution. This parsing inconsistency allows attackers to construct specially crafted URLs that pass validation checks but resolve to unintended destinations.

The vulnerability is classified as CWE-918 (Server-Side Request Forgery), where an attacker can induce the application to make HTTP requests to arbitrary domains. The issue impacts multiple Spinnaker components—both the clouddriver artifacts module and Orca's fromUrl expression handling—making this a widespread concern across Spinnaker deployments.

Root Cause

The root cause lies in the validation method passing a normalized URI object to the URL restriction validator instead of the original HttpUrl object. When httpUrl.uri().normalize() is called, the resulting URI loses context that the HttpUrl class properly handles, particularly around hostname parsing with underscores. Java's standard URL/URI classes have known issues with RFC-compliant hostname validation, specifically around underscore characters which are technically invalid in hostnames but commonly used in internal DNS names.

Attack Vector

The attack leverages network-accessible endpoints where users can supply URLs for artifact retrieval or expression evaluation. An authenticated attacker can submit a URL containing carefully placed underscores that cause the validation logic to misinterpret the hostname portion. This allows the request to bypass allow-list or deny-list restrictions and reach internal resources that should be protected. The attack requires low privileges and no user interaction, with potential to impact confidentiality across security boundaries.

// Vulnerable code - passing normalized URI loses underscore handling context
// Source: https://github.com/spinnaker/spinnaker/commit/7c4737906239a958a468e843239c6785b03d0eda

// BEFORE (vulnerable):
account.getUrlRestrictions().validateURI(httpUrl.uri().normalize());

// AFTER (fixed):
account.getUrlRestrictions().validateURI(httpUrl);

The fix modifies the validation to pass the HttpUrl object directly to validateURI() instead of the normalized URI, ensuring consistent parsing behavior throughout the validation chain.

Detection Methods for CVE-2026-25534

Indicators of Compromise

• Unusual outbound HTTP requests from Spinnaker services to internal IP addresses or unexpected hostnames
• URL parameters in clouddriver or Orca logs containing underscores in hostname portions (e.g., http://internal_service.corp/)
• Artifact fetch operations targeting internal infrastructure endpoints
• Network connections from Spinnaker pods to metadata services (169.254.169.254) or internal APIs

Detection Strategies

• Monitor Spinnaker application logs for artifact URL requests containing underscores in hostnames
• Implement network-level monitoring for egress traffic from Spinnaker components to internal network ranges
• Deploy web application firewall rules to detect SSRF patterns in URL parameters
• Enable verbose logging on clouddriver and Orca services to capture URL validation events

Monitoring Recommendations

• Configure alerting for Spinnaker services making requests to RFC 1918 private address ranges
• Implement DNS query logging to detect resolution of internal hostnames from Spinnaker components
• Set up anomaly detection for unusual artifact source URLs in pipeline configurations
• Monitor for increased failed validation attempts which may indicate exploitation attempts

How to Mitigate CVE-2026-25534

Immediate Actions Required

• Upgrade Spinnaker to patched versions: 2025.2.4, 2025.3.1, 2025.4.1, or 2026.0.0
• Review recent artifact configurations for suspicious URLs containing underscore characters
• Audit network access controls to ensure Spinnaker cannot reach sensitive internal services
• Temporarily disable artifact features if patching is not immediately possible

Patch Information

Spinnaker has released security patches addressing this vulnerability. The fix ensures that URL validation uses the HttpUrl object directly rather than a normalized URI, maintaining consistent underscore handling. Patches are available in versions 2025.2.4, 2025.3.1, 2025.4.1, and 2026.0.0. For detailed information, see the GitHub Security Advisory GHSA-8r8j-gfhg-fw38 and the related advisory GHSA-vrjc-q2fh-6x9h.

Workarounds

• Disable HTTP artifact features on affected systems if they are not required
• Implement network segmentation to prevent Spinnaker from accessing sensitive internal resources
• Configure strict URL allowlists at the network/proxy level as an additional defense layer
• Deploy egress filtering to block Spinnaker services from reaching internal metadata endpoints

# Example: Restrict Spinnaker egress with network policy (Kubernetes)
# Apply strict egress rules to prevent SSRF to internal networks
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: spinnaker-egress-restrict
  namespace: spinnaker
spec:
  podSelector:
    matchLabels:
      app: clouddriver
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.0.0.0/8
        - 172.16.0.0/12
        - 192.168.0.0/16
        - 169.254.169.254/32
EOF