CVE-2026-82439: Apache Storm DRPC: Unauthenticated Unbounded Memory Growth in DRPC
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Storm DRPCto a version that resolves this vulnerability.Fixed in 3.1.0Patch CVE-2026-82439 - Configuration
Configure drpc.authorizer so that only trusted principals can reach the DRPC endpoints (required mitigation for users unable to upgrade immediately).
Apache Storm DRPC drpc.authorizer = (configure to allow only trusted principals) - Compensating control
Ensure the DRPC ports are not reachable from untrusted networks (network-level restriction to trusted sources only).
Event History
Frequently Asked Questions
Which deployments are exposed by default?
DRPC deployments with drpc.authorizer unset are exposed by default because the DRPC endpoint accepts requests without credentials. Exposure is especially significant when DRPC ports are reachable from untrusted networks.
What does an attacker need to exploit this issue?
An attacker only needs network access to a reachable DRPC endpoint when no authorizer is configured. They can send requests using arbitrarily many distinct function names; the names do not need to correspond to functions registered by a topology.
What happens after malicious requests are processed?
The request itself can be cleaned up, but the queue object and its function-name map entry remain for the life of the DRPC process. Repeated unique names permanently accumulate retained memory until the server exhausts its heap.
What can be done if an immediate upgrade is not possible?
Configure drpc.authorizer to limit DRPC access to trusted principals, and prevent untrusted networks from reaching DRPC ports. Upgrade to 3.1.0 when possible, which removes a function queue once it has no waiting requests.