Skip to content

EEF-CVE-2026-53431 CVE-2026-53431 GHSA-xjv8-vmh5-xhf6

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

Not rated yet Hex
Severity
0.0 / 10
Unknown · CVSS 4.0
Exploit chance (EPSS)
0.51%
Chance of exploitation in the next 30 days. Higher than 43.66% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-294 Authentication Bypass by Capture-replay
Fix
2.3.7
Upgrade boruta to this version or later

Description

Summary

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.

Workarounds

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.

Configurations

The attack requires that the Boruta deployment has provisioned at least one OAuth client configured to authenticate via JWT client assertions (client_secret_jwt or private_key_jwt token endpoint authentication methods). Deployments that authenticate clients only via client_secret_basic or client_secret_post are not exposed.

Affected versions

Hex

PackageVulnerableFixed in
boruta
>= 2.3.0, < 2.3.7
2.3.7

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

boruta Hex → 2.3.7

mix
{:boruta, "~> 2.3.7"} # then: mix deps.update boruta

Severity breakdown

CVSS 4.0 0.0

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

Attack vector
Network
Attack complexity
Low
Attack requirements
Present
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
High
Integrity (vulnerable system)
High
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-294: Authentication Bypass by Capture-replay

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

How to prevent it
  • Architecture and Design: Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.
  • Architecture and Design: Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
EEF-CVE-2026-65635
Boruta dynamic client registration allows creation of over-privileged OAuth clients
Not rated yet Also affects boruta
EEF-CVE-2026-54885
Server-side request forgery in Boruta OAuth request_uri and OpenID jwks_uri fetching
Not rated yet Also affects boruta
EEF-CVE-2026-87119
mpp Tempo subscription key authorization is not bound to the issuing challenge, allowing a captured activation credential to be replayed
Not rated yet Same weakness, CWE-294
GHSA-9xv2-5v5q-p794
Apache Tomcat's DIGEST authenticator has an Authentication Bypass by Capture-replay vulnerability
Critical Same weakness, CWE-294
EEF-CVE-2026-53424
Missing one-time-use enforcement in Samly allows replay of SAML bearer assertions
Not rated yet Same weakness, CWE-294
EEF-CVE-2026-67581
On-chain transfer proof is not single-use in mpp EVM payment method, enabling cross-challenge replay
High Same weakness, CWE-294
EEF-CVE-2026-73136
Static memo configuration in mpp Tempo disables per-challenge attribution binding, enabling third-party replay
High Same weakness, CWE-294
GHSA-wg23-69c2-gjc8
Craft CMS: Passkey login accepts replayed WebAuthn assertions
Medium Same weakness, CWE-294

Credits: Jonatan Männchen / EEF, Pascal Knoth

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor