Reporting

Do you want to disclose a potential security issue for Apache Storm? Send your report to the Apache Security Team.

You can read more about the security policy on:

• Apache Storm security model

Advisories

This section is experimental: it provides advisories since 2023 and may lag behind the official CVE publications. It may also lack details found on the project security page linked above. If you have any feedback on how you would like this data to be provided, you are welcome to reach out on our public mailinglist or privately on security@apache.org

Disclosure of Unredacted Merged Daemon Configuration via the Topology Page

CVE-2026-84179 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T13:57:57.741Z

Affected

• Apache Storm Nimbus from 3.0.0 before 3.1.0
• Apache Storm UI from 3.0.0 before 3.1.0

Description

Description

getTopologyPageInfo merged the Nimbus daemon configuration with the topology’s own configuration and returned the result without redaction in the topology_conf field of TopologyPageInfo. The Storm UI copied that value verbatim into the configuration field of GET /api/v1/topology/{id} and of the corresponding metrics endpoint.

Where the cluster is configured with them, the merged map includes storm.zookeeper.auth.payload, which Storm’s own documentation directs operators to keep in storm-cluster-auth.yaml under permissions that deny access from workers, together with the keystore and truststore passwords for the Thrift, Netty and ZooKeeper TLS configuration, and any plugin key whose name denotes a secret.

getTopologyPageInfo is a topology read-only operation. Under SimpleACLAuthorizer a principal listed in topology.readonly.users or topology.readonly.groups could therefore read daemon credentials that the dedicated cluster configuration API, getNimbusConf, redacts and that is gated on nimbus.users instead. The sibling operations that exist to serve configuration were masked; the topology page, which merges in strictly more daemon state, was not.

Mitigation

Upgrade to 3.1.0, where credential-bearing values are masked before any configuration is served over the Nimbus API.

Users who cannot upgrade immediately should remove any principal that is not trusted with cluster credentials from topology.readonly.users, topology.readonly.groups, topology.users and topology.groups, and should rotate the ZooKeeper authentication payload and any TLS keystore or truststore passwords that were reachable through the topology page.

Credit

References

• https://lists.apache.org/thread/3pj6tf6xq8l6f661k3c20tqjnx6w5k55

Credits

• Wanxin Yin (yaklang.io) (finder)

Cross-Tenant Blob Deletion and Cluster Denial of Service via Unvalidated Topology Dependency Keys

CVE-2026-82441 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T13:58:55.224Z

Affected

• Apache Storm Nimbus from 3.0.0 before 3.1.0

Description

Description

A submitted topology carries two lists of blobstore keys, dependency_jars and dependency_artifacts,
which the client fills in after uploading the corresponding blobs. Nimbus performed no validation of their
contents on the submission path, yet acts on them in two places.

During cleanup of a finished topology, Nimbus deletes the keys named in those lists, and the deletion is
performed as the Nimbus subject, for which the blobstore short-circuits its ACL check. A submitter who
listed a key belonging to another topology, such as its -stormjar.jar, could therefore cause
that blob to be deleted when their own topology was cleaned up.

Separately, on acquiring leadership a Nimbus compares the dependency keys of all active topologies against
the blobstore contents and surrenders leadership if any is missing. A single key that does not exist, on a
single active topology, therefore causes every Nimbus to acquire leadership, surrender it and requeue
indefinitely, leaving the cluster without a leader and unable to schedule, clean up or accept submissions.

Mitigation

Upgrade to 3.1.0, where a submission is refused unless every entry in both lists is a dependency blob key
and exists in the blobstore.

Note that this validates new submissions only; a topology stored by an affected version with an invalid list
is unaffected by the upgrade. An operator whose cluster is failing to retain a leader should inspect the
Nimbus log for the dependency keys reported as missing and remove or resubmit the topology naming them.

Users who cannot upgrade immediately should restrict topology submission to trusted principals.

Credit

This issue was discovered by rzo1 while investigating an unrelated blobstore defect.

References

• https://lists.apache.org/thread/qzh245bczoxw4mfnyvrj3dj2crtzdso8

Credits

• rzo1 (finder)

