CVE-2026-49249 in Boruta Server
Summary
by MITRE • 09/02/2026
Boruta is a standalone authorization server that aims to implement OAuth 2.0 and Openid Connect up to decentralized identity specifications. Prior to version 0.10.0, BorutaIdentityWeb.UserSettingsController.update/2 atomizes every key of the user-supplied request body via String.to_atom/1 before any validation. Because String.to_atom interns atoms permanently in the BEAM atom table (default cap 1,048,576 atoms; ERL_MAX_ATOMS), any authenticated end user can send PUT /users/settings with a user[<fresh-key>]=... body containing fresh keys per request and exhaust the global VM atom table. Once the table is full, the BEAM aborts with no more index entries in atom_tab and the entire OIDC server (auth, admin, gateway apps in the umbrella) crashes. The route is protected only by require_authenticated_user and a per-IP rate limit of 10 requests/second; a logged-in end user can hit it. The keys are atomized unconditionally before the downstream Accounts.update_user/6 call, so even failing updates contribute to exhaustion. This issue has been patched in version 0.10.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified as CVE-2024-Boruta-AtoMEx involves a critical resource exhaustion flaw within the Boruta authorization server, specifically affecting versions prior to 0.10.0. This standalone service implements OAuth 2.0 and OpenID Connect specifications for decentralized identity management. The core technical defect resides in the UserSettingsController.update/2 function, which processes user-supplied request bodies by converting every key into an Elixir atom using String.to_atom/1 prior to any form of validation or sanitization. This design choice is fundamentally flawed because it ignores the immutable nature and limited capacity of atoms within the BEAM virtual machine environment. In Erlang-based systems like those running on the BEAM, atoms are permanently interned in a global atom table with a default maximum limit of 1,048,576 entries. Once this cap is reached via ERL_MAX_ATOMS configuration or system limits, no new atoms can be created, leading to catastrophic failure of the virtual machine runtime.
The operational impact of this vulnerability allows any authenticated end user to trigger a Denial of Service attack against the entire OIDC server infrastructure. By sending PUT requests to /users/settings with request bodies containing fresh, unique keys in each iteration, an attacker can systematically exhaust the global VM atom table. The route is protected only by basic authentication requiring a logged-in user and a per-IP rate limit of ten requests per second; however, this rate limiting is insufficient to prevent exhaustion given that even failed updates contribute to the accumulation of atoms since the conversion occurs unconditionally before downstream validation logic in Accounts.update_user/6 executes. Consequently, once the atom table reaches its capacity threshold, the BEAM runtime aborts with an error indicating no more index entries are available in the atom_tab data structure. This results in a complete crash of the authentication server, including all associated applications within the umbrella project such as auth, admin, and gateway services, effectively rendering the identity provider unavailable to all users.
From a classification perspective, this vulnerability aligns with CWE-787 Out-of-bounds Write or Resource Exhaustion depending on specific implementation details, but more accurately fits CWE-400 Uncontrolled Resource Consumption due to the unbounded allocation of system resources based on user input. In terms of attack patterns, it corresponds to ATT&CK technique T1496 Resource Hijacking, specifically subcomponent resource exhaustion, where an adversary consumes limited computational resources to degrade service availability for legitimate users. The lack of validation before atom creation represents a failure in input sanitization and boundary checking, which are fundamental principles in secure coding practices for stateful applications interacting with low-level runtime environments.
Mitigation strategies must focus on preventing the uncontrolled generation of atoms from external inputs. For existing deployments running versions prior to 0.10.0, immediate patching is required as this issue has been resolved in version 0.10.0 by modifying the controller logic to validate and sanitize keys before attempting atom conversion or avoiding atomization entirely for dynamic user data. Developers should implement strict allowlists for expected parameter names rather than dynamically converting arbitrary input strings into atoms. Additionally, increasing ERL_MAX_ATOMS is not a viable long-term solution as it only delays the inevitable crash without addressing the root cause of unbounded resource consumption. Implementing stricter rate limiting that accounts for atom allocation costs and adding monitoring alerts for atom table usage levels can provide temporary resilience while migration to patched versions occurs.