boruta
A yet complex but OpenID™ certified OAuth / OpenID Connect provider core
View on Github
Activity
- Latest release
- 1mo ago
- Total releases
- 46
- Cadence
- ~30 days
- Last 12 months
- 3
Reach
- Downloads
- 478.2k
- Stars
- 93
Details
- License
- MIT
- First release
- Aug 01, 2019
| Version | Released | |
|---|---|---|
2.3.8
patch
| ||
2.3.7
patch
| ||
2.3.6
patch
3 CVEs
CVE-2026-53431
EEF-CVE-2026-53431
GHSA-xjv8-vmh5-xhf6
Jul 30, 2026
Boruta accepts expired JWT client assertions due to missing exp claim validation
Critical
Network
Low
None
None
SummaryAuthentication 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 accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion's exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken's default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client's privileges. This issue affects boruta: from 2.3.0 before 2.3.7. WorkaroundsRestrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay. ConfigurationsThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-65635
EEF-CVE-2026-65635
GHSA-w869-fcf2-68vp
Jul 30, 2026
Boruta dynamic client registration allows creation of over-privileged OAuth clients
High
Network
Low
None
None
SummaryImproper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval. This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2. This issue affects boruta from 2.3.0 before 2.3.7. WorkaroundsDisable the dynamic client registration route or restrict it to authenticated administrators. If dynamic registration must remain available to untrusted callers, do not forward the request parameters to Boruta.Openid.register_client/3 directly. Instead, construct a new parameter map in the host application that contains only the standards-defined public metadata (such as redirect URIs, client name, logo, and contacts) and overwrite every administrative attribute (supported grant types, authorized scopes, PKCE flag, public refresh and revocation flags, token lifetimes, signing settings, token endpoint authentication method) with values from a fixed least-privilege server-side profile before calling the function. ConfigurationsA deployment is vulnerable when the host application exposes Boruta.Openid.register_client/3 on a network endpoint without requiring a trusted initial access token and without a strict server-side allowlist that prevents caller-supplied administrative attributes from reaching the underlying changeset. The standard controller generator does not install a dynamic client registration route, so deployments that never call Boruta.Openid.register_client/3 from a public endpoint are not exploitable. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-54885
EEF-CVE-2026-54885
GHSA-5q9h-vf5j-fr2g
Jul 30, 2026
Server-side request forgery in Boruta OAuth request_uri and OpenID jwks_uri fetching
Low
Network
Low
None
None
SummaryServer-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. WorkaroundsRestrict the network egress of the Boruta host so that the OAuth/OpenID authorization server cannot reach loopback, private, link-local, multicast, or cloud metadata addresses. Where possible, disable application routes for OAuth request_uri dereferencing and OpenID Connect dynamic client registration, or restrict OpenID Connect dynamic client registration to trusted callers, until a patched release is deployed. Affected versions
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev | ||
3.0.0-beta.4
pre
|
3.0.0-beta.4
pre
Dependencies (14)
+ 6 more
Changelog
Compare changes
|
|
2.3.5
patch
3 CVEs
CVE-2026-53431
EEF-CVE-2026-53431
GHSA-xjv8-vmh5-xhf6
Jul 30, 2026
Boruta accepts expired JWT client assertions due to missing exp claim validation
Critical
Network
Low
None
None
SummaryAuthentication 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 accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion's exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken's default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client's privileges. This issue affects boruta: from 2.3.0 before 2.3.7. WorkaroundsRestrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay. ConfigurationsThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-65635
EEF-CVE-2026-65635
GHSA-w869-fcf2-68vp
Jul 30, 2026
Boruta dynamic client registration allows creation of over-privileged OAuth clients
High
Network
Low
None
None
SummaryImproper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval. This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2. This issue affects boruta from 2.3.0 before 2.3.7. WorkaroundsDisable the dynamic client registration route or restrict it to authenticated administrators. If dynamic registration must remain available to untrusted callers, do not forward the request parameters to Boruta.Openid.register_client/3 directly. Instead, construct a new parameter map in the host application that contains only the standards-defined public metadata (such as redirect URIs, client name, logo, and contacts) and overwrite every administrative attribute (supported grant types, authorized scopes, PKCE flag, public refresh and revocation flags, token lifetimes, signing settings, token endpoint authentication method) with values from a fixed least-privilege server-side profile before calling the function. ConfigurationsA deployment is vulnerable when the host application exposes Boruta.Openid.register_client/3 on a network endpoint without requiring a trusted initial access token and without a strict server-side allowlist that prevents caller-supplied administrative attributes from reaching the underlying changeset. The standard controller generator does not install a dynamic client registration route, so deployments that never call Boruta.Openid.register_client/3 from a public endpoint are not exploitable. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-54885
EEF-CVE-2026-54885
GHSA-5q9h-vf5j-fr2g
Jul 30, 2026
Server-side request forgery in Boruta OAuth request_uri and OpenID jwks_uri fetching
Low
Network
Low
None
None
SummaryServer-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. WorkaroundsRestrict the network egress of the Boruta host so that the OAuth/OpenID authorization server cannot reach loopback, private, link-local, multicast, or cloud metadata addresses. Where possible, disable application routes for OAuth request_uri dereferencing and OpenID Connect dynamic client registration, or restrict OpenID Connect dynamic client registration to trusted callers, until a patched release is deployed. Affected versions
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev | ||
3.0.0-beta.3
pre
| ||
3.0.0-beta.2
pre
| ||
3.0.0-beta.1
pre
| ||
2.3.4
patch
3 CVEs
CVE-2026-53431
EEF-CVE-2026-53431
GHSA-xjv8-vmh5-xhf6
Jul 30, 2026
Boruta accepts expired JWT client assertions due to missing exp claim validation
Critical
Network
Low
None
None
SummaryAuthentication 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 accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion's exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken's default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client's privileges. This issue affects boruta: from 2.3.0 before 2.3.7. WorkaroundsRestrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay. ConfigurationsThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-65635
EEF-CVE-2026-65635
GHSA-w869-fcf2-68vp
Jul 30, 2026
Boruta dynamic client registration allows creation of over-privileged OAuth clients
High
Network
Low
None
None
SummaryImproper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval. This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2. This issue affects boruta from 2.3.0 before 2.3.7. WorkaroundsDisable the dynamic client registration route or restrict it to authenticated administrators. If dynamic registration must remain available to untrusted callers, do not forward the request parameters to Boruta.Openid.register_client/3 directly. Instead, construct a new parameter map in the host application that contains only the standards-defined public metadata (such as redirect URIs, client name, logo, and contacts) and overwrite every administrative attribute (supported grant types, authorized scopes, PKCE flag, public refresh and revocation flags, token lifetimes, signing settings, token endpoint authentication method) with values from a fixed least-privilege server-side profile before calling the function. ConfigurationsA deployment is vulnerable when the host application exposes Boruta.Openid.register_client/3 on a network endpoint without requiring a trusted initial access token and without a strict server-side allowlist that prevents caller-supplied administrative attributes from reaching the underlying changeset. The standard controller generator does not install a dynamic client registration route, so deployments that never call Boruta.Openid.register_client/3 from a public endpoint are not exploitable. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-54885
EEF-CVE-2026-54885
GHSA-5q9h-vf5j-fr2g
Jul 30, 2026
Server-side request forgery in Boruta OAuth request_uri and OpenID jwks_uri fetching
Low
Network
Low
None
None
SummaryServer-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. WorkaroundsRestrict the network egress of the Boruta host so that the OAuth/OpenID authorization server cannot reach loopback, private, link-local, multicast, or cloud metadata addresses. Where possible, disable application routes for OAuth request_uri dereferencing and OpenID Connect dynamic client registration, or restrict OpenID Connect dynamic client registration to trusted callers, until a patched release is deployed. Affected versions
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev | ||
2.3.3
patch
3 CVEs
CVE-2026-53431
EEF-CVE-2026-53431
GHSA-xjv8-vmh5-xhf6
Jul 30, 2026
Boruta accepts expired JWT client assertions due to missing exp claim validation
Critical
Network
Low
None
None
SummaryAuthentication 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 accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion's exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken's default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client's privileges. This issue affects boruta: from 2.3.0 before 2.3.7. WorkaroundsRestrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay. ConfigurationsThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-65635
EEF-CVE-2026-65635
GHSA-w869-fcf2-68vp
Jul 30, 2026
Boruta dynamic client registration allows creation of over-privileged OAuth clients
High
Network
Low
None
None
SummaryImproper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval. This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2. This issue affects boruta from 2.3.0 before 2.3.7. WorkaroundsDisable the dynamic client registration route or restrict it to authenticated administrators. If dynamic registration must remain available to untrusted callers, do not forward the request parameters to Boruta.Openid.register_client/3 directly. Instead, construct a new parameter map in the host application that contains only the standards-defined public metadata (such as redirect URIs, client name, logo, and contacts) and overwrite every administrative attribute (supported grant types, authorized scopes, PKCE flag, public refresh and revocation flags, token lifetimes, signing settings, token endpoint authentication method) with values from a fixed least-privilege server-side profile before calling the function. ConfigurationsA deployment is vulnerable when the host application exposes Boruta.Openid.register_client/3 on a network endpoint without requiring a trusted initial access token and without a strict server-side allowlist that prevents caller-supplied administrative attributes from reaching the underlying changeset. The standard controller generator does not install a dynamic client registration route, so deployments that never call Boruta.Openid.register_client/3 from a public endpoint are not exploitable. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-54885
EEF-CVE-2026-54885
GHSA-5q9h-vf5j-fr2g
Jul 30, 2026
Server-side request forgery in Boruta OAuth request_uri and OpenID jwks_uri fetching
Low
Network
Low
None
None
SummaryServer-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. WorkaroundsRestrict the network egress of the Boruta host so that the OAuth/OpenID authorization server cannot reach loopback, private, link-local, multicast, or cloud metadata addresses. Where possible, disable application routes for OAuth request_uri dereferencing and OpenID Connect dynamic client registration, or restrict OpenID Connect dynamic client registration to trusted callers, until a patched release is deployed. Affected versions
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev | ||
2.3.2
patch
3 CVEs
CVE-2026-53431
EEF-CVE-2026-53431
GHSA-xjv8-vmh5-xhf6
Jul 30, 2026
Boruta accepts expired JWT client assertions due to missing exp claim validation
Critical
Network
Low
None
None
SummaryAuthentication 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 accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion's exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken's default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client's privileges. This issue affects boruta: from 2.3.0 before 2.3.7. WorkaroundsRestrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay. ConfigurationsThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-65635
EEF-CVE-2026-65635
GHSA-w869-fcf2-68vp
Jul 30, 2026
Boruta dynamic client registration allows creation of over-privileged OAuth clients
High
Network
Low
None
None
SummaryImproper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval. This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2. This issue affects boruta from 2.3.0 before 2.3.7. WorkaroundsDisable the dynamic client registration route or restrict it to authenticated administrators. If dynamic registration must remain available to untrusted callers, do not forward the request parameters to Boruta.Openid.register_client/3 directly. Instead, construct a new parameter map in the host application that contains only the standards-defined public metadata (such as redirect URIs, client name, logo, and contacts) and overwrite every administrative attribute (supported grant types, authorized scopes, PKCE flag, public refresh and revocation flags, token lifetimes, signing settings, token endpoint authentication method) with values from a fixed least-privilege server-side profile before calling the function. ConfigurationsA deployment is vulnerable when the host application exposes Boruta.Openid.register_client/3 on a network endpoint without requiring a trusted initial access token and without a strict server-side allowlist that prevents caller-supplied administrative attributes from reaching the underlying changeset. The standard controller generator does not install a dynamic client registration route, so deployments that never call Boruta.Openid.register_client/3 from a public endpoint are not exploitable. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-54885
EEF-CVE-2026-54885
GHSA-5q9h-vf5j-fr2g
Jul 30, 2026
Server-side request forgery in Boruta OAuth request_uri and OpenID jwks_uri fetching
Low
Network
Low
None
None
SummaryServer-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. WorkaroundsRestrict the network egress of the Boruta host so that the OAuth/OpenID authorization server cannot reach loopback, private, link-local, multicast, or cloud metadata addresses. Where possible, disable application routes for OAuth request_uri dereferencing and OpenID Connect dynamic client registration, or restrict OpenID Connect dynamic client registration to trusted callers, until a patched release is deployed. Affected versions
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev | ||
2.3.1
patch
2 CVEs
CVE-2026-53431
EEF-CVE-2026-53431
GHSA-xjv8-vmh5-xhf6
Jul 30, 2026
Boruta accepts expired JWT client assertions due to missing exp claim validation
Critical
Network
Low
None
None
SummaryAuthentication 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 accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion's exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken's default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client's privileges. This issue affects boruta: from 2.3.0 before 2.3.7. WorkaroundsRestrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay. ConfigurationsThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-65635
EEF-CVE-2026-65635
GHSA-w869-fcf2-68vp
Jul 30, 2026
Boruta dynamic client registration allows creation of over-privileged OAuth clients
High
Network
Low
None
None
SummaryImproper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval. This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2. This issue affects boruta from 2.3.0 before 2.3.7. WorkaroundsDisable the dynamic client registration route or restrict it to authenticated administrators. If dynamic registration must remain available to untrusted callers, do not forward the request parameters to Boruta.Openid.register_client/3 directly. Instead, construct a new parameter map in the host application that contains only the standards-defined public metadata (such as redirect URIs, client name, logo, and contacts) and overwrite every administrative attribute (supported grant types, authorized scopes, PKCE flag, public refresh and revocation flags, token lifetimes, signing settings, token endpoint authentication method) with values from a fixed least-privilege server-side profile before calling the function. ConfigurationsA deployment is vulnerable when the host application exposes Boruta.Openid.register_client/3 on a network endpoint without requiring a trusted initial access token and without a strict server-side allowlist that prevents caller-supplied administrative attributes from reaching the underlying changeset. The standard controller generator does not install a dynamic client registration route, so deployments that never call Boruta.Openid.register_client/3 from a public endpoint are not exploitable. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev | ||
2.3.0
minor
2 CVEs
CVE-2026-53431
EEF-CVE-2026-53431
GHSA-xjv8-vmh5-xhf6
Jul 30, 2026
Boruta accepts expired JWT client assertions due to missing exp claim validation
Critical
Network
Low
None
None
SummaryAuthentication 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 accepts JWT-based client authentication (client_secret_jwt and private_key_jwt token endpoint authentication methods) but never enforces that the assertion's exp claim is in the future. The pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only verifies that an exp claim is present (it pattern-matches on the existence of the key and returns success), and the Joken token configuration used for signature verification, Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex, returns an empty map, so Joken's default exp claim validator is not engaged either. Any attacker who obtains a validly-signed client assertion (for example through logs, reverse proxies, browser tooling, or other observability surfaces) can replay it indefinitely to authenticate as the client and obtain access tokens with that client's privileges. This issue affects boruta: from 2.3.0 before 2.3.7. WorkaroundsRestrict the use of JWT-based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients, and prefer non-JWT client authentication methods (client_secret_basic or client_secret_post) where possible. Where JWT client authentication must remain enabled, issue short-lived client assertions and protect them from exposure in application logs, fronting proxies, browser tooling, and observability systems to reduce the window for replay. ConfigurationsThe attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev
CVE-2026-65635
EEF-CVE-2026-65635
GHSA-w869-fcf2-68vp
Jul 30, 2026
Boruta dynamic client registration allows creation of over-privileged OAuth clients
High
Network
Low
None
None
SummaryImproper Isolation or Compartmentalization vulnerability in malach-it boruta (Elixir.Boruta.Openid module) allows attackers to register OpenID Connect clients with administrative privileges through the dynamic client registration entry point. Boruta.Openid.register_client/3 forwards caller-supplied registration parameters to the administrative client creation path without a public/admin field-level allowlist, so an unauthenticated registrant can set security-sensitive attributes including supported grant types, authorized scopes, PKCE enforcement, public refresh and revocation behavior, token lifetimes, and signing settings. The library does not distinguish between metadata a public registrant is allowed to set and administrative controls that should require operator approval. This vulnerability is associated with program files lib/boruta/openid.ex and program routines 'Elixir.Boruta.Openid':register_client/3, 'Elixir.Boruta.Openid':parse_registration_params/2. This issue affects boruta from 2.3.0 before 2.3.7. WorkaroundsDisable the dynamic client registration route or restrict it to authenticated administrators. If dynamic registration must remain available to untrusted callers, do not forward the request parameters to Boruta.Openid.register_client/3 directly. Instead, construct a new parameter map in the host application that contains only the standards-defined public metadata (such as redirect URIs, client name, logo, and contacts) and overwrite every administrative attribute (supported grant types, authorized scopes, PKCE flag, public refresh and revocation flags, token lifetimes, signing settings, token endpoint authentication method) with values from a fixed least-privilege server-side profile before calling the function. ConfigurationsA deployment is vulnerable when the host application exposes Boruta.Openid.register_client/3 on a network endpoint without requiring a trusted initial access token and without a strict server-side allowlist that prevents caller-supplied administrative attributes from reaching the underlying changeset. The standard controller generator does not install a dynamic client registration route, so deployments that never call Boruta.Openid.register_client/3 from a public endpoint are not exploitable. Affected versions
2.3.0
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
Fixed in
2.3.7
References
Updated Sep 08, 2026 · Source: OSV.dev | ||
2.2.2
patch
| ||
2.2.1
patch
| ||
2.2.0
minor
| ||
2.1.5
patch
| ||
2.1.4
patch
| ||
2.1.3
patch
| ||
2.1.2
patch
| ||
2.1.1
patch
| ||
2.1.0
minor
| ||
2.0.1
patch
| ||
2.0.0
major
| ||
2.0.0-rc.1
pre
| ||
2.0.0-rc.0
pre
| ||
1.2.1
patch
| ||
1.2.0
minor
| ||
1.1.0
minor
| ||
1.0.3
patch
| ||
1.0.2
patch
| ||
1.0.1
patch
| ||
1.0.0
major
| ||
0.2.1
patch
| ||
1.0.0-rc.3
pre
| ||
1.0.0-rc.2
pre
| ||
1.0.0-rc.1
pre
| ||
1.0.0-rc.0
pre
| ||
0.2.0
minor
| ||
0.1.1
patch
| ||
0.1.0
initial
| ||
0.1.0-rc.5
pre
| ||
0.1.0-rc.4
pre
| ||
0.1.0-rc.3
pre
| ||
0.1.0-rc.2
pre
| ||
0.1.0-rc.1
pre
|