Description
Description

`DefaultStateSerializer`, used to persist and restore stateful bolt checkpoints, configured Kryo with class
registration disabled and an instantiation strategy that constructs objects without invoking their
constructors, then deserialized whatever bytes the state store returned. A party able to write to the
topology's keyspace in the state store, for example a co-tenant of a shared Redis instance or anyone with
network access to it, could therefore place a serialized object graph that executes code inside the worker
JVM when the state is restored.

This requires the Redis-backed state provider, which is not the default. Write access to a state-store key
is a data-plane privilege; code execution in the worker JVM is not, so the two are not equivalent.

Mitigation

Upgrade to 3.1.0, where the state serializer requires registered classes.

Note that this is a behaviour change for existing state: checkpoints written by an affected version may fail
to restore, and a migration step may be required. Users who cannot upgrade immediately should restrict
network and credential access to the state store to the cluster itself.

Credit

The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
Published: 2026-11-09
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

No vendor fix or workaround currently provided.

Additional remediation guidance may be available on OpenCVE Cloud.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 09 Nov 2026 11:30:00 +0000

Type Values Removed Values Added
References

Mon, 09 Nov 2026 10:15:00 +0000

Type Values Removed Values Added
Description Description `DefaultStateSerializer`, used to persist and restore stateful bolt checkpoints, configured Kryo with class registration disabled and an instantiation strategy that constructs objects without invoking their constructors, then deserialized whatever bytes the state store returned. A party able to write to the topology's keyspace in the state store, for example a co-tenant of a shared Redis instance or anyone with network access to it, could therefore place a serialized object graph that executes code inside the worker JVM when the state is restored. This requires the Redis-backed state provider, which is not the default. Write access to a state-store key is a data-plane privilege; code execution in the worker JVM is not, so the two are not equivalent. Mitigation Upgrade to 3.1.0, where the state serializer requires registered classes. Note that this is a behaviour change for existing state: checkpoints written by an affected version may fail to restore, and a migration step may be required. Users who cannot upgrade immediately should restrict network and credential access to the state store to the cluster itself. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.
Title Apache Storm Client: Deserialization of Untrusted Data from the State Store
Weaknesses CWE-502
References

Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: apache

Published:

Updated: 2026-11-09T10:13:14.284Z

Reserved: 2026-08-29T10:33:24.250Z

Link: CVE-2026-82436

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-11-09T10:17:11.633

Modified: 2026-11-09T11:17:26.213

Link: CVE-2026-82436

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-11-09T11:45:09Z

Weaknesses