CVE-2026-54885 in boruta
Summary
by MITRE • 07/30/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/30/2026
This Server-Side Request Forgery vulnerability in malach-it Boruta represents a critical security flaw that allows unauthenticated remote attackers to manipulate the OAuth/OpenID authorization server into making arbitrary outbound HTTP requests. The vulnerability stems from insufficient input validation mechanisms within three distinct code paths that process remote URI references. The primary attack vector involves the Boruta.Oauth.Request.Base.fetch_unsigned_request/1 function in lib/boruta/oauth/request/base.ex which directly dereferences the OAuth request_uri parameter through Finch.build(:get, request_uri) |> Finch.request(OpenIDHttpClient), creating a pathway for attackers to specify arbitrary destinations for outbound requests. Additionally, Boruta.Openid.parse_registration_params/2 in lib/boruta/openid.ex processes the jwks_uri parameter from OpenID Connect dynamic client registration requests without proper validation, while Boruta.Ecto.Clients.refresh_jwk_from_jwks_uri/1 in lib/boruta/adapters/ecto/clients.ex handles stored jwks_uri values for existing clients through a similar unvalidated dereferencing mechanism. These code paths collectively demonstrate a fundamental failure in implementing proper URI validation and sanitization controls.
The technical implementation lacks essential security measures that would normally prevent such vulnerabilities. Each code path performs minimal validation, essentially only checking if the URI parses with a scheme without restricting the scheme to secure protocols like https. The absence of HTTPS enforcement, host or IP allowlisting, and rejection of non-public network ranges such as loopback addresses, private networks, and link-local addresses creates an exploitable attack surface. Furthermore, the implementation does not impose response size limitations, nor does it constrain HTTP redirects, allowing attackers to potentially exhaust server resources or chain multiple requests through redirect loops. This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF) which specifically addresses insecure direct object references that allow attackers to manipulate server-side requests.
The operational impact of this vulnerability extends beyond simple data exfiltration, as it provides attackers with potential access to internal services and cloud metadata endpoints that the Boruta server can reach. Attackers could potentially enumerate internal network resources, access sensitive configuration information, or even exploit misconfigured internal services that are not exposed to the public internet. The vulnerability affects all versions from 2.3.2 through 2.3.6, representing a significant risk to organizations relying on Boruta for OAuth/OpenID Connect authentication services. This issue maps directly to ATT&CK technique T1566.002 for Server-Side Request Forgery attacks and demonstrates how insufficient input validation can lead to privilege escalation and lateral movement within network environments.
Mitigation strategies should focus on implementing strict URI validation across all three vulnerable code paths, enforcing HTTPS requirements for all external references, and establishing comprehensive host/IP allowlists that exclude private and non-public network ranges. Organizations should implement response size limits and redirect constraints to prevent resource exhaustion attacks. The fix should include DNS resolution validation to reject loopback and private address ranges, implement proper input sanitization, and establish a secure HTTP client configuration that enforces security policies at the network level. Additionally, organizations should consider implementing network segmentation and firewall rules to limit outbound connections from the Boruta server, reducing the potential impact of any successful exploitation attempts while maintaining the system's legitimate functionality.