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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-14T14:17:12.470Z",
  "pubdate": "2026-09-14T14:17:12.470Z",
  "executiveSummary": "The DRPC server within Apache Storm is susceptible to a memory exhaustion vulnerability resulting from improper state management of request queues.\nThe vulnerability is categorized as an uncontrolled resource consumption issue where the application indefinitely caches metadata for arbitrary function names provided by external clients.\nBecause the system fails to prune entries from its internal request queue map, an unauthenticated attacker can induce a Denial of Service (DoS) by flooding the service with unique, arbitrary function names until the process heap is fully exhausted.\nThe impact is significant, as the vulnerability does not require authentication or specific function registration to exploit, allowing remote attackers to crash the DRPC server.\nThe risk is exacerbated by the default configuration where 'drpc.authorizer' is unset, permitting unrestricted access to the endpoint from any network source.\nUsers are advised to prioritize upgrading to version 3.1.0 or implementing network-level access controls and authorization modules to mitigate the exposure of the DRPC infrastructure.",
  "technicalDetails": "The vulnerability resides in the DRPC server's request handling logic, which maintains a map mapping function names to corresponding request queues. The root cause is a lack of lifecycle management for entries within this map. When a function name is received for the first time, the server initializes a new queue and stores it in the map; however, no mechanism exists to subsequently remove these entries.\nWhile request cleanup logic removes individual requests from their respective queues and the shutdown sequence drains queues, the queue object and the map entry itself persist for the entire duration of the process lifecycle. This creates a permanent memory leak proportional to the number of unique function names processed by the server.\nThe attack vector leverages the fact that function names are derived directly from client-supplied input without validation against a whitelist of registered topologies. An attacker can craft a series of requests containing randomized or unique function strings. Because each entry in the map consumes heap memory to store the function name and its associated object, a malicious actor can systematically populate the map with an unbounded number of entries.\nThe attack flow follows a repetitive cycle: 1) The attacker initiates an unauthorized connection to the DRPC endpoint; 2) The attacker sends a DRPC request using a novel function name; 3) The server allocates heap memory to store the new queue and the name; 4) The server maintains this reference indefinitely, preventing garbage collection. By iterating this process, the attacker consumes the available memory heap, eventually triggering an OutOfMemoryError, which causes the DRPC server to crash or become unresponsive.\nExploitation requires no privileges, as the 'drpc.authorizer' remains unset by default, granting any remote user the ability to interact with the DRPC service. Because the retained state is permanent rather than transient, the service will not recover from this state without a process restart, at which point the attacker can resume the memory exhaustion process. The issue is persistent across all versions prior to 3.1.0, and the lack of authentication ensures that any network path to the DRPC port is a potential vector for exploitation."
}