Unauthenticated Unbounded Memory Growth in DRPC

CVE-2026-82439 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:00:08.012Z

Affected

• Apache Storm DRPC from 3.0.0 before 3.1.0

Description

Description

The DRPC server kept a map from function name to request queue and created an entry the first time a
function name was seen. No code path ever removed an entry: request cleanup removed the request from its
queue, and the shutdown path drained queues, but the queue object and its map entry remained for the life of
the process.

Function names come from the client and are not constrained to functions any topology has registered, so the
number of retained entries is bounded only by the number of distinct names an attacker chooses to send, and
each retained entry holds the name itself. drpc.authorizer is unset by default, so no credentials are
required to reach the endpoint.

The retained state is permanent rather than a transient load spike, so the effect accumulates until the DRPC
server exhausts its heap.

Mitigation

Upgrade to 3.1.0, where a function’s queue is removed once nothing is waiting in it.

Users who cannot upgrade immediately should configure drpc.authorizer so that only trusted principals can
reach the DRPC endpoints, and should ensure the DRPC ports are not reachable from untrusted networks.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/7sgzvv5lzz93jn6vy74qfk105bhmkrzs

Credits

• The ASF using Claude Agents (finder)

Authenticated API Responses Exposed to Arbitrary Web Origins

CVE-2026-82438 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:02:06.144Z

Affected

• Apache Storm Webapp from 3.0.0 before 3.1.0

Description

Description

Three separate mechanisms allowed a web page on an unrelated origin to read responses that Storm’s HTTP
components served to an authenticated user.

The Logviewer reflected the request’s Origin header back in Access-Control-Allow-Origin while also
sending Access-Control-Allow-Credentials: true. The published security model documents a permissive
Access-Control-Allow-Origin: * posture as accepted, which is safe precisely because browsers refuse to
honour * together with credentials; reflecting the concrete origin removes that protection.

The shared CORS filter used by the UI, the Logviewer and DRPC was configured with a response header name
where an initialisation parameter name was expected. The container ignored the setting and applied its own
defaults, which allow credentials.

Finally, the UI and Logviewer wrapped API responses in a caller-supplied JSONP callback for every GET
request. A script element on any origin can load such a response, which bypasses the same-origin policy
entirely rather than negotiating it, and there was no way to turn the behaviour off.

In each case the effect is that a page visited by an authenticated operator can read cluster, topology and
log data on their behalf.

Mitigation

Upgrade to 3.1.0, where the Logviewer no longer reflects the request origin in a credentialed response, the
CORS filter is configured explicitly, and JSONP wrapping is governed by ui.enable.jsonp, which defaults to
false.

Note that disabling JSONP is a behaviour change for tooling that passes a callback query parameter; such
tooling should be moved to ordinary JSON requests.

Users who cannot upgrade immediately should place the UI, Logviewer and DRPC HTTP endpoints behind a reverse
proxy that strips Access-Control-Allow-Origin and Access-Control-Allow-Credentials from responses and
rejects requests carrying a callback parameter.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/2o7tl3hcdd865njxsn4d9cxp1frkctz3

Credits

• The ASF using Claude Agents (finder)

Log Access Controls Not Enforced by Logviewer

CVE-2026-82437 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:05:07.291Z

Affected

• Apache Storm Logviewer from 3.0.0 before 3.1.0

Description

Description

The Logviewer offers logs.users and logs.groups so operators can control who may read log content. For
daemon logs those settings were not applied: the access decision combined the “this is a daemon log” flag
with the authorizer result in a way that discarded the authorizer’s answer whenever the flag was set, and
the daemon log page and download endpoints reached the handler without consulting an authorizer at all. Any
user able to pass the configured servlet filter could therefore read nimbus.log, supervisor.log and the
other daemon logs on every reachable node, which contain other tenants’ topology names, owners and
configuration fragments.

The same advisory covers the log listing endpoints, which accepted a user argument and never applied it, so
/listLogs and /searchLogs returned every tenant’s topology and worker log file names regardless of the
caller. That part is metadata only.

There was no configuration that closed either behaviour.

Mitigation

