CVE-2026-53431 in Boruta
Summary
by MITRE • 07/30/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/31/2026
The vulnerability described represents a critical authentication bypass flaw in the malach-it Boruta OAuth 2.0 implementation that fundamentally undermines the security of client authentication mechanisms. This weakness allows attackers to exploit previously valid JSON Web Token (JWT) assertions indefinitely, effectively circumventing time-based expiration controls that are essential for maintaining secure authentication sessions. The flaw specifically targets the client assertion validation process where JWT tokens are used for client authentication through methods such as client_secret_jwt and private_key_jwt at the token endpoint.
The technical root cause of this vulnerability lies in the incomplete implementation of JWT expiration validation within Boruta's OAuth framework. The pre-check helper function Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex demonstrates a fundamental design flaw where it only verifies the presence of an exp claim within the JWT payload without ensuring that this timestamp represents a future date. This function performs pattern-matching on the existence of the key and simply returns success when the claim is present, completely ignoring whether the expiration time has already passed. Furthermore, the Joken token configuration used for signature verification in Boruta.Oauth.Authorization.Client.Token.token_config/0 returns an empty map, which prevents Joken's default expiration validator from being activated during the token verification process.
This authentication bypass vulnerability directly impacts the integrity of the OAuth 2.0 client authentication flow and creates significant operational risks for systems relying on Boruta. Attackers who obtain a validly-signed client assertion through various means such as log monitoring, reverse proxy inspection, browser developer tools, or other observability mechanisms can replay these tokens indefinitely to impersonate the issuing OAuth client. The consequences extend beyond simple unauthorized access as attackers gain the ability to obtain access tokens with the privileges and permissions associated with the compromised client, potentially leading to data breaches, privilege escalation, and unauthorized system modifications.
The vulnerability affects all versions of Boruta from 2.3.0 through 2.3.6, representing a window of opportunity for attackers to exploit this flaw across multiple releases. This authentication bypass aligns with CWE-287 (Improper Authentication) and specifically manifests as a failure in proper session management controls that should prevent replay attacks. From an ATT&CK perspective, this vulnerability maps to T1566 (Phishing) through the initial compromise of tokens, T1078 (Valid Accounts) by leveraging legitimate client credentials, and T1550 (Use of Unencrypted/Unauthenticated Communication) when attackers exploit token replay mechanisms. Organizations implementing Boruta within their OAuth infrastructure face significant risk exposure, particularly in environments where client authentication is critical for protecting sensitive resources and maintaining proper access controls.
The recommended mitigation strategy involves implementing proper JWT expiration validation that ensures the exp claim represents a future timestamp before accepting any client assertion for authentication. The check_expiration function must be enhanced to verify that the expiration time has not already passed, and the Joken token configuration should be properly configured to engage the default expiration validator. Additionally, organizations should implement comprehensive logging and monitoring of client authentication attempts to detect anomalous token usage patterns, and consider implementing additional security controls such as nonce validation or transaction binding to prevent replay attacks. The version upgrade to 2.3.7 or later is essential to address this vulnerability, as it contains the necessary fixes to properly validate JWT expiration times and enforce proper time-based authentication controls.