Executive brief
Boruta, an Elixir-based OAuth 2.0 and OpenID Connect provider, fails to check the expiration date of security tokens used for client authentication. This allows an attacker who intercepts an old, expired login token to reuse it indefinitely to impersonate a legitimate client application. Successful exploitation could lead to unauthorized access to sensitive data or the ability to perform actions on behalf of the compromised application.
Technical details
An authentication bypass by capture-replay exists in Boruta due to missing expiration validation for JWT-based client authentication (client_secret_jwt and private_key_jwt). The vulnerable component, Boruta.Oauth.Request.Base.check_expiration/1, only verifies the presence of the 'exp' claim without checking if the timestamp is in the future. Additionally, the Joken configuration in Boruta.Oauth.Authorization.Client.Token.token_config/0 returns an empty map, bypassing default library-level validation. A remote attacker who obtains a previously valid JWT assertion (e.g., from logs or proxies) can replay it to authenticate as the OAuth client and obtain access tokens. The issue is fixed in version 2.3.7.
Affected products
- malach-it boruta from 2.3.0 before 2.3.7
Timeline
- 2026-07-30: advisory: Original advisory published by EEF CNA
- 2026-07-30: patched: Fixes merged in commits 5204f88 and 6936343
References
- https://repo.hex.pm/
- https://github.com/
- https://cna.erlef.org/cves/CVE-2026-53431.html
- https://github.com/malach-it/boruta_auth/commit/5204f88f9b2cdd9637a755337ed5f99185be5474
- https://github.com/malach-it/boruta_auth/commit/69363432aa36760fc5438e4e17115d0f7c1b925a
- https://github.com/malach-it/boruta_auth/security/advisories/GHSA-xjv8-vmh5-xhf6