CVE-2026-54885
MediumCVSS 6.9Summary
An SSRF vulnerability in the Boruta library (versions 2.3.2 through 2.3.7) allows an unauthenticated attacker to force the OAuth/OpenID authorization server to send HTTP requests to arbitrary URIs, including internal services and cloud metadata endpoints. The vulnerability exists in three code paths that do not properly validate target URIs.
Risk Assessment
The risk includes internal network scanning, access to cloud metadata (e.g., credentials), and attacks on other internal services, potentially leading to confidentiality and integrity breaches.
Recommendation
Upgrade Boruta to version 2.3.7 or later, which contains the fix. As a temporary workaround, restrict outbound HTTP traffic from the Boruta server.
Other vulnerabilities in Boruta
See all- CVE-2026-65635High
The Boruta library in Elixir has an improper isolation vulnerability allowing unauthenticated attackers to register OpenID Connect clients with administrative privileges. The lack of an allowlist lets attackers set sensitive attributes like grant types, scopes, PKCE enforcement, and token lifetimes.
- CVE-2026-53431Critical
Authentication bypass by capture-replay vulnerability in malach-it Boruta allows an attacker who has obtained a previously valid JWT client assertion to authenticate as the issuing OAuth client after the assertion has expired. Boruta does not enforce the exp claim check, allowing replay attacks.
Original NVD description (English source)
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.