CVE-2026-53431
CriticalCVSS 9.1Summary
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.
Risk Assessment
An attacker can replay captured JWT assertions to authenticate as an OAuth client and obtain access tokens with its privileges, leading to unauthorized access to resources.
Recommendation
Immediately upgrade Boruta to version 2.3.7 or later, which enforces assertion expiration checks.
Other vulnerabilities in Boruta
See all- CVE-2026-65635High
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.
- CVE-2026-54885Medium
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.
- CVE-2026-55221Medium
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.
- CVE-2026-49249High
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.
Original NVD description (English source)
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 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.