Upgrade to 3.1.0, where the daemon log paths evaluate the same configured user and group lists that the
worker log paths already used, and the listing endpoints filter by the requesting user.

Users who cannot upgrade immediately should place the Logviewer behind a reverse proxy that restricts the
daemon log endpoints, and should treat daemon log content as readable by any filter-authenticated user.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/hqyj3spllmbj6vg9vmx29b1tjhzysdkl

Credits

• The ASF using Claude Agents (finder)

Unauthenticated Remote Memory Exhaustion in the Worker Messaging Decoder

CVE-2026-82435 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:09:19.187Z

Affected

• Apache Storm Worker from 3.0.0 before 3.1.0

Description

Description

The worker’s Netty message decoder is installed ahead of the SASL authentication handlers in the pipeline
and acts on frames before any authentication has taken place. It allocated buffers sized from a
length field carried in the frame, so a single frame from an unauthenticated peer able to reach a worker
slot port could drive a large allocation.

storm.messaging.netty.authentication defaults to false, and the decoder runs before the handler that
enforces it in any case, so no credentials are required. The attacker needs only TCP reachability to a
worker port.

The effect of a single frame at the default 768 MB worker heap has not been measured to distinguish
sustained worker loss from transient garbage-collection pressure. The severity assigned to this advisory
reflects the more conservative reading; consumers who require a precise figure should test against their own
worker heap configuration.

References

• https://lists.apache.org/thread/wqfy7qb8c76f4c3wr2w6bhoz62vcnpb7

Credits

• The ASF using Claude Agents (finder)

Disclosure of the Topology ZooKeeper Credential to Read-Only Users and to Logs

CVE-2026-82434 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:10:14.214Z

Affected

• Apache Storm Nimbus from 3.0.0 before 3.1.0
• Apache Storm Client from 3.0.0 before 3.1.0

Description

Description

When ZooKeeper authentication is configured, Storm deliberately retains
storm.zookeeper.topology.auth.payload in the topology configuration, because workers need it. Nimbus then
served that configuration verbatim to any caller holding read-only topology permissions, so a user whose
only grant was the ability to view a topology received its ZooKeeper credential.

That credential is not read-only. The cluster state implementation uses write-capable ACLs for worker
heartbeats, backpressure and error state, so a recipient can forge or remove that state for the topology
concerned. It is not a write credential on assignments.

The same advisory covers the submission client, which logged the generated payload at INFO on every
submission that generated one, and the SASL handlers, which logged it at DEBUG. The credential therefore
also reached any log aggregation or support bundle collected from the cluster.

Mitigation

Upgrade to 3.1.0, where the payload is removed from the configuration served to read-only callers and is no
longer written to logs.

Users who cannot upgrade immediately should rotate storm.zookeeper.topology.auth.payload for existing
topologies, review retained logs and support bundles for the value, and restrict read-only topology
permissions to trusted principals.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/1t7hggrz59rdq792qm1pnkqj0ogm2szq

Credits

• The ASF using Claude Agents (finder)

Disclosure of Unredacted Daemon Configuration via Nimbus and the UI

CVE-2026-82433 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:12:22.650Z

Affected

• Apache Storm Nimbus from 3.0.0 before 3.1.0
• Apache Storm UI from 3.0.0 before 3.1.0

Description

Description

getNimbusConf returned the complete daemon configuration without redaction after only a user-level
authorization check. Where the cluster is configured with them, that response includes
storm.zookeeper.auth.payload and the keystore and truststore passwords for the Thrift, Netty and
ZooKeeper TLS configuration. The project masks passwords elsewhere before display, so the omission here is
inconsistent rather than intended.

The UI endpoint /api/v1/cluster/configuration compounded this. It carried no @AuthNimbusOp annotation,
and the authorization filter treated a missing annotation as “no gate required” and returned immediately, so
the endpoint applied no per-user check at all and proxied the request under the UI daemon’s own principal.
Any user able to pass ui.filter therefore received the full configuration, including principals that
Nimbus itself would have refused. 

Mitigation

Upgrade to 3.1.0, where credential-bearing values are masked before the configuration is served and where
every UI API endpoint must declare its authorization explicitly.

