Boruta vulnerabilities

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.

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.

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.

Boruta, a standalone authorization server implementing OAuth 2.0 and OpenID Connect, prior to version 0.10.0 logged sensitive values in business event logs. These could include access tokens, refresh tokens, authorization codes, agent tokens, direct-post codes, ID tokens, VP tokens, and tokens submitted to introspection or revocation endpoints. An attacker with log access could recover these credentials and use them until expiration or revocation.

Boruta before version 0.10.0 atomizes every key of the user-supplied request body via String.to_atom/1 before validation. Because String.to_atom interns atoms permanently in the BEAM atom table (default cap 1,048,576 atoms), any authenticated user can exhaust the global VM atom table, causing the BEAM to abort and crash the entire OIDC server. Patched in version 0.10.0.