Boruta accepts JWT-based client authentication using client_secret_jwt and private_key_jwt methods but fails to enforce that the JWT assertion's exp claim is in the future. The pre-check function only verifies the presence of the exp claim without validating its timestamp, and the token configuration disables the default exp claim validation. Consequently, an attacker who obtains a validly signed client assertion can replay it indefinitely, bypassing authentication and obtaining access tokens with the client's privileges. This affects Boruta versions from 2.3.0 before 2.3.7.

An attacker with access to a previously valid JWT client assertion can bypass authentication by replaying expired tokens, gaining unauthorized access to the OAuth client’s privileges. This can lead to unauthorized issuance of access tokens, potentially compromising protected resources and services relying on Boruta for OAuth client authentication.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is released, avoid exposing JWT client assertions in logs, proxies, or other observability tools to reduce the risk of token capture. Monitor for updates from malach-it regarding patches or official mitigations.