External risk intelligence

Multitenant Delegator Cache Denial of Service

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-74841

The vulnerability exists in LoginWorker and ContextFilter components responsible for processing authentication requests in multitenant applications. As these components handle incoming login traffic, they are typically exposed at the network edge to facilitate user access, making them commonly reachable in deployments where such web applications or API gateways are public-facing.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability has been identified in multitenant deployments that could lead to denial of service by consuming excessive memory and database resources. This issue arises from how tenant IDs are processed during authentication, allowing an unauthenticated attacker to overload the system by submitting a continuous stream of arbitrary tenant IDs. The main concern is confirming relevance and exposure.

Unauthenticated attackers can overload system resources.
It impacts authentication processes in multitenant systems.
Assess exposure to avoid unnecessary resource consumption.

Attack Path

How an attacker could exploit the issue

An unauthenticated attacker can target multitenant deployments by sending a stream of arbitrary tenant IDs to a vulnerable component. This action causes the system to build a delegator name from a user-supplied tenant ID before verifying the tenant's existence. The internal cache of the DelegatorFactory then stores these names, leading to an unbounded cache growth. This denial-of-service condition can result in significant memory and database load, impacting the application's availability.

No authentication required.
Arbitrary tenant IDs sent to components.
Exhausts memory and database resources.

Live Threat

Current exploitation, exposure, and threat context

In multitenant deployments, an unauthenticated attacker could exploit this vulnerability by sending a continuous stream of tenant IDs to exhaust system memory and database resources. This occurs because the system attempts to resolve a delegator name using a user-supplied tenant ID before verifying the tenant's existence, leading to an unbounded cache growth.

Tenant delegator names could be exposed.
Arbitrary tenant IDs may be submitted.
Unnecessary memory and database load.

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts multitenant deployments. The platform or infrastructure team is likely responsible for managing the underlying systems where ContextFilter and LoginWorker reside. They should identify all instances of this technology, determine their business criticality and network exposure, and locate the accountable system owner. Planning for remediation should then be risk-based.

Platform/Infrastructure teams own resolution.
Verify all affected systems are inventoried.
Plan remediation based on exposure.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the role of ContextFilter and LoginWorker in this software?

ContextFilter and LoginWorker are core components within multitenant applications that handle incoming authentication traffic. They manage user requests and resolve delegators—the internal mechanisms that route data or actions to the correct specific tenant—during the login process.

How does CVE-2026-74841 cause a system failure?

This vulnerability involves Uncontrolled Resource Consumption (CWE-400 and CWE-770). The system attempts to process a delegator name based on a user-provided tenant ID before verifying if that tenant actually exists. Because the application caches these requests even when they fail, an attacker can force the system to store an infinite number of invalid entries, eventually exhausting available memory and database capacity.

Do I need to be authenticated to trigger this cache growth?

No. The vulnerability exists in the pre-authentication layer of the software. An attacker does not need legitimate credentials or an existing account to send the malicious requests. Simply interacting with the login interface using a high volume of arbitrary, non-existent tenant IDs is sufficient to initiate the cache saturation.

Why is this a concern for my internet-facing infrastructure?

According to Halo Surface Signal, these components typically reside at the network edge to facilitate user access in multitenant environments. If your application is public-facing, it is directly reachable by external actors who can reach these login processes over the network, significantly increasing the likelihood of resource exhaustion attacks.

When should I begin addressing this CVE?

You should prioritize identifying all deployments of this technology immediately. Since the fix involves infrastructure-level changes to how tenant requests are validated, work with your platform or system owners to map your application inventory, determine which instances face the internet, and plan a risk-based remediation strategy.

References

lists.apache.org/thread.html/7b2syzksp7klt9fvhdg0olldvs2g83lz

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.