Users who cannot upgrade immediately should place the UI behind an authenticating reverse proxy that
restricts /api/v1/cluster/configuration, and should rotate the ZooKeeper authentication payload and any
TLS keystore or truststore passwords that were reachable through it.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/ohw4s30rhm2r20498c0zbqxyy7xd5hxl

Credits

• The ASF using Claude Agents (finder)

Blobstore Authorization Bypass via Rebalance Configuration Overrides

CVE-2026-82432 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:11:26.098Z

Affected

• Apache Storm Nimbus from 3.0.0 before 3.1.0

Description

Description

Nimbus validated topology.blobstore.map against the calling subject at submission time only. The rebalance
operation accepts configuration overrides and stripped a small set of keys from them, but never re-ran that
validation, so a caller authorised to rebalance a topology could introduce a blobstore map entry naming a
blob whose ACL does not grant them access. Supervisors localise whatever key the map names, placing the
blob’s contents into the topology’s working directory.

The same advisory covers listBlobs, which performed no authorization check and passed no subject, unlike
the neighbouring getBlobMeta and beginBlobDownload operations. It therefore returned every key in the
blobstore to any caller able to reach the Nimbus Thrift port, which provides the key names that make the
above practical. On its own the disclosure is metadata only.

Mitigation

Upgrade to 3.1.0, where rebalance configuration overrides are validated exactly as submission-time
configuration is, against the rebalancing caller, and where listBlobs applies the configured
authorization.

Users who cannot upgrade immediately should restrict rebalance rights to trusted principals, keeping in mind
that membership of a topology’s topology.users or topology.groups confers them.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/psy1gj77jhf9y3lhph9yz4f5fovmkz7b

Credits

• The ASF using Claude Agents (finder)

Authorization Bypass When nimbus.groups Is Configured Without nimbus.users

CVE-2026-82431 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:14:47.150Z

Affected

• Apache Storm Client from 3.0.0 before 3.1.0

Description

Description

SimpleACLAuthorizer evaluated the user-level command set by returning early when nimbus.users was empty,
before nimbus.groups was considered. An operator who restricted cluster access by group alone, leaving
nimbus.users unset, therefore received no restriction at all: every authenticated principal was permitted
every user-level operation, including submitTopology, beginFileUpload and getNimbusConf.

docs/SECURITY.md presents nimbus.groups as a supported way to lock down a cluster, so a deployment
following the documentation could believe it was restricted while it was not. The failure is silent; nothing
in the logs or the configuration indicates that the group list is being ignored.

Both lists left empty continues to mean that no restriction is configured, which is the shipped default and
is unchanged.

Mitigation

Upgrade to 3.1.0, where nimbus.groups is evaluated whether or not nimbus.users is set.

Users who cannot upgrade immediately should additionally populate nimbus.users with the intended
principals, since a non-empty user list causes the group list to be evaluated on affected versions.
Operators should review Nimbus access logs for operations by principals outside the intended groups.

Note that after upgrading, a cluster configured with nimbus.groups alone becomes restrictive for the first
time. This includes NimbusClient, which calls getLeader on every connection, so clients outside the
configured groups will begin to be refused.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/s335qxb6woqb35ho3fpq7toytsz1gpts

Credits

• The ASF using Claude Agents (finder)

Local Privilege Escalation to Root via Container Command Files Chowned to the Tenant

CVE-2026-82430 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:15:57.534Z

Affected

• Apache Storm Worker Launcher from 3.0.0 before 3.1.0

Description

Description

When launching a Docker or OCI worker, the setuid-root worker-launcher first changes ownership of the
entire worker directory to the untrusted topology user, and only afterwards reads and acts on the command
file that the supervisor wrote into that same directory. The file is opened without O_NOFOLLOW and without
re-verifying its owner, so between the ownership change and the read the tenant can replace its contents.

For the Docker path the parsed command is executed with real uid 0, and the command sanitiser is not a
privilege boundary: it admits -v with an arbitrary source, --device, --cap-add, --security-opt,
--user and --net, and copies positional arguments through verbatim. A rewritten file therefore yields an
attacker-authored, root-equivalent container invocation with the host filesystem available.

