Boruta CVE-2026-54885

Path 1 (OAuth request_uri): Requires access to the OAuth authorization endpoint and the ability to submit an authorization request with a request_uri parameter. This path is unauthenticated and available against any deployment supporting OAuth 2.0 authorization code flow with request_uri; one code clause does not restrict URI scheme, permitting non-HTTP schemes. Path 2 (OpenID Connect dynamic client registration jwks_uri): Requires dynamic client registration to be enabled - this is a configurable feature, not universally enabled by default, but when active requires no authentication or prior client credentials. Path 3 (jwks_uri refresh): Requires that an attacker has previously registered or modified a client with a malicious jwks_uri, meaning prior authenticated access or exploitation of path 2 is a prerequisite. Shared limiting factor across all paths: the Boruta server must have network reachability to the target URI from its host environment; attackers cannot reach targets the server itself cannot reach.

The CVSS 4.0 score of 6.9 (Medium) correctly models SSRF impact: the vulnerable system (the Boruta server) itself has no confidentiality, integrity, or availability impact (VC:N/VI:N/VA:N), but subsequent systems reachable from the Boruta host carry Low confidentiality and integrity impact (SC:L/SI:L). Real-world severity is highly deployment-context-dependent. In cloud-hosted environments where the Boruta host can reach the Instance Metadata Service (IMDS) at 169.254.169.254, an unauthenticated attacker could potentially retrieve IAM credentials or instance identity documents, elevating practical impact well beyond the rated score. The no-auth, no-complexity, network-accessible nature of path 1 (request_uri) is particularly concerning because it requires no prior client relationship. Path 2 (dynamic client registration) is similarly unauthenticated if the feature is enabled but is not universally deployed. Path 3 (jwks_uri refresh) requires prior client registration, reducing its unauthenticated exposure. No KEV listing and no EPSS data were provided; no public exploit code has been identified. The three independent code paths mean that remediating one path without upgrading leaves the others open.

An unauthenticated attacker sends an OAuth 2.0 authorization request to the Boruta server's authorization endpoint with the request_uri parameter set to http://169.254.169.254/latest/meta-data/iam/security-credentials/ - a cloud IMDS endpoint reachable from the server host. Boruta's fetch_unsigned_request/1 invokes Finch to retrieve that URI without any host or IP validation, and the IMDS response (containing IAM role credentials or instance metadata) is processed by the server. Alternatively, on deployments with dynamic client registration enabled, the attacker registers a new OIDC client specifying a jwks_uri pointing to an internal service, causing the server to probe that endpoint during registration. No public proof-of-concept code has been identified at time of analysis.