Boruta
Monthly
Authentication bypass via JWT assertion replay in malach-it Boruta (an Elixir OAuth 2.0/OpenID Connect provider) from 2.3.0 before 2.3.7 lets an attacker who captures any previously valid client assertion re-authenticate as that OAuth client indefinitely, because the token endpoint never checks the assertion's expiry. An attacker who harvests a signed client_secret_jwt or private_key_jwt assertion from logs, proxies, or browser tooling can mint access tokens carrying the victim client's privileges. No public exploit identified at time of analysis, though the fix commits and regression tests publicly demonstrate both the flawed and corrected behavior.
Privilege escalation via dynamic client registration in malach-it's Boruta OAuth 2.0/OpenID Connect provider library (Elixir) lets an unauthenticated registrant create OIDC clients that carry administrative security attributes. Because Boruta.Openid.register_client/3 forwards caller-supplied parameters straight into the administrative client-creation changeset with no public/admin allowlist, a self-registering client can dictate its own supported grant types, authorized scopes, PKCE enforcement, public refresh/revocation behavior, token lifetimes, and signing settings on versions 2.3.0 through 2.3.6. There is no public exploit identified at time of analysis and it is not in CISA KEV, but a vendor-released patch (2.3.7) is available.
Server-Side Request Forgery in Boruta (malach-it/boruta_auth versions 2.3.2 through 2.3.6) enables unauthenticated remote attackers to force the OAuth/OpenID authorization server to issue outbound HTTP requests to arbitrary attacker-controlled URIs, including cloud metadata endpoints (e.g., AWS IMDS at 169.254.169.254), internal APIs, and RFC 1918 network services. Three distinct code paths - OAuth request_uri handling, OpenID Connect dynamic client registration jwks_uri, and scheduled jwks_uri refresh - all invoke Elixir's Finch HTTP client against caller-supplied URIs with no host allowlist, no private IP rejection, no redirect constraint, and no response size cap. No public exploit has been identified at time of analysis; a vendor patch is available in version 2.3.7.
Authentication bypass via JWT assertion replay in malach-it Boruta (an Elixir OAuth 2.0/OpenID Connect provider) from 2.3.0 before 2.3.7 lets an attacker who captures any previously valid client assertion re-authenticate as that OAuth client indefinitely, because the token endpoint never checks the assertion's expiry. An attacker who harvests a signed client_secret_jwt or private_key_jwt assertion from logs, proxies, or browser tooling can mint access tokens carrying the victim client's privileges. No public exploit identified at time of analysis, though the fix commits and regression tests publicly demonstrate both the flawed and corrected behavior.
Privilege escalation via dynamic client registration in malach-it's Boruta OAuth 2.0/OpenID Connect provider library (Elixir) lets an unauthenticated registrant create OIDC clients that carry administrative security attributes. Because Boruta.Openid.register_client/3 forwards caller-supplied parameters straight into the administrative client-creation changeset with no public/admin allowlist, a self-registering client can dictate its own supported grant types, authorized scopes, PKCE enforcement, public refresh/revocation behavior, token lifetimes, and signing settings on versions 2.3.0 through 2.3.6. There is no public exploit identified at time of analysis and it is not in CISA KEV, but a vendor-released patch (2.3.7) is available.
Server-Side Request Forgery in Boruta (malach-it/boruta_auth versions 2.3.2 through 2.3.6) enables unauthenticated remote attackers to force the OAuth/OpenID authorization server to issue outbound HTTP requests to arbitrary attacker-controlled URIs, including cloud metadata endpoints (e.g., AWS IMDS at 169.254.169.254), internal APIs, and RFC 1918 network services. Three distinct code paths - OAuth request_uri handling, OpenID Connect dynamic client registration jwks_uri, and scheduled jwks_uri refresh - all invoke Elixir's Finch HTTP client against caller-supplied URIs with no host allowlist, no private IP rejection, no redirect constraint, and no response size cap. No public exploit has been identified at time of analysis; a vendor patch is available in version 2.3.7.