For the OCI path the same rewrite window applies, and mount validation is structural only, with no
source or destination allow-list, so arbitrary host paths can be bind-mounted read-write into the
container. The username field of the command file is likewise attacker-settable and is checked only
against non-root and minimum-uid rules, permitting execution as another tenant’s uid.

Mitigation

Upgrade to 3.1.0, where the command file is validated before the ownership change and re-verified on open,
and where mount sources and destinations are constrained by configuration.

Users who cannot upgrade immediately should disable Docker and OCI worker isolation, or restrict topology
submission on affected supervisors to trusted principals. Note that the launcher must be rebuilt and
reinstalled after upgrading.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/8d5pkn486p8vrz5klg6onk5r8k9sd9lv

Credits

• The ASF using Claude Agents (finder)

Local Privilege Escalation to Root via a Time-of-Check Race in the Worker Launcher

CVE-2026-82429 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:16:44.051Z

Affected

• Apache Storm Worker Launcher from 3.0.0 before 3.1.0

Description

Description

The setuid-root worker-launcher binary adjusts ownership and permissions of worker directories by walking
the tree with FTS and calling lchown and chmod on each entry’s full pathname while running with an
effective uid of 0. Both syscalls re-resolve the path at the time of the call, after FTS has classified the
entry, and the trees being walked are owned and writable by the untrusted topology user.

A tenant running code on a supervisor node could therefore replace an intermediate directory component with
a symbolic link between classification and the privileged operation, redirecting the root-owned lchown or
chmod at an arbitrary file on the host. The operation is repeatable at will, since crashing a worker
forces a relaunch and blob updates re-run the walk, so a failed attempt costs the attacker nothing.

This crosses the boundary that supervisor.run.worker.as.user and container isolation are intended to
enforce. It is the same defect class as the Hadoop container-executor issues from which this code derives.

Mitigation

Upgrade to 3.1.0, where the privileged walk operates on file descriptors it has already stat’d rather than
on pathnames re-resolved at call time.

Users who cannot upgrade immediately should not run untrusted topology code on supervisors configured with
supervisor.run.worker.as.user, since the launcher is the boundary being crossed. Note that the launcher
must be rebuilt and reinstalled after upgrading; replacing the Java artifacts alone is not sufficient.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/9vjqrt28g0mxg304vw6pw46cx72v4rvq

Credits

• The ASF using Claude Agents (finder)

Cross-Tenant Dependency Jar Substitution via Predictable Blob Keys

CVE-2026-82428 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:18:08.670Z

Affected

• Apache Storm Client from 3.0.0 before 3.1.0

Description

Description

Dependency artifacts uploaded with storm jar --artifacts were stored under a blob key derived only from
the Maven coordinate, for example dep---.jar. The key was therefore identical
for every user of the cluster and predictable in advance. When the blob already existed, the uploader
caught KeyAlreadyExistsException and silently reused it, with no check that the existing blob’s content
or owner matched the artifact the submitter had resolved.

A user who uploaded a blob under such a key first therefore controlled the bytes that every later submitter
of the same coordinate would receive on the worker classpath, resulting in code execution inside another
tenant’s topology.

This affects deployments where more than one principal may create blobs and where the --artifacts
dependency feature is used.

Mitigation

Upgrade to 3.1.0, where each uploaded artifact receives a key carrying a freshly generated UUID and a
pre-existing blob is no longer silently reused.

Note that the corrected key generation is on the SUBMITTING CLIENT, so upgrading the cluster alone does not
close this; every client that runs storm jar --artifacts must also be upgraded. Operators should audit
existing dep- blobs for unexpected owners before upgrading. Users who cannot upgrade immediately should
avoid the --artifacts mechanism in multi-tenant clusters and distribute dependencies inside the topology
jar instead.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/pj3fspp4l10fgk2jkvrnqsmxycmjv622

Credits

• The ASF using Claude Agents (finder)

Path Traversal as the Supervisor User via Unsanitised Blobstore Map Local Name

CVE-2026-82427 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:19:14.743Z

Affected

• Apache Storm Nimbus from 3.0.0 before 3.1.0

Description

Description

