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 lets any low-privileged authenticated user 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) is 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). Major enterprises including Target, Salesforce, Airbnb, Adobe, and JPMorgan Chase use it to manage software releases across AWS, GCP, Kubernetes, and other cloud providers. Because Spinnaker is the orchestration layer for production deployments, an RCE in any of its services is especially serious.

Technical Information

Root Cause: Missing SpEL Evaluation Restrictions in Echo

Spinnaker is made up of several independent microservices. One of them, Echo, is the eventing service that routes events, handles pipeline triggers, and processes notifications. When Echo processes the "expected artifacts" section of a pipeline definition, it evaluates any SpEL expressions embedded there.

The flaw, classified as CWE-94 (Improper Control of Generation of Code), comes from an inconsistency in how Spinnaker services enforce security boundaries around SpEL evaluation. Orca, Spinnaker's orchestration engine, already restricts its SpEL evaluation context to a predefined set of trusted Java classes, so expressions cannot instantiate arbitrary classes. This is the trusted class pattern documented in Spinnaker's Pipeline Expression Reference.

Echo had no such restriction. Its SpEL evaluation context granted full JVM access, so an expression could instantiate and invoke any Java class on the classpath. The vulnerable component is the Maven package io.spinnaker.echo:echo-pipelinetriggers.

Attack Flow

For anyone with authenticated access to a Spinnaker deployment, exploitation is straightforward:

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 permission to define or modify pipeline configurations.
The attacker crafts a pipeline definition, or modifies an existing one, so that the expected artifacts configuration contains a malicious SpEL expression. 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.
When Echo processes the pipeline trigger and evaluates the expected artifacts, it reaches the malicious expression. With no trusted class whitelist in place, Echo's SpEL evaluator instantiates the referenced Java classes and executes the specified methods.
The attacker can now invoke arbitrary commands, access the file system, or perform any other operation available to the JVM process running Echo. Echo typically runs with the permissions of its container or host service account, so this can mean access to secrets and cloud credentials, plus the ability to move laterally within the deployment environment.

CVSS v3.1 Metrics

The GitHub Security Advisory (GHSA-69rw-45wj-g4v6) lists these base metrics:

Metric	Value	Operational Implication
Attack Vector	Network	Exploitable remotely without local access
Attack Complexity	Low	Reliable exploitation with 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 means a compromise of Echo can affect systems and resources beyond Echo itself. That fits a flaw that allows arbitrary commands on the host and potentially a pivot to other infrastructure components.

Patch Information

The Spinnaker project has confirmed CVE-2026-32613 and published a patch through GitHub Security Advisory GHSA-69rw-45wj-g4v6. The advisory credits GitHub user jasonmcintosh as the remediation developer.

What the Patch Does

The patch brings Echo's SpEL evaluation context in line with Orca's existing security model. It limits the Java classes that expressions can instantiate to an explicitly whitelisted set of trusted classes, the same trusted class pattern Spinnaker already documents for Orca in its Pipeline Expression Reference. After the patch, Echo blocks SpEL expressions that try to reference arbitrary Java classes such as java.lang.Runtime.

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 "Patches" section of the GHSA body still reads "Incoming," but the fixes are already available in the release tags above. The underlying code change has not yet been merged to the public master branch of the spinnaker/echo repository, where the most recent public commit is a docs update from December 2025. That is consistent with Spinnaker's security policy, which ships security-sensitive fixes through release branches.

Temporary Workaround

For teams that cannot patch immediately, the official advisory gives a single workaround, which is to disable the Echo service entirely. Administrators should understand what that costs. 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, which severely degrades the platform's automated continuous delivery. Use this workaround only 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 matrix below lists 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 check their deployment's version against this matrix. Release lines older than 2025.3.x may not receive backported fixes, so organizations running them should consult the Spinnaker project for guidance.

Vendor Security History

The Spinnaker project maintains a dedicated Security Special Interest Group (SIG) to handle vulnerability reports and coordinate fixes. Its responsible disclosure policy asks security researchers to report issues privately by email.

Spinnaker's microservice architecture has had critical vulnerabilities before. A previous advisory (GHSA-8r8j-gfhg-fw38) documented a URL validation bypass in the Clouddriver and Orca microservices. Complex, multi-service architectures like Spinnaker can end up with inconsistent security controls across services. In this case Orca had the correct SpEL restrictions and Echo did not, which suggests the hardening was applied to services individually rather than through a shared, centralized mechanism. CVE-2026-32613 is a case for auditing security boundaries uniformly across all services in a microservice deployment.

CVE Analysis

Experimental AI-Generated Content

Introduction

Technical Information