EEF-CVE-2026-53431 CVE-2026-53431 GHSA-xjv8-vmh5-xhf6
Boruta accepts expired JWT client assertions due to missing exp claim validation
- 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
| Package | Vulnerable | Fixed 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
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why 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
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