CVE-2026-41862: Spring Statemachine RCE Vulnerability

CVE-2026-41862 Overview

CVE-2026-41862 is an insecure deserialization vulnerability [CWE-502] in Spring Statemachine's Kryo-based persistence backends. The flaw affects the JPA, MongoDB, Redis, and ZooKeeper persistence implementations. These backends deserialize persisted state-machine contexts without enforcing a class allowlist. An attacker who can write to the underlying persistence store can trigger remote code execution inside the application JVM.

The vulnerability impacts Spring Statemachine versions 4.0.0 through 4.0.1 and 3.2.0 through 3.2.4. Exploitation requires low privileges and no user interaction, with network-based attack delivery.

Critical Impact
Successful exploitation allows arbitrary code execution within the affected application JVM, leading to full compromise of confidentiality, integrity, and availability.

Affected Products

Spring Statemachine 4.0.0 through 4.0.1
Spring Statemachine 3.2.0 through 3.2.4
Applications using Kryo-based persistence (JPA, MongoDB, Redis, ZooKeeper)

Discovery Timeline

2026-06-23 - CVE-2026-41862 published to NVD
2026-06-24 - Last updated in NVD database

Technical Details for CVE-2026-41862

Vulnerability Analysis

Spring Statemachine persists state-machine contexts to durable storage so applications can resume workflows across restarts. The Kryo-based persistence backends serialize and deserialize these contexts when reading and writing state. The deserialization path does not constrain which Java classes Kryo is permitted to instantiate.

Without a class allowlist, an attacker controlling persisted data can craft a payload referencing gadget classes available on the application classpath. When the application restores the state-machine context, Kryo instantiates these classes and invokes their methods, leading to arbitrary code execution inside the JVM.

Root Cause

The root cause is a missing class allowlist on the Kryo deserialization configuration used by the JPA, MongoDB, Redis, and ZooKeeper persistence backends. Kryo by default can be configured to register only known-safe classes, but the affected backends accept arbitrary types from persisted data. This matches the [CWE-502] pattern of deserializing untrusted data without validation.

Attack Vector

Exploitation requires an attacker to place a malicious serialized payload into the persistence store used by the Spring Statemachine. This can occur through direct write access to the database, cache, or coordination service, or through application logic that allows untrusted input to influence persisted state-machine context. When the application loads the tampered context, the Kryo deserializer reconstructs attacker-controlled objects and executes the embedded gadget chain inside the application JVM.

The vulnerability mechanism is described in the Spring Security advisory for CVE-2026-41862. No verified public proof-of-concept code is available at this time.

Detection Methods for CVE-2026-41862

Indicators of Compromise

Unexpected child processes spawned by the Java application process hosting Spring Statemachine workflows.
Anomalous outbound network connections originating from JVMs that persist state-machine contexts.
Modifications to state-machine persistence records (JPA tables, MongoDB collections, Redis keys, or ZooKeeper znodes) from unexpected sources.
JVM stack traces referencing com.esotericsoftware.kryo during deserialization of state-machine contexts.

Detection Strategies

Inventory applications using Spring Statemachine and confirm the version against the affected ranges 3.2.0-3.2.4 and 4.0.0-4.0.1.
Monitor Java process behavior for deserialization-driven execution patterns such as Runtime.exec invocations from Kryo call stacks.
Audit access controls and write patterns on databases, caches, and coordination services backing Statemachine persistence.

Monitoring Recommendations

Log and alert on application exceptions originating from com.esotericsoftware.kryo classes during context restoration.
Track integrity of Statemachine persistence stores using checksums or change-data-capture pipelines.
Correlate application restart events with downstream process creation and network egress in a centralized analytics pipeline.

How to Mitigate CVE-2026-41862

Immediate Actions Required

Identify all services depending on Spring Statemachine and verify whether they use the JPA, MongoDB, Redis, or ZooKeeper Kryo persistence backends.
Upgrade to a fixed Spring Statemachine release as published in the Spring Security advisory.
Restrict and audit write access to persistence stores so only the application service account can modify state-machine context records.
Rotate credentials for any persistence store that may have been exposed to untrusted writers.

Patch Information

Refer to the Spring Security advisory for CVE-2026-41862 for fixed version numbers and upgrade guidance. Users on the 4.0.x branch should move to a release later than 4.0.1, and users on 3.2.x should move to a release later than 3.2.4.

Workarounds

Place Statemachine persistence stores on isolated network segments accessible only to the owning application.
Enforce strict authentication and authorization on Redis, MongoDB, JPA databases, and ZooKeeper ensembles backing Statemachine.
Where feasible, disable Kryo-based persistence and use an alternative serialization mechanism with a strict class allowlist until patches are applied.
Apply Java Security Manager policies or runtime allowlists that block process execution and reflective class loading from within the persistence code path.

bash

# Example: restrict Redis access used by Spring Statemachine persistence
# 1. Bind Redis to a private interface only
sed -i 's/^bind .*/bind 127.0.0.1 10.0.0.5/' /etc/redis/redis.conf

# 2. Require authentication
echo 'requirepass <strong-random-password>' >> /etc/redis/redis.conf

# 3. Disable dangerous commands that could aid lateral movement
echo 'rename-command CONFIG ""' >> /etc/redis/redis.conf
echo 'rename-command FLUSHALL ""' >> /etc/redis/redis.conf

systemctl restart redis