CVE-2026-49852: 
Python vulnerability analysis and mitigation

CVE-2026-49852 is an improper authentication vulnerability in joserfc, a Python library implementing JSON Object Signing and Encryption (JOSE) standards. The flaw allows joserfc.jwt.decode to accept attacker-forged HMAC-signed tokens when the caller-supplied verification key is an empty string or None, enabling complete authentication bypass. All versions of joserfc up to and including 1.6.7 (PyPI) are affected; the issue is fixed in version 1.6.8. It carries a CVSS v4.0 base score of 8.7 (High) (Github Advisory). The vulnerability was first published on May 29, 2026, and added to the GitHub Advisory Database on July 2, 2026 (Github Advisory).

The root cause is classified as CWE-287 (Improper Authentication) and CWE-326 (Inadequate Encryption Strength). In src/joserfc/_rfc7518/oct_key.py, OctKey.import_key only emits a SecurityWarning for keys shorter than 14 bytes but does not reject zero-length input — allowing an OctKey with raw_value = b"" to be created silently. Subsequently, HMACAlgorithm.sign and HMACAlgorithm.verify in src/joserfc/_rfc7518/jws_algs.py pass the result of OctKey.get_op_key(...) directly to Python's hmac.new(...), which accepts an empty byte string as a valid key. Because an empty HMAC key produces a fully deterministic digest, any attacker can reproduce the exact signature without any secret knowledge, causing hmac.compare_digest to return True and jwt.decode to succeed (Github Advisory, Fix Commit). This is a cross-language sibling of ruby-jwt CVE-2026-45363, which had the same class of defect. Exploitation requires no privileges or user interaction, but does require the operator-side misconfiguration of an empty or unset JWT secret (e.g., JWT_SECRET environment variable unset, missing database row, or key-finder fallback returning "") (Github Advisory).

Successful exploitation results in complete authentication bypass: an attacker can forge arbitrary JWT claims — including sub, admin, scopes, audience, and exp — and have them accepted as valid by any service using joserfc with an empty HMAC key. The misconfiguration is silent at startup; joserfc emits only a SecurityWarning and continues operating, meaning affected deployments may not be aware of their exposure. Integrity is fully compromised for the affected system, enabling privilege escalation, unauthorized access to protected resources, and potential lateral movement within applications that rely on JWT-based identity (Github Advisory).

1. Identify target: Locate an application using joserfc <= 1.6.7 for JWT verification where the JWT_SECRET (or equivalent) environment variable is unset, empty, or sourced from a missing database/Redis row — causing OctKey.import_key("") to be called silently.
2. Craft forged JWT header and payload: Construct a JWT header {"alg": "HS256", "typ": "JWT"} and a payload with desired claims (e.g., {"sub": "attacker", "admin": true, "exp": <future timestamp>}), base64url-encoding each part.
3. Sign with empty key: Compute the HMAC-SHA256 signature over <header>.<payload> using an empty byte string as the key: hmac.new(b"", signing_input, hashlib.sha256).digest(), then base64url-encode the result.
4. Assemble and submit forged token: Concatenate the parts as <header>.<payload>.<signature> and send it in the Authorization: Bearer <token> header to the target endpoint.
5. Achieve authentication bypass: The server calls joserfc.jwt.decode(token, OctKey.import_key(""), algorithms=["HS256"]), which internally computes hmac.new(b"", signing_input, sha256).digest() — matching the attacker's digest exactly — and returns the decoded claims, granting the attacker full access as the forged identity (Github Advisory).

• Logs: Application logs showing successful JWT authentication (HTTP 200) for requests where the JWT_SECRET environment variable is unset or empty; absence of BadSignatureError exceptions in joserfc-related log output despite suspicious or unexpected claim values.
• Application Behavior: Python process emitting SecurityWarning: Key size should be >= 112 bits at startup (logged if warnings are captured), indicating an empty or very short HMAC key is in use.
• Network: HTTP requests to authenticated API endpoints bearing JWTs with "alg": "HS256" and claims such as "admin": true or elevated roles from unexpected source IPs or user agents.
• File System / Config: JWT_SECRET or equivalent environment variable absent or set to an empty string in deployment configuration files, container environment, or secrets manager entries (Github Advisory).

Upgrade joserfc to version 1.6.8 immediately, which rejects empty OctKey material at import time (ValueError: oct key material must not be empty) and adds a defence-in-depth check in HMACAlgorithm.sign and .verify (joserfc Release, Fix Commit). As an interim workaround, ensure that all JWT secrets are explicitly validated as non-empty before being passed to OctKey.import_key — for example, raise an error if os.environ.get("JWT_SECRET", "") returns an empty string. Audit all key-finder callables, database/Redis lookups, and configuration defaults to confirm they cannot resolve to "" or None at runtime (Github Advisory).

The advisory notes that equivalent empty-key guards already exist in PyJWT 2.13.0, firebase/php-jwt, jjwt (256-bit minimum), and Microsoft IdentityModel (128-bit minimum), framing this as a known class of JWT library vulnerability that joserfc had not yet addressed (Github Advisory). The vulnerability was reported by security researcher tonghuaroot and patched promptly by maintainer lepture. OpenSUSE issued a security announcement and update for the affected package, and Red Hat published an errata (RHSA-2026:42045), indicating broad downstream awareness and response (Feedly).