CVE-2026-49249
WysokieCVSS 7.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 14 - wyżej niż 14% wszystkich znanych CVE
Streszczenie
Boruta przed wersją 0.10.0 w kontrolerze UserSettingsController.update/2 atomizuje każdy klucz z ciała żądania przez String.to_atom/1 przed walidacją. Ponieważ String.to_atom trwale internuje atomy w tablicy atomów BEAM (domyślnie 1 048 576 atomów), każdy uwierzytelniony użytkownik może wysłać PUT /users/settings z nowymi kluczami, wyczerpując globalną tablicę atomów. Gdy tablica jest pełna, BEAM przerywa działanie, powodując awarię całego serwera OIDC. Problem naprawiono w wersji 0.10.0.
Ocena ryzyka
Uwierzytelniony użytkownik może spowodować awarię całego serwera autoryzacyjnego, prowadząc do odmowy usługi.
Rekomendacja
Zaktualizuj Boruta do wersji 0.10.0 lub nowszej.
Inne podatności w Boruta
Zobacz wszystkie- CVE-2026-65635Wysokie
Biblioteka Boruta w języku Elixir zawiera lukę w mechanizmie izolacji, która pozwala nieuwierzytelnionemu atakującemu na rejestrację klientów OpenID Connect z uprawnieniami administracyjnymi. Brak listy dozwolonych pól powoduje, że atakujący może ustawić wrażliwe atrybuty, takie jak typy grantów, zakresy, wymuszanie PKCE czy czasy życia tokenów.
- CVE-2026-54885Średnie
Podatność SSRF (Server-Side Request Forgery) w bibliotece Boruta (wersje od 2.3.2 do 2.3.7) pozwala nieuwierzytelnionemu atakującemu na zmuszenie serwera autoryzacyjnego OAuth/OpenID do wysyłania żądań HTTP do dowolnych URI, w tym do usług wewnętrznych i endpointów metadanych chmury. Podatność występuje w trzech ścieżkach kodu, które nie walidują odpowiednio docelowych URI.
- CVE-2026-53431Krytyczne
Podatność na obejście uwierzytelniania przez przechwytywanie i odtwarzanie w bibliotece Boruta firmy malach-it umożliwia atakującemu, który uzyskał wcześniej ważne asercje JWT klienta, uwierzytelnienie jako klient OAuth po wygaśnięciu asercji. Boruta nie wymusza sprawdzania pola exp w asercjach JWT, co pozwala na ich wielokrotne użycie.
- CVE-2026-55221Średnie
Boruta, samodzielny serwer autoryzacyjny implementujący OAuth 2.0 i OpenID Connect, przed wersją 0.10.0 logował wrażliwe wartości w dziennikach zdarzeń biznesowych. Mogły to być tokeny dostępu, odświeżania, autoryzacyjne, agenta, kody direct-post, tokeny ID, VP oraz tokeny przesyłane do punktów introspection lub revocation. Osoba z dostępem do logów mogła odzyskać te poświadczenia i używać ich do wygaśnięcia lub unieważnienia.
Oryginalny opis (angielski, źródło NVD)
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.