joserfc versions <= 1.6.7 have a vulnerability in their HMAC verification implementation where the verify function accepts empty or nil keys without rejection. The OctKey.import_key method issues only a warning for keys shorter than 14 bytes but does not reject zero-length keys, which are then used in hmac.new calls. This allows attackers to forge HMAC-signed JWT tokens if the application’s verification key is empty or None, a condition that can arise from unset environment variables, missing database entries, or default empty strings. This vulnerability is a cross-language sibling of CVE-2026-45363 affecting ruby-jwt. Unlike ruby-jwt and other libraries that enforce non-empty keys, joserfc lacks such a check, making it vulnerable to token forgery without requiring authentication.

An attacker can forge valid HMAC-signed JWT tokens if the application uses joserfc for JWT verification and the configured secret key is empty or None. This effectively bypasses signature verification, allowing unauthorized access or privilege escalation in systems relying on joserfc for JWT authentication. The vulnerability requires no privileges or user interaction but depends on the operator misconfiguring or failing to set the JWT secret properly.

No official patch or fixed release is currently available for joserfc. Operators must ensure that the JWT secret key used for verification is never empty or None. Applications should implement additional validation to reject empty keys before passing them to joserfc.jwt.decode. Monitor vendor advisories for updates or patches addressing this issue.