A topology’s topology.blobstore.map lets the submitter choose a local name for each blob that the
supervisor localises. That name was used to build a path under the topology’s working directory without
normalisation, in both AsyncLocalizer and Container.createBlobstoreLinks, and the symlink helper
force-deletes whatever already exists at the target before creating the link.

A submitter could therefore use ../ segments to direct that delete-and-symlink operation at an arbitrary
path, as the supervisor user, on every node the topology is scheduled onto. The consequences include
recursive deletion of supervisor-owned content and planting a symlink that causes a subsequent worker
launch to execute attacker-chosen code as another tenant’s operating-system user, which defeats the
isolation that supervisor.run.worker.as.user is intended to provide.

Mitigation

Upgrade to 3.1.0, where the resolved target must lie inside the expected root at both call sites.

Users who cannot upgrade immediately should restrict topology submission to trusted principals, and may
reject submissions whose topology.blobstore.map entries contain path separators or .. segments before
they reach Nimbus.

Credit

The ASF – found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

References

• https://lists.apache.org/thread/o0j51w6m0qdmwypvzfnd8w97s7ysnmyj

Credits

• The ASF using Claude Agents (finder)

Arbitrary File Read on Nimbus via Unvalidated Uploaded Jar Location

CVE-2026-82426 [CVE] [CVE json] [OSV json]

Last updated: 2026-09-14T14:04:15.864Z

Affected

• Apache Storm Nimbus from 3.0.0 before 3.1.0

Description

Description

Nimbus accepted the uploadedJarLocation argument of submitTopology / submitTopologyWithOpts as a
server-side path and opened it directly, without checking that it referred to a file the caller had
actually uploaded. The intended flow is that a client first calls beginFileUpload, which returns a path
inside the Nimbus inbox, and uploads the jar in chunks to that location; nothing bound submission to that
flow, and the uploaders map populated by beginFileUpload was never consulted at submit time.

An authenticated user with topology submission rights could therefore submit any path readable by the
Nimbus daemon user as their topology jar. Nimbus copied the file into the topology’s jar blob, and the
blob ACL grants the submitting subject read access, so the contents could then be retrieved with the
ordinary blob download RPCs. Candidate targets include the Nimbus Kerberos keytab, Thrift and UI TLS
private keys, and storm.yaml with the ZooKeeper authentication payload. Possession of the Nimbus keytab
turns an ordinary tenant into a cluster administrator.

In a deployment configured as the documentation recommends, submission is available to every
authenticated principal when nimbus.users is unset, so no elevated privilege is required.

Mitigation

Upgrade to 3.1.0, where the submitted location is canonicalised and must resolve inside the Nimbus inbox.

Users who cannot upgrade immediately should restrict topology submission to trusted principals via
nimbus.users or nimbus.groups, and should treat any file readable by the Nimbus daemon user as
potentially exposed to submitters: rotate the Nimbus keytab and any TLS private keys or ZooKeeper
credentials reachable from that account. Local mode is unaffected.

References

• https://lists.apache.org/thread/cq3xzxvvhtb6brbp9nl9p8kobnvtmnwc

Credits

• n0mi1k (finder)
• The ASF using Claude Agents (finder)

Anonymous principal assigned on TLS client certificate verification failure

CVE-2026-41081 [CVE] [CVE json] [OSV json]

Last updated: 2026-04-27T13:10:44.288Z

Affected

• Apache Storm Client before 2.8.7

Description

Improper Handling of TLS Client Authentication Failure Leading to Anonymous Principal Assignment in Apache Storm

Versions Affected: up to 2.8.7

Description: When TLS transport is enabled in Apache Storm without requiring client certificate authentication (the default configuration), the TlsTransportPlugin assigns a fallback principal (CN=ANONYMOUS) if no client certificate is presented or if certificate verification fails. The underlying SSLPeerUnverifiedException is caught and suppressed rather than rejecting the connection.

This fail-open behavior means an unauthenticated client can establish a TLS connection and receive a valid principal identity. If the configured authorizer (e.g., SimpleACLAuthorizer) does not explicitly deny access to CN=ANONYMOUS, this may result in unauthorized access to Storm services. The condition is logged at debug level only, reducing visibility in production.

