Summary ZeroPath Research discovered two separate critical vulnerabilities in Spinnaker that allow low privilege authenticated users to execute arbitrary code on the Clouddriver and Echo servers. Because Spinnaker is used to deploy applications, compromising these services allows attackers to steal credentials and pivot into source control and production cloud environments. The flaws have been assigned CVE-2026-32604 and CVE-2026-32613, each with a maximum 10.0 Critical severity, and have been patched in the latest Spinnaker releases. Using our POC to pop a shell on Clouddriver Impacted Software Vulnerable Versions Patched Versions < 2026.0.1 < 2025.4.2 < 2025.3.2 2026.1.0 2026.0.1 2025.4.2 2025.3.2 To check which version you're running, invoke: curl -v https://<your-gate-host>/version Or from the Deck UI: Click the Gear Icon => Navigate to Settings Timeline 2026-03-11 Echo vulnerability reported 2026-03-11 Clouddriver vulnerability reported 2026-03-11 Spinnaker maintainers acknowledge both vulnerabilities 2026-03-12 CVEs assigned 2026-03-20 Spinnaker releases fixes in each major branch (2026.0.1, 2025.4.2, 2025.3.2) 2026-04-20 Critical CVEs (CVE-2026-32604, CVE-2026-32613) made public Exploitation Video Walkthrough Along with this article, we've released proof of concept scripts and video demonstrating the exploit in a lab. Spinnaker Background Spinnaker is an open source platform for managing and deploying cloud applications. Netflix built it originally, and it is now used by many major companies, including Google and Cisco. Some Spinnaker users listed on the Spinnaker website It is generally configured to only be privately accessible, but some instances do exist on the public internet. 94 public-facing Spinnaker instances discoverable via Shodan Architecture Core Concepts Spinnaker exists to both manage and deploy cloud applications. An Application in the Spinnaker sense is more complex than in the everyday sense. It consists of individual deployable artifacts + configuration ( Server Groups ), logical Clusters made of related Server Groups, and Applications, made up of one or more Clusters. This complexity comes in handy for deploying distributed applications like Spinnaker itself… creating one Application might mean standing up 12 unique microservices, each of which has multiple replicas and each of which has important dependencies on other services. Pipelines are the key abstraction within Spinnaker for capturing how to go about deploying a particular Application. Because of how complex the Apps it manages can get, Pipelines support a lot of rich functionality. As a result, they also expose a lot of attack surface. Both flaws we'll be discussing involve exploiting some of this Pipeline attack surface. Privilege Structure Spinnaker has a fairly straightforward privilege system. There are two primary resource types a user can have permissions to: Account (cloud account): READ: Ability to view infrastructure in cloud account WRITE: Ability to create new infrastructure in cloud account Application (managed/deployed by Spinnaker): READ: View a managed app EXECUTE: Kick off pipelines for managed app WRITE: Update pipelines and other config for managed app One of the RCEs we'll be exploring requires none of these permissions – a user just has to be authenticated. The other requires WRITE on one application. For more information about authorization in Spinnaker, the project docs are a good resource: Components Spinnaker is a complex application made up of more than 10 microservices. Only a few relate to the vulnerabilities we're focused on, but here's the overall structure: Diagram of Spinnaker microservices Key components for our purposes: Gate – public-facing API gateway Orca – responsible for executing pipelines Clouddriver – responsible for interfacing with cloud environments to stand up infrastructure Echo – central notification / event hub Fiat – authorization One vulnerability allows code execution on the Clouddriver, and the other allows code execution on Echo. In both cases, the caller can trigger the issues through the public API exposed by Gate OR by talking to relevant services directly. Key Trust Boundaries Gate authenticates and authorizes requests before dispatching them to the target microservice that fulfills the request. For the most part, services themselves do not perform any authentication or authorization. The network within which the services run is assumed to be trusted. This perimeter-based trust model is part of what makes the vulnerabilities we'll be discussing so severe. If you're an attacker, once you're past Gate (e.g. because you have code execution on an internal service), the world is your oyster. The Flaws Flaw 1: Clouddriver RCE (CVE-2026-32604) Overview Clouddriver is an especially juicy target because it typically holds cloud credentials for production environments. PUT /artifacts/fetch is an endpoint on the Gate service designed to trigger an artifact download. It's prima...