Answer in brief
CVE-2026-49249 records a Unknown severity vulnerability in Boruta: Authenticated atom-exhaustion DoS in BorutaIdentityWeb.UserSettingsController.update/2. The current sources do not mark it as known exploited. The current feed maps malach-it/boruta-server (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps malach-it/boruta-server (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| malach-it/boruta-servergeneric | < 0.10.0 | Not reported |
Published upstream
Sep 2, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 2, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 2, 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.
Quoted source text, attributed separately from HOL analysis.