Impact: Unauthenticated clients may be assigned a principal identity, potentially bypassing authorization in permissive or misconfigured environments.

Mitigation: Users should upgrade to 2.8.7 in which TLS authentication failures are handled in a fail-closed manner.

Users who cannot upgrade immediately should:
- Enable mandatory client certificate authentication (nimbus.thrift.tls.client.auth.required: true)
- Ensure authorization rules explicitly deny access to CN=ANONYMOUS
- Review all ACL configurations for implicit default-allow behavior

References

• https://lists.apache.org/thread/plxx5l29dvplk5rwzdcq53rdfl6v4gs8

Credits

• K (finder)

Disabling TLS verification for Prometheus Reporter also disables it for all other connections

CVE-2026-40557 [CVE] [CVE json] [OSV json]

Last updated: 2026-04-27T13:12:09.640Z

Affected

• Apache Storm Prometheus Reporter from 2.6.3 before 2.8.7

Description

Improper Certificate Validation via Global SSL Context Downgrade in Apache Storm Prometheus Reporter

Versions Affected: from 2.6.3 to 2.8.6

Description: 

In production deployments where an administrator enables storm.daemon.metrics.reporter.plugin.prometheus.skip_tls_validation (by default it is disabled) intending to affect only the Prometheus reporter, the undocumented global side effect creates an attack surface across every TLS-protected communication channel in the Storm daemon.

The PrometheusPreparableReporter class implements an INSECURE_TRUST_MANAGER that accepts all SSL certificates without validation, with empty checkClientTrusted and checkServerTrusted methods. Most critically, when the storm.daemon.metrics.reporter.plugin.prometheus.skip_tls_validation configuration option is enabled (default = disabled) for HTTPS Prometheus PushGateway connections, the INSECURE_CONNECTION_FACTORY calls SSLContext.setDefault(sslContext), which globally replaces the JVM's default SSL context rather than applying the insecure context only to the Prometheus connection. This payload flows through storm.yaml configuration → PrometheusPreparableReporter.prepare() → INSECURE_CONNECTION_FACTORY → SSLContext.setDefault(), resulting in a JVM-wide TLS security downgrade. All subsequent HTTPS connections in the process - including ZooKeeper, Thrift, Netty, and UI connections - silently trust all certificates, including self-signed, expired, and attacker-generated ones, enabling man-in-the-middle interception of cluster state, topology submissions, tuple data, and administrative credentials.

Mitigation: 2.x users should upgrade to 2.8.7 if the Prometheus Metrics Reporter is used. Prometheus Metrics Reporter Users who cannot upgrade immediately should remove the storm.daemon.metrics.reporter.plugin.prometheus.skip_tls_validation: true setting from their storm.yaml configuration and instead configure a proper truststore containing the PushGateway's certificate.

References

• https://lists.apache.org/thread/f5bv68z1y5xstz22psjk05p3wn86knjq

Credits

• K (finder)

Stored Cross-Site Scripting (XSS) via Unsanitized Topology Metadata in Storm UI

CVE-2026-35565 [CVE] [CVE json] [OSV json]

Last updated: 2026-04-13T09:10:15.976Z

Affected

• Apache Storm UI before 2.8.6

Description

Stored Cross-Site Scripting (XSS) via Unsanitized Topology Metadata in Apache Storm UI

Versions Affected: before 2.8.6

Description: The Storm UI visualization component interpolates topology metadata including component IDs, stream names, and grouping values directly into HTML via innerHTML in parseNode() and parseEdge() without sanitization at any layer. An authenticated user with topology submission rights could craft a topology containing malicious HTML/JavaScript in component identifiers (e.g., a bolt ID containing an onerror event handler). This payload flows through Nimbus → Thrift → the Visualization API → vis.js tooltip rendering, resulting in stored cross-site scripting. 

In multi-tenant deployments where topology submission is available to less-trusted users but the UI is accessed by operators or administrators, this enables privilege escalation through script execution in an admin's browser session.

