malach-it Boruta 2.3.0-2.3.6 OAuth Request Base Expiration Check base.ex Boruta.Oauth.Request.Base.check_expiration/1 authentication replay

Summaryinfo

A vulnerability, which was classified as critical, has been found in malach-it Boruta 2.3.0-2.3.6. This impacts the function Boruta.Oauth.Request.Base.check_expiration/1 of the file lib/boruta/oauth/request/base.ex of the component OAuth Request Base Expiration Check. The manipulation leads to authentication replay. This vulnerability is listed as CVE-2026-53431. The attack may be initiated remotely. There is no available exploit.

Detailsinfo

A vulnerability, which was classified as critical, has been found in malach-it Boruta 2.3.0-2.3.6. This issue affects the function Boruta.Oauth.Request.Base.check_expiration/1 of the file lib/boruta/oauth/request/base.ex of the component OAuth Request Base Expiration Check. The manipulation with an unknown input leads to a authentication replay vulnerability. Using CWE to declare the problem leads to CWE-294. A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes). Impacted is confidentiality, integrity, and availability. The summary by CVE is:

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.

The advisory is shared at github.com. The identification of this vulnerability is CVE-2026-53431 since 06/09/2026. The exploitation is known to be easy. The attack may be initiated remotely. No form of authentication is needed for a successful exploitation. Technical details are known, but no exploit is available. MITRE ATT&CK project uses the attack technique T1040 for this issue.

Upgrading to version 2.3.7 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Vendor

• malach-it

Name

• Boruta

Version

• 2.3.0-2.3.6

CPE 2.3info

• 🔒

CPE 2.2info

• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion