This vulnerability in Boruta allows client assertion JWTs to be replayed indefinitely. The technical failure is straightforward: token_config/0 returns an empty map {}, which tells Joken to skip its default expiration validation. The check_expiration/1 function only verifies that an exp claim exists in the token—it never checks whether that timestamp is still valid. Neither layer performs the temporal validation, and both appear to.
The practical consequence is severe: any JWT ever issued to a client remains a valid credential forever. An attacker who obtains a client assertion from logs, proxy records, browser devtools, or any observability surface can replay it to authenticate as that client indefinitely. The library correctly validates the cryptographic signature (proving the token originated from your server), but never validates that the token is still temporally legitimate. This is not a forgery attack—the attacker is reusing a token your system already issued.
The upgrade path is more complex than a library update. Upgrading to the patched version prevents new tokens from being vulnerable, but every client assertion issued while running the vulnerable version remains usable by anyone who captured it. If your logs, proxies, SIEM pipelines, or debugging output ever contained JWTs, those credentials are still valid. You must audit where client assertions were logged and force-rotate every client credential that existed during the vulnerable window. This is the step most teams will skip, and it's the gap that leaves you exposed after patching.
The detection problem compounds the risk. Boruta accepting a replayed assertion produces identical audit logs to legitimate authentication—there is no anomaly to trigger alerts. Your SIEM won't catch this. You'll only discover the compromise after an attacker has already used the replayed token to obtain downstream access tokens and moved laterally through your system, because Boruta's token issuance to the replayed assertion is indistinguishable from normal operation.
This empty-map override pattern has appeared in JWT libraries across multiple ecosystems—CVE-2017-16128 (jsonwebtoken), CVE-2020-7598 (jose), and others all share the same root cause: returning an empty config to 'pass through' to defaults actually disables validation entirely. The pattern is an antipattern precisely because it removes security-critical defaults while appearing to preserve them. Audit your other Boruta and Joken configurations for similar override patterns, and treat any token_config/0 returning {} as a critical finding.