The Lemur JWT verifier extracts the 'alg' field from the unverified JWT header and passes it directly to the PyJWT decode function as the allowed algorithm. This is a known anti-pattern because the server should pin the algorithm rather than trust the token's header. Although PyJWT 2.x rejects 'alg=none' tokens by default, preventing immediate single-request ATO, the vulnerability remains a defense-in-depth weakness. If Lemur deployments move to asymmetric signing algorithms (e.g., RS256), an attacker could exploit the algorithm confusion by specifying 'alg=HS256' and forging tokens using the public key as the HMAC secret. Furthermore, audit logs that record the 'alg' field from the token header can be manipulated by attackers, reducing anomaly detection effectiveness. The vulnerability is classified under CWE-347 (Improper Verification of Cryptographic Signature) and affects Lemur versions prior to 1.9.2.

This vulnerability creates a defense-in-depth gap that could lead to account takeover (ATO) if combined with a separate secret disclosure vulnerability or if the system migrates to asymmetric signing without addressing the issue. The immediate risk is limited because PyJWT 2.x blocks 'alg=none' tokens, preventing trivial single-request token forgery. However, the algorithm confusion attack remains a risk for future asymmetric signing deployments. Additionally, audit logs can be manipulated by attackers to hide anomalous token usage, reducing detection capabilities.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until an official fix is available, users should avoid migrating to asymmetric signing algorithms without ensuring the JWT verifier pins the expected algorithm rather than trusting the token header. Monitoring for updates from the Lemur project and PyJWT library is recommended. No generic mitigations are advised beyond addressing the specific algorithm pinning issue.