Mitigation: 2.x users should upgrade to 2.8.6. Users who cannot upgrade immediately should monkey-patch the parseNode() and parseEdge() functions in the visualization JavaScript file to HTML-escape all API-supplied values including nodeId, :capacity, :latency, :component, :stream, and :grouping before interpolation into tooltip HTML strings, and should additionally restrict topology submission to trusted users via Nimbus ACLs as a defense-in-depth measure. A guide on how to do this is available in the release notes of 2.8.6.

References

• https://storm.apache.org/2026/04/12/storm286-released.html

RCE through Unsafe Deserialization via Kerberos TGT Credential Handling

CVE-2026-35337 [CVE] [CVE json] [OSV json]

Last updated: 2026-04-13T09:11:04.526Z

Affected

• Apache Storm Client before 2.8.6

Description

Deserialization of Untrusted Data vulnerability in Apache Storm.

Versions Affected: before 2.8.6.

Description: When processing topology credentials submitted via the Nimbus Thrift API, Storm deserializes the base64-encoded TGT blob using ObjectInputStream.readObject() without any class filtering or validation. An authenticated user with topology submission rights could supply a crafted serialized object in the "TGT" credential field, leading to remote code execution in both the Nimbus and Worker JVMs.

Mitigation: 2.x users should upgrade to 2.8.6.

Users who cannot upgrade immediately should monkey-patch an ObjectInputFilter allow-list to ClientAuthUtils.deserializeKerberosTicket() restricting deserialized classes to javax.security.auth.kerberos.KerberosTicket and its known dependencies. A guide on how to do this is available in the release notes of 2.8.6.

Credit: This issue was discovered by K.

References

• https://storm.apache.org/2026/04/12/storm286-released.html

Credits

• K (finder)

Local Information Disclosure Vulnerability in Storm-core on Unix-Like systems due temporary files

CVE-2023-43123 [CVE] [CVE json] [OSV json]

Last updated: 2023-11-23T09:16:32.695Z

Affected

• Apache Storm from 2.0.0 before 2.6.0

Description

References

• https://lists.apache.org/thread/88oc1vqfjtr29cz5xts0v2wm5pmhbm0l

Credits

• Andrea Cosentino from Apache Software Foundation (finder)

Unsafe Pre-Authentication Deserialization In Workers

CVE-2021-40865 [CVE] [CVE json] [OSV json]

Last updated: 2021-10-21T21:27:58.697Z

Affected

• Apache Storm from v1.0.0 before Apache Storm *
• Apache Storm from Apache Storm before v1.2.4

Description

An Unsafe Deserialization vulnerability exists in the worker services of the Apache Storm supervisor server allowing pre-auth Remote Code Execution (RCE). Apache Storm 2.2.x users should upgrade to version 2.2.1 or 2.3.0. Apache Storm 2.1.x users should upgrade to version 2.1.1. Apache Storm 1.x users should upgrade to version 1.2.4

References

• https://lists.apache.org/thread.html/r8d45e74299897b6734dd0f788c46a631009ce2eeb731523386f7a253%40%3Cuser.storm.apache.org%3E
• https://seclists.org/oss-sec/2021/q4/45

Credits

• Apache Storm would like to thank @pwntester Alvaro Muñoz of the GitHub Security Lab team for reporting this issue.

Shell Command Injection Vulnerability in Nimbus Thrift Server

CVE-2021-38294 [CVE] [CVE json] [OSV json]

Last updated: 2021-10-21T22:16:43.838Z

Affected

• Apache Storm from v1.0.0 before Apache Storm*
• Apache Storm from Apache Storm before v1.2.4

Description

A Command Injection vulnerability exists in the getTopologyHistory service of the Apache Storm 2.x prior to 2.2.1 and Apache Storm 1.x prior to 1.2.4. A specially crafted thrift request to the Nimbus server allows Remote Code Execution (RCE) prior to authentication.

References

• https://lists.apache.org/thread.html/r5fe881f6ca883908b7a0f005d35115af49f43beea7a8b0915e377859%40%3Cuser.storm.apache.org%3E
• https://seclists.org/oss-sec/2021/q4/44

Credits

• Apache Storm would like to thank @pwntester Alvaro Muñoz of the GitHub Security Lab team for reporting this issue.