AI analysis
Apache Storm's DRPC server creates a queue entry the first time it sees a function name and never removes it, so retained state accumulates for the life of the process (CWE-770, allocation without limits). Because function names come from the client and are not constrained to functions any topology has registered, an attacker can drive unbounded heap growth simply by sending requests with many distinct function names. The drpc.authorizer setting is unset by default, so no credentials are required to reach the DRPC endpoint, and any party with network access to the DRPC ports can exhaust the server's heap and take it down — a denial of service whose effect is permanent rather than a transient load spike. Apache Storm deployments running DRPC servers on versions prior to 3.1.0 are affected. No public proof of concept or exploitation is known, the CVE is not in CISA's KEV catalog, and no CVSS score has been assigned yet.
What to do: Upgrade to Apache Storm 3.1.0, where a function's queue is removed once nothing is waiting in it. If you cannot upgrade immediately, configure drpc.authorizer so only trusted principals can reach the DRPC endpoints, and ensure the DRPC ports are not reachable from untrusted networks. Also review DRPC server heap usage and logs for unexplained growth from many distinct function names, which would indicate probing.
Affected
| Apache Storm | all versions prior to 3.1.0 (fixed in 3.1.0) |
Estimated exposure
nichelikely hundreds to low thousands of DRPC-enabled Storm clusters, with only a subset having DRPC ports reachable by untrusted parties (clearly an estimate) — Apache Storm is an on-premises distributed stream-processing framework with no public install counts, and DRPC is an optional component typically deployed on internal cluster networks, so real-world exposure is limited to deployments where…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
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.