CVE-2026-49852: joserfc HMAC Auth Bypass Vulnerability

CVE-2026-49852 Overview

CVE-2026-49852 is an authentication bypass vulnerability [CWE-287] in joserfc, a Python library implementing JSON Object Signing and Encryption (JOSE) standards. Versions prior to 1.6.8 accept attacker-forged HMAC-signed JWTs when the caller supplies an empty string or None as the verification key. The library only emits a SecurityWarning for short keys instead of rejecting zero-length input. Attackers can trivially forge HS256, HS384, and HS512 signatures against affected applications. The issue is resolved in version 1.6.8.

Critical Impact
Remote attackers can forge valid JWT signatures without knowing any secret, enabling authentication bypass and identity spoofing in applications that pass empty or null keys to joserfc.jwt.decode.

Affected Products

joserfc Python library versions prior to 1.6.8
Applications using joserfc.jwt.decode with HMAC algorithms (HS256, HS384, HS512)
Downstream services relying on joserfc for JOSE/JWT verification

Discovery Timeline

2026-07-17 - CVE-2026-49852 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-49852

Vulnerability Analysis

The vulnerability resides in the HMAC signing and verification path of joserfc. When joserfc.jwt.decode is invoked with a verification key that is an empty string or None, the library derives an empty byte string as the HMAC key. HMAC with a zero-length key produces a deterministic digest that any party can reproduce without possessing a shared secret.

An attacker who crafts a JWT with an HMAC algorithm header and computes the digest using an empty key will pass verification. This defeats the integrity guarantee of the JWS specification and enables identity spoofing wherever the affected code path is reachable. The flaw is classified under [CWE-287] Improper Authentication.

Root Cause

Two compounding defects produce the vulnerability. First, OctKey.import_key in src/joserfc/_rfc7518/oct_key.py emits only a SecurityWarning for keys shorter than 14 bytes and does not reject zero-length input. Second, HMACAlgorithm.sign and HMACAlgorithm.verify in src/joserfc/_rfc7518/jws_algs.py pass the output of OctKey.get_op_key(...) directly into hmac.new(...) without validating that the key material is non-empty.

Attack Vector

Exploitation requires no privileges, no user interaction, and is network reachable. An attacker constructs a JWT with an alg header of HS256, HS384, or HS512, then signs it using an empty byte string as the HMAC key. If the target application invokes joserfc.jwt.decode with an empty or None key, verification succeeds and the forged claims are accepted as authentic.

python

# Security patch in src/joserfc/_rfc7518/jws_algs.py
     def sign(self, msg: bytes, key: OctKey) -> bytes:
         # it is faster than the one in cryptography
         op_key = key.get_op_key("sign")
+        if not op_key:
+            # Defence-in-depth: OctKey.import_key rejects empty input, but
+            # an OctKey can also be constructed directly through other
+            # internal paths. An empty HMAC key produces a forgeable digest.
+            raise ValueError("HMAC key must not be empty")
         return hmac.new(op_key, msg, self.hash_alg).digest()
 
     def verify(self, msg: bytes, sig: bytes, key: OctKey) -> bool:
         op_key = key.get_op_key("verify")
+        if not op_key:
+            raise ValueError("HMAC key must not be empty")
         v_sig = hmac.new(op_key, msg, self.hash_alg).digest()
         return hmac.compare_digest(sig, v_sig)

Source: GitHub Commit 86d0091

python

# Security patch in src/joserfc/_rfc7518/oct_key.py
         password: Any = None,
     ) -> "OctKey":
         key: OctKey = super(OctKey, cls).import_key(value, parameters, password)
+        if not key.raw_value:
+            # An empty oct key material produces a deterministic HMAC digest
+            # that any party can reproduce, allowing trivial signature forgery
+            # in JWS HS256/HS384/HS512 verification. Reject outright rather
+            # than emitting a SecurityWarning that callers commonly suppress.
+            raise ValueError("oct key material must not be empty")
         if len(key.raw_value) < 14:
             # https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final
             warnings.warn("Key size should be >= 112 bits", SecurityWarning)

Source: GitHub Commit 86d0091

Detection Methods for CVE-2026-49852

Indicators of Compromise

JWTs with alg header set to HS256, HS384, or HS512 arriving from untrusted clients that verify against a signature computed with an empty key.
Application logs showing successful joserfc.jwt.decode calls where the configured verification key resolves to an empty string or None.
Presence of SecurityWarning messages referencing key size under 112 bits in application logs prior to patching.

Detection Strategies

Perform dependency scanning for joserfc<1.6.8 in Python requirements.txt, pyproject.toml, and lockfiles.
Audit application source code for calls to joserfc.jwt.decode and confirm the key argument is never derived from empty configuration values or unset environment variables.
Deploy runtime request inspection to flag inbound JWTs whose signature validates against an empty HMAC key.

Monitoring Recommendations

Log all authentication decisions involving JWT verification, including the algorithm and key identifier used.
Alert on Python SecurityWarning entries originating from joserfc._rfc7518.oct_key during signing key import.
Monitor authentication anomalies such as unusual privilege escalations following token acceptance from new IPs.

How to Mitigate CVE-2026-49852

Immediate Actions Required

Upgrade joserfc to version 1.6.8 or later across all Python environments.
Audit application code to ensure the verification key passed to joserfc.jwt.decode is never empty, None, or sourced from unset configuration.
Rotate any HMAC secrets that may have been exposed or misconfigured during the vulnerable window.

Patch Information

The fix is available in joserfc version 1.6.8. The patch introduces explicit rejection of empty key material in OctKey.import_key and defense-in-depth checks in HMACAlgorithm.sign and HMACAlgorithm.verify. See the GitHub Security Advisory GHSA-gg9x-qcx2-xmrh and the GitHub Release 1.6.8 notes.

Workarounds

If immediate upgrade is not possible, wrap joserfc.jwt.decode in a helper that raises when the key is empty or None.
Restrict accepted JWT algorithms to asymmetric options such as RS256 or ES256 where feasible to eliminate the HMAC attack surface.
Enforce a minimum key length of at least 32 bytes for HMAC secrets at configuration load time.

bash

# Configuration example - upgrade joserfc to the patched release
pip install --upgrade 'joserfc>=1.6.8'

# Verify installed version
python -c "import joserfc; print(joserfc.__version__)"