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.
Published: 2026-07-30
Score: 9.1 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

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.

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

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

History

Thu, 30 Jul 2026 19:30:00 +0000

Type Values Removed Values Added
First Time appeared Malach-it boruta
Vendors & Products Malach-it boruta

Thu, 30 Jul 2026 17:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'poc', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Thu, 30 Jul 2026 15:00:00 +0000

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'}

Subscriptions

Malach-it Boruta Boruta Auth
cve-icon MITRE

Status: PUBLISHED

Assigner: EEF

Published:

Updated: 2026-07-31T04:20:43.209Z

Reserved: 2026-06-09T11:01:47.529Z

Link: CVE-2026-53431

cve-icon Vulnrichment

Updated: 2026-07-30T16:13:13.574Z

cve-icon NVD

Status : Deferred

Published: 2026-07-30T15:16:33.567

Modified: 2026-07-30T17:16:32.863

Link: CVE-2026-53431

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-03T11:00:03Z

Weaknesses
  • CWE-294

    Authentication Bypass by Capture-replay