CVE-2026-74841 · Other
NO FIX YET
In multitenant deployments, the login and context filters build a per-tenant delegator name from a request-supplied tenant ID and request it before checking the tenant exists. The delegator factory caches every name it is asked for, including failed lookups, so an unauthenticated attacker can send many arbitrary tenant IDs to drive unbounded memory and database load.
first public Nov 5, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Only deployments running in multitenant mode are described as exposed, since the per-tenant delegator lookup is in the multitenant request path. Single-tenant deployments are not described as affected. The sources do not name the product or versions, so the team must confirm whether its deployment uses this multitenant login path.
Not affected if single-tenant
Who cares multitenant, self-hosted
Unknown from the sources.
No fix yet, per the sources.
In multitenant deployments, ContextFilter and LoginWorker built a per-tenant delegator name from a request-supplied userTenantId parameter and requested a delegator for it before confirming the tenant existed. DelegatorFactory's internal cache retains every delegator name it is asked to resolve, including ones that fail to resolve, so an unauthenticated attacker could submit a stream of arbitrary tenant IDs to grow this cache without bound, driving unnecessary memory and database load.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.