Brief Summary: Spinnaker Echo RCE via Unrestricted SpEL Evaluation (CVE-2026-32613)

Introduction

An unrestricted Spring Expression Language (SpEL) evaluation context in Spinnaker's Echo microservice allows any authenticated user with low privileges to achieve full remote code execution on the underlying host. For organizations running Spinnaker as the backbone of their multi-cloud continuous delivery pipelines, this vulnerability (CVSS 9.9 per NVD, 10.0 per GitHub Advisory) represents a direct path from a compromised developer account to complete infrastructure takeover.

Spinnaker is an open source, multi-cloud continuous delivery platform originally built at Netflix and now maintained under the Continuous Delivery Foundation (a Linux Foundation project). It is deployed by major enterprises including Target, Salesforce, Airbnb, Adobe, and JPMorgan Chase to manage software releases across AWS, GCP, Kubernetes, and other cloud providers. Its role as the orchestration layer for production deployments makes any RCE vulnerability in its services particularly consequential.

Technical Information

Root Cause: Missing SpEL Evaluation Restrictions in Echo

Spinnaker is composed of several independent microservices. Among them, Echo is the eventing service responsible for routing events, handling pipeline triggers, and processing notifications. When Echo processes pipeline definitions, specifically the "expected artifacts" section, it evaluates Spring Expression Language (SpEL) expressions embedded in those definitions.

The critical flaw (classified as CWE-94, Improper Control of Generation of Code) is an inconsistency in how different Spinnaker services handle SpEL evaluation security boundaries. Spinnaker's Orca service (the orchestration engine) had already implemented a security control: it restricts the SpEL evaluation context to a predefined set of trusted Java classes, preventing arbitrary class instantiation during expression evaluation. This is the trusted class pattern documented in Spinnaker's Pipeline Expression Reference.

Echo, however, was missing this same restriction entirely. Its SpEL evaluation context granted full JVM access, meaning any Java class available on the classpath could be instantiated and invoked during expression evaluation. The vulnerable component is specifically the Maven package io.spinnaker.echo:echo-pipelinetriggers.

Attack Flow

The exploitation path is straightforward for anyone with authenticated access to a Spinnaker deployment:

Authentication: The attacker needs only low-level authenticated access to the Spinnaker API. This could be a developer account, a service account, or any identity with permissions to define or modify pipeline configurations.
Malicious Expression Injection: The attacker crafts a pipeline definition (or modifies an existing one) containing a malicious SpEL expression within the expected artifacts configuration. Because Echo does not restrict the evaluation context, the expression can reference arbitrary Java classes, such as java.lang.Runtime, java.lang.ProcessBuilder, or java.io.File.
Expression Evaluation by Echo: When Echo processes the pipeline trigger and evaluates the expected artifacts, it encounters the malicious SpEL expression. Without a trusted class whitelist, Echo's SpEL evaluator instantiates the referenced Java classes and executes the specified methods.
Arbitrary Code Execution: The attacker achieves arbitrary command invocation, file system access, or any other operation available to the JVM process running Echo. Since Echo typically runs with the permissions of its container or host service account, this can mean access to secrets, cloud credentials, and lateral movement capabilities within the deployment environment.

CVSS v3.1 Metrics

The GitHub Security Advisory (GHSA-69rw-45wj-g4v6) provides the following base metrics:

Metric	Value	Operational Implication
Attack Vector	Network	Exploitable remotely without local access
Attack Complexity	Low	Reliable exploitation; no advanced conditions required
Privileges Required	Low	Any authenticated user with basic access can trigger the flaw
User Interaction	None	Can be automated without victim participation
Scope	Changed	Impacts resources beyond the vulnerable component
Confidentiality	High	Total loss of data protection
Integrity	High	Complete compromise of data integrity
Availability	High	Total loss of system availability

The "Changed" scope is particularly notable. It indicates that compromising Echo can lead to impact on other systems and resources beyond Echo itself, which is consistent with the ability to execute arbitrary commands on the host and potentially pivot to other infrastructure components.

Patch Information

The Spinnaker project has confirmed and published a patch for CVE-2026-32613 via GitHub Security Advisory GHSA-69rw-45wj-g4v6. The fix was developed by GitHub user jasonmcintosh, who is credited as the remediation developer in the advisory.

What the Patch Does

The patch brings Echo's SpEL evaluation context in line with Orca's existing security model. Specifically, it restricts the set of Java classes that can be instantiated during expression evaluation to only an explicitly whitelisted set of trusted classes. This is the same trusted class pattern that Spinnaker already documents in its Pipeline Expression Reference for Orca. After the patch, attempts to reference arbitrary Java classes (such as java.lang.Runtime) within SpEL expressions processed by Echo will be blocked.

Fixed Versions

The fix has been backported across all active Spinnaker release branches:

Fixed Spinnaker Version	Release Date
2025.3.2	March 19, 2026
2025.4.2	March 20, 2026
2026.0.1	March 20, 2026
2026.1.0	Latest stable

The patched releases were all published in mid-March 2026, approximately one month before the advisory and CVE were made public on April 20, 2026. The advisory's "Patches" section within the GHSA body still reads "Incoming," but the actual fixes are already available in the release tags listed above. The underlying code change has not yet been merged to the public master branch of the spinnaker/echo repository (the most recent public commit there is a docs update from December 2025), consistent with Spinnaker's security policy of shipping fixes via release branches for security sensitive changes.

Temporary Workaround

If immediate patching is not feasible, the official advisory provides a single workaround: disable the Echo service entirely. Administrators should understand the operational cost of this approach. Spinnaker relies on Echo to forward events from other services (like Orca and Igor) to registered webhooks. Disabling Echo will break pipeline triggers, event notifications, and webhook integrations, severely degrading the automated continuous delivery capabilities of the platform. This workaround should only be used as a temporary emergency measure while the upgrade is being prepared.

Affected Systems and Versions

The vulnerability affects the Maven package io.spinnaker.echo:echo-pipelinetriggers. The following version matrix details the affected and patched releases:

Release Line	Affected Versions	Patched Version
2026.1.x	Prior to 2026.1.0	2026.1.0
2026.0.x	Prior to 2026.0.1	2026.0.1
2025.4.x	Prior to 2025.4.2	2025.4.2
2025.3.x	Prior to 2025.3.2	2025.3.2

Any Spinnaker deployment running a version older than those listed in the "Patched Version" column is vulnerable. Administrators should verify their specific deployment version against this matrix. Organizations running Spinnaker versions from release lines older than 2025.3.x should consult the Spinnaker project for guidance, as those branches may not receive backported fixes.

Vendor Security History

The Spinnaker project maintains a dedicated Security Special Interest Group (SIG) to handle vulnerability reports and coordinate fixes. They operate a responsible disclosure policy, directing security researchers to report issues privately via email.

This is not the first critical vulnerability in Spinnaker's microservice architecture. A previous advisory (GHSA-8r8j-gfhg-fw38) documented a URL validation bypass in the Clouddriver and Orca microservices. The pattern here is worth noting: complex, multi-service architectures like Spinnaker can have inconsistent security controls across services. In this case, Orca had the correct SpEL restrictions while Echo did not, suggesting that security hardening was applied to services individually rather than through a shared, centralized mechanism. The discovery of CVE-2026-32613 reinforces the importance of auditing security boundaries uniformly across all services in a microservice deployment.

CVE Analysis

Experimental AI-Generated Content

Introduction

Technical Information