joserfc versions <= 1.6.7 contain a vulnerability where the HMAC-based JWT verification accepts empty or nil keys, enabling attackers to forge tokens. The root cause is that OctKey.import_key only warns when keys are shorter than 14 bytes but does not reject empty keys. Consequently, HMACAlgorithm.verify uses hmac.new with an empty key, which Python's hmac module accepts, allowing signature verification without a secret. This is a cross-language sibling of CVE-2026-45363 affecting ruby-jwt. The vulnerability is exploitable when the configured JWT secret is empty or None due to unset environment variables, missing database entries, or fallback defaults. No official fix or patch release exists yet.

An attacker can forge valid JWT tokens without knowledge of the secret key if the verification key is empty or None. This compromises authentication and authorization mechanisms relying on joserfc for JWT verification, potentially allowing unauthorized access to protected resources. The vulnerability requires no privileges and can be exploited remotely if the application uses joserfc with an empty or unset secret key.

No official patch or fixed release is currently available for joserfc. Operators must ensure that the JWT secret key is never empty or None in configuration or runtime environment. Applications should implement validation to reject empty or nil keys before calling joserfc.jwt.decode. Monitoring and auditing configuration sources for missing or empty secrets is recommended until an official fix is released.