EUVD-2026-51145Severity by source
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable token endpoint (AV:N) with no privileges (PR:N), but the attacker must first capture a valid signed assertion, mapping the 4.0 AT:P requirement to AC:H; full client impersonation gives C:H/I:H with no availability impact.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Authentication bypass via JWT assertion replay in malach-it Boruta (an Elixir OAuth 2.0/OpenID Connect provider) from 2.3.0 before 2.3.7 lets an attacker who captures any previously valid client assertion re-authenticate as that OAuth client indefinitely, because the token endpoint never checks the assertion's expiry. An attacker who harvests a signed client_secret_jwt or private_key_jwt assertion from logs, proxies, or browser tooling can mint access tokens carrying the victim client's privileges. No public exploit identified at time of analysis, though the fix commits and regression tests publicly demonstrate both the flawed and corrected behavior.
Technical ContextAI
Boruta is an OAuth 2.0 and OpenID Connect authorization server library written in Elixir, and this issue lives in its RFC 7523 JWT client-authentication path supporting the client_secret_jwt and private_key_jwt token endpoint auth methods. The root cause is CWE-294 (Authentication Bypass by Capture-replay): the expiry (exp) claim is never validated as being in the future. Two defects combine - the pre-check helper Boruta.Oauth.Request.Base.check_expiration/1 in lib/boruta/oauth/request/base.ex only pattern-matches that an exp key exists and returns success without comparing it to the current time, and Boruta.Oauth.Authorization.Client.Token.token_config/0 in lib/boruta/oauth/authorization/client.ex returns an empty map, so Joken's default exp validator is never engaged. The signature is verified but temporal validity is not, so any correctly signed assertion remains eternally valid for replay.
RemediationAI
Upgrade Boruta to version 2.3.7, which enforces exp expiry validation - this is the primary and recommended fix (Vendor-released patch: 2.3.7). The fix, in commits 5204f88f9b2cdd9637a755337ed5f99185be5474 and 69363432aa36760fc5438e4e17115d0f7c1b925a, adds an exp claim validator to token_config/0 requiring exp to be a number greater than the current time and switches signature checks from Token.verify to Token.verify_and_validate so the validator actually runs. If immediate upgrade is not possible, compensating controls focus on preventing assertion leakage: stop logging Authorization headers and request bodies containing client_assertion at reverse proxies and application logs, and rotate any client secrets or key pairs whose assertions may already have been exposed (trade-off: secret/key rotation forces reconfiguration of every affected client). Where feasible, front the token endpoint with a gateway that rejects assertions whose exp is in the past, though this duplicates the logic the patch already provides. Consult the advisory at https://github.com/malach-it/boruta_auth/security/advisories/GHSA-xjv8-vmh5-xhf6 for authoritative guidance.
Privilege escalation via dynamic client registration in malach-it's Boruta OAuth 2.0/OpenID Connect provider library (El
Server-Side Request Forgery in Boruta (malach-it/boruta_auth versions 2.3.2 through 2.3.6) enables unauthenticated remot
Same weakness CWE-294 – Authentication Bypass by Capture-replay
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today