CVE-2026-54885
ŚrednieCVSS 6.9Streszczenie
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.
Ocena ryzyka
Ryzyko obejmuje możliwość skanowania sieci wewnętrznej, dostępu do metadanych chmury (np. poświadczeń) oraz ataków na inne wewnętrzne usługi, co może prowadzić do naruszenia poufności i integralności systemu.
Rekomendacja
Należy zaktualizować Boruta do wersji 2.3.7 lub nowszej, która zawiera poprawkę. Jako tymczasowe obejście można ograniczyć wychodzący ruch HTTP z serwera Boruta.
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-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.
Oryginalny opis (angielski, źródło NVD)
Server-Side Request Forgery vulnerability in malach-it Boruta allows an unauthenticated remote attacker to cause the OAuth/OpenID authorization server to issue outbound HTTP requests to attacker-chosen URIs, including internal services and cloud metadata endpoints. Three code paths fetch remote URIs supplied by the requester without sufficient validation of the target. Boruta.Oauth.Request.Base.fetch_unsigned_request/1 in lib/boruta/oauth/request/base.ex dereferences the OAuth request_uri parameter from the authorization request via Finch.build(:get, request_uri) |> Finch.request(OpenIDHttpClient). Boruta.Openid.parse_registration_params/2 in lib/boruta/openid.ex dereferences the jwks_uri supplied in an OpenID Connect dynamic client registration request. Boruta.Ecto.Clients.refresh_jwk_from_jwks_uri/1 in lib/boruta/adapters/ecto/clients.ex later refreshes the stored jwks_uri for an existing client. In all three paths the only validation is that the URI parses with a scheme (and one of the two request_uri clauses does not even restrict the scheme to http or https). The implementations do not require HTTPS, do not enforce a host or IP allowlist, do not reject loopback, private, link-local, or other non-public ranges after DNS resolution, do not cap response size, and do not constrain redirects. An attacker can therefore steer the server's HTTP client at arbitrary network targets reachable from the Boruta host. This issue affects boruta: from 2.3.2 before 2.3.7.