| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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.
Credit
Independently reported to the Apache Storm PMC by n0mi1k, with a proof of concept.
Also found by the ASF using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| 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. |
| 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. |
| 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. |
| 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. |
| Description
Nimbus instantiates the class named by a topology's `topology.scheduler.strategy` when scheduling it. The
allowlist intended to constrain that choice, `nimbus.scheduler.strategy.class.whitelist`, was treated as
"allow any class" when unset, and it had no entry in the shipped `defaults.yaml`, so unset was the shipped
state. An authenticated submitter could therefore cause Nimbus to instantiate any class on the Nimbus
classpath that has a no-argument constructor.
Storm's own production artifacts contain classes with side effects suitable for this: instantiating
`org.apache.storm.testing.InProcessZookeeper` starts a ZooKeeper server with its own threads and sockets
and nothing closes it, and `org.apache.storm.LocalCluster` behaves similarly. Repeated submissions
therefore consume threads, sockets and memory in the most privileged daemon in the cluster.
Mitigation
Upgrade to 3.1.0, where an unset allowlist means the strategies shipped with Storm rather than any class.
Note that this is a behaviour change: a cluster running an out-of-tree scheduler strategy without an
explicit allowlist will have those topologies refused until the class is added to
`nimbus.scheduler.strategy.class.whitelist`. The rejection message names the refused class and the
configuration key.
Users who cannot upgrade immediately should set `nimbus.scheduler.strategy.class.whitelist` explicitly to
the strategies they intend to permit. |
| 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. |
| 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 |
| 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. |
| 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.
Credit: This issue was discovered while investigating another report by K. |
| The UI daemon in Apache Storm 0.10.0 before 0.10.0-beta1 allows remote attackers to execute arbitrary code via unspecified vectors. |
| Directory traversal vulnerability in the log viewer in Apache Storm 0.9.0.1 allows remote attackers to read arbitrary files via a .. (dot dot) in the file parameter to log. |
| It was found that under some situations and configurations of Apache Storm 1.x before 1.0.4 and 1.1.x before 1.1.1, it is theoretically possible for the owner of a topology to trick the supervisor to launch a worker as a different, non-root, user. In the worst case this could lead to secure credentials of the other user being compromised. |
| On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.
The method File.createTempFile on unix-like systems creates a file with predefined name (so easily identifiable) and by default will create this file with the permissions -rw-r--r--. Thus, if sensitive information is written to this file, other local users can read this information.
File.createTempFile(String, String) will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set.
This affects the class https://github.com/apache/storm/blob/master/storm-core/src/jvm/org/apache/storm/utils/TopologySpoutLag.java#L99 and was introduced by https://issues.apache.org/jira/browse/STORM-3123
In practice, this has a very limited impact as this class is used only if ui.disable.spout.lag.monitoring
is set to false, but its value is true by default.
Moreover, the temporary file gets deleted soon after its creation.
The solution is to use Files.createTempFile https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...) instead.
We recommend that all users upgrade to the latest version of Apache Storm. |
| 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 |
| 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. |
| The Apache Storm Logviewer daemon exposes HTTP-accessible endpoints to read/search log files on hosts running Storm. In Apache Storm versions 0.9.1-incubating to 1.2.2, it is possible to read files off the host's file system that were not intended to be accessible via these endpoints. |
| Apache Storm version 1.0.6 and earlier, 1.2.1 and earlier, and version 1.1.2 and earlier expose an arbitrary file write vulnerability, that can be achieved using a specially crafted zip archive (affects other archives as well, bzip2, tar, xz, war, cpio, 7z), that holds path traversal filenames. So when the filename gets concatenated to the target extraction directory, the final path ends up outside of the target folder. |
| Apache Storm version 1.0.6 and earlier, 1.2.1 and earlier, and version 1.1.2 and earlier expose a vulnerability that could allow a user to impersonate another user when communicating with some Storm Daemons. |
