CVE-2026-53431

Boruta accepts expired JWT client assertions due to missing exp claim validation

View on CVE.org
Published Jul 30, 2026 CVSS 4.0 · 9.1 Critical EPSS < 1% KEV · Not listed
Description
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.

Analysis

AI-generated

Technical impact

Boruta Auth validates JWT‑based client assertions without checking that the exp claim is in the future, allowing a replay of any captured, expired token. An attacker who obtains a signed client assertion—through logs, reverse proxies, browser tooling or other monitoring surfaces—can reuse it indefinitely to request access tokens, effectively gaining the privileges of the authenticated OAuth client.

Affected Systems

The malach‑it Boruta Auth package versions 2.3.0 through 2.3.6 are affected by this vulnerability.

Risk and Exploitability

The vulnerability carries a CVSS score of 9.1, indicating critical risk. An EPSS score of < 1% indicates a very low but nonzero exploitation probability, but the flaw is not listed in CISA's KEV catalog, which does not diminish the high likelihood that attackers can reuse captured assertions. Successful exploitation requires only possession of a valid signed assertion; no further credentials or permissions are needed.

Remediation

Vendor Workaround

Restrict 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.

OpenCVE Recommended Actions

  • Upgrade Boruta to version 2.3.7 or later, which adds proper expiration validation.
  • Disable or restrict the use of JWT‑based client authentication (client_secret_jwt and private_key_jwt) to highly trusted clients or replace them with client_secret_basic or client_secret_post where possible.
  • Issue client assertions with short lifetimes and ensure they are not stored, logged or exposed in application logs, reverse proxies, browser tooling or observability systems.

Generated by OpenCVE AI on August 3, 2026 at 10:49 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories available
History
Type Values Removed Values Added
First Time appeared Malach-it boruta
Vendors & Products Malach-it boruta
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'total'}, 'version': '2.0.3'}
Type Values Removed Values Added
Description 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.
Title Boruta accepts expired JWT client assertions due to missing exp claim validation
First Time appeared Malach-it
Malach-it boruta Auth
Weaknesses CWE-294
CPEs cpe:2.3:a:malach-it:boruta_auth:*:*:*:*:*:*:*:*
Vendors & Products Malach-it
Malach-it boruta Auth
References
Metrics cvssV4_0

{'score': 9.1, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N'}
Weaknesses
  • CWE-294

    Authentication Bypass by Capture-replay

Sources

Status
PUBLISHED
Assigner
EEF
Published
Updated
Jul 31, 2026, 4:20 AM
Reserved
Jun 9, 2026, 11:01 AM

View source JSON

Updated
Jul 30, 2026, 4:13 PM

JSON

Status
Deferred
Published
Jul 30, 2026, 3:16 PM
Modified
Oct 23, 2026, 10:10 PM

View source JSON

No data.

Updated
Aug 3, 2026, 11:00 AM

JSON