Remote Code Execution in Spring Statemachine via Unsafe Deserialization

Executive Summary

This vulnerability exists in Spring Statemachine's Kryo-based persistence backends (including JPA, MongoDB, Redis, and ZooKeeper). It involves deserialising persisted state-machine contexts without enforcing a class allowlist, which is a security weakness known as CWE-502 (deserialization of untrusted data). Because of this, an attacker can potentially execute remote code inside the application's Java Virtual Machine (JVM).

Useful 0 Not Useful 0

Impact Analysis

The vulnerability can lead to remote code execution within the application JVM. This means an attacker could run arbitrary code on the affected system, potentially leading to full system compromise, data theft, data corruption, or disruption of services.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows remote code execution inside the application JVM due to unsafe deserialization of untrusted data. Such a security flaw can lead to unauthorized access, data breaches, or manipulation of sensitive information.

Consequently, organizations using affected versions of Spring Statemachine may face challenges in maintaining compliance with standards and regulations like GDPR and HIPAA, which require protection of personal and sensitive data against unauthorized access and breaches.

Failure to address this vulnerability could result in violations of these regulations, potentially leading to legal penalties, reputational damage, and loss of trust.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate CVE-2026-41862, you should upgrade Spring Statemachine to the fixed versions: 4.0.2 (OSS) or 4.0.1.1 and 3.2.5 (Enterprise Support Only). These versions enforce Kryo's registration requirement and introduce a helper to register framework and JDK types by default.

If your application uses custom state or event types, you must explicitly register them via a Consumer<Kryo> callback in the persistence-layer factory to avoid exceptions during persistence or loading.

Be aware that the upgrade introduces wire-format incompatibility, so persisted contexts from older versions cannot be read by the fixed versions. You should either drain or migrate the persistence backend during the upgrade or accept that pre-upgrade contexts become unreadable.

For Redis users, note that a new key namespace (ssm:context: by default) is introduced to prevent key collisions. Existing keys from older versions will not be visible after the upgrade unless rewritten or a custom prefix is used.

Applying these patches promptly is advised to secure your applications against remote code execution risks.

Useful 0 Not Useful 0