Summary
Authlib versions before 1.9.1 may accept an empty string or empty byte sequence as HMAC key material during OAuth and OpenID Connect token signing or verification. If an application's secret lookup can return an empty value, a remote attacker may forge HS256, HS384, or HS512 tokens with arbitrary claims that Authlib treats as authentic.
Authlib versions before 1.9.1 may accept an empty string or empty byte sequence as HMAC key material during OAuth and OpenID Connect token signing or verification. If an application's secret lookup can return an empty value, a remote attacker may forge HS256, HS384, or HS512 tokens with arbitrary claims that Authlib treats as authentic.
Affected context
The issue affects Authlib deployments that use its HMAC-based token signing or verification paths and obtain signing secrets from a lookup mechanism that can produce empty values. Risk is highest when forged tokens are accepted for authentication, authorization, identity claims, or access to protected OAuth or OpenID Connect resources.
The issue affects Authlib deployments that use its HMAC-based token signing or verification paths and obtain signing secrets from a lookup mechanism that can produce empty values. Risk is highest when forged tokens are accepted for authentication, authorization, identity claims, or access to protected OAuth or OpenID Connect resources.
Exploit preconditions
- Attack surface: OAuth or OpenID Connect token validation using Authlib HMAC algorithms
- Required access: Ability to submit a crafted token to an endpoint that performs Authlib verification
- Trigger point: HMAC signing or verification when the configured key material is empty
- Why exploitation is possible: An empty HMAC key provides no meaningful secret, allowing deterministic signatures to be computed for attacker-selected claims
- Attack surface: OAuth or OpenID Connect token validation using Authlib HMAC algorithms
- Required access: Ability to submit a crafted token to an endpoint that performs Authlib verification
- Trigger point: HMAC signing or verification when the configured key material is empty
- Why exploitation is possible: An empty HMAC key provides no meaningful secret, allowing deterministic signatures to be computed for attacker-selected claims
Why this happens
The vulnerability results from failing to reject zero-length key material during key import and HMAC operations. When an empty string or empty byte sequence is accepted as a cryptographic secret, token verification no longer depends on confidential key material.
This maps primarily to CWE-287: Improper Authentication, because forged credentials can be accepted as authentic. It is also related to CWE-326: Inadequate Encryption Strength and CWE-1391: Use of Weak Credentials, since an empty key does not provide meaningful cryptographic protection.
The vulnerability results from failing to reject zero-length key material during key import and HMAC operations. When an empty string or empty byte sequence is accepted as a cryptographic secret, token verification no longer depends on confidential key material.
This maps primarily to CWE-287: Improper Authentication, because forged credentials can be accepted as authentic. It is also related to CWE-326: Inadequate Encryption Strength and CWE-1391: Use of Weak Credentials, since an empty key does not provide meaningful cryptographic protection.
Potential impact
- Attackers may forge OAuth or OpenID Connect tokens
- Authentication checks may be bypassed
- Arbitrary identity or authorization claims could be accepted
- Protected APIs and user data may be accessed
- Account impersonation or privilege escalation could occur
- Attackers may forge OAuth or OpenID Connect tokens
- Authentication checks may be bypassed
- Arbitrary identity or authorization claims could be accepted
- Protected APIs and user data may be accessed
- Account impersonation or privilege escalation could occur
General mitigation guidance
Mitigation generally focuses on ensuring that cryptographic key material is present, secret, and validated before use.
Common defensive patterns include:
- Rejecting null, empty, and otherwise invalid signing secrets before token processing
- Enforcing minimum length and entropy requirements for HMAC keys
- Using secure secret-management systems with fail-closed behavior
- Avoiding fallback values or silently defaulting missing secrets to empty strings
- Applying least privilege to services that issue and validate tokens
- Separating signing and verification credentials across appropriate trust boundaries
- Maintaining dependency versions that contain the relevant security correction
Mitigation generally focuses on ensuring that cryptographic key material is present, secret, and validated before use.
Common defensive patterns include:
- Rejecting null, empty, and otherwise invalid signing secrets before token processing
- Enforcing minimum length and entropy requirements for HMAC keys
- Using secure secret-management systems with fail-closed behavior
- Avoiding fallback values or silently defaulting missing secrets to empty strings
- Applying least privilege to services that issue and validate tokens
- Separating signing and verification credentials across appropriate trust boundaries
- Maintaining dependency versions that contain the relevant security correction
How teams detect issues like this
Organizations can identify related weaknesses through:
- Static analysis for HMAC or token-verification code paths that accept nullable or empty secrets
- Code review checks for default empty strings, empty byte sequences, and permissive secret lookups
- Configuration and policy checks requiring non-empty, sufficiently strong signing keys
- Negative tests confirming that missing or empty key material causes verification to fail closed
- Runtime monitoring for unusual token issuances, claim changes, or authentication activity
- Automated dependency and security review tools that flag vulnerable authentication-library usage
Organizations can identify related weaknesses through:
- Static analysis for HMAC or token-verification code paths that accept nullable or empty secrets
- Code review checks for default empty strings, empty byte sequences, and permissive secret lookups
- Configuration and policy checks requiring non-empty, sufficiently strong signing keys
- Negative tests confirming that missing or empty key material causes verification to fail closed
- Runtime monitoring for unusual token issuances, claim changes, or authentication activity
- Automated dependency and security review tools that flag vulnerable authentication-library usage
