CVE-2026-48526

What it actually does

PyJWT versions prior to 2.13.0 can be vulnerable to an algorithm-confusion authentication bypass when an application verifies JWTs while allowing both asymmetric algorithms, such as RS256, and HMAC algorithms, such as HS256. In vulnerable configurations, the verifier may accept a JSON Web Key intended to be used as an asymmetric public key and reuse it as an HMAC shared secret. An attacker who can obtain the issuer's public key may craft a token that appears valid under an HMAC algorithm, allowing forged claims to pass signature verification. Successful exploitation can compromise token integrity and confidentiality of protected resources, but does not directly cause service availability impact.

Why it matters to the business

If an affected application relies on PyJWT for authentication or authorization and permits both asymmetric and HMAC JWT algorithms, attackers may be able to impersonate users, elevate privileges, or access protected APIs without knowing the legitimate private signing key. This can lead to unauthorized data access, fraudulent account activity, privilege escalation, and loss of trust in audit trails that depend on token identity. Although the issue is not currently listed in CISA KEV, has low EPSS, and has no reported mature exploitation, authentication bypass flaws should be prioritized because exploitability can rise quickly once proof-of-concept details become available.

How an attack unfolds

An attacker first identifies an application that accepts JWTs and uses PyJWT prior to 2.13.0 for verification. The attacker determines that the verifier allows both asymmetric and HMAC algorithms, for example accepting RS256 and HS256 in the same validation path. The attacker then obtains the issuer's public key, often from a public JWKS endpoint, application metadata, documentation, or a certificate chain. Instead of using the key as a public verification key, the attacker constructs a JWT header that selects an HMAC algorithm and creates claims for a target identity or elevated role. Because the vulnerable verifier does not correctly reject use of a JSON Web Key in the HMAC path, the public key may be treated as the HMAC secret, causing the forged token to verify successfully. The attacker then presents the token to protected endpoints and gains access according to the forged claims.

How to fix it

Upgrade PyJWT to version 2.13.0 or later everywhere it is used. In addition to upgrading, harden JWT validation by explicitly allowlisting only the expected algorithm for each issuer and key type; do not allow HMAC and asymmetric algorithms in the same validation context unless there is a strict key separation model. Ensure symmetric secrets and asymmetric public keys are stored, loaded, and selected through separate code paths. Reject tokens whose `alg` header does not exactly match the expected algorithm for the issuer. Avoid trusting token-provided `alg`, `kid`, `jku`, or `x5u` values without strict issuer-bound validation. Rotate signing keys if exploitation is suspected, invalidate active sessions where feasible, and review authorization decisions made from JWT claims during the suspected exposure window.

How to confirm the fix worked

Confirm that all deployed Python environments, containers, build artifacts, and dependency lockfiles use PyJWT 2.13.0 or later. Check dependency inventories using package manifests such as `requirements.txt`, `poetry.lock`, `Pipfile.lock`, container SBOMs, and runtime commands such as `pip show PyJWT` or `pip freeze`. Review application code to ensure JWT decoding specifies a narrow `algorithms` allowlist appropriate to the issuer and does not mix HS* and RS*/ES* algorithms for the same keys. Add a negative security test that attempts to validate a token using an HMAC algorithm where the HMAC secret is derived from the issuer public key; the fixed and hardened application should reject it. Validate that production logs no longer show successful authentication for tokens using unexpected HMAC algorithms where asymmetric JWTs are expected.

Typical attack path

1. Discover an application or API that accepts JWT bearer tokens.
2. Determine that the application uses PyJWT before version 2.13.0 or exhibits behavior consistent with the vulnerable validation logic.
3. Confirm that the token verifier allows both asymmetric and HMAC algorithms in the same trust path.
4. Obtain the issuer public key or JWK from a public JWKS URL, metadata endpoint, certificate, or exposed configuration.
5. Create a JWT with an HMAC algorithm in the header and attacker-controlled identity or authorization claims.
6. Use the issuer public key material as the HMAC secret so the vulnerable verifier accepts the forged signature.
7. Send the forged token to protected application or API endpoints.
8. Access data or perform actions as the forged user, service account, or privileged role.

How to detect it

Detection should focus on evidence of unexpected JWT algorithm use and suspicious authentication outcomes. Collect and review identity provider logs, API gateway logs, application authentication logs, reverse proxy logs, WAF logs, and endpoint telemetry from services that validate JWTs. Look for successful requests bearing JWTs whose decoded header contains `alg` values of `HS256`, `HS384`, or `HS512` when the issuer normally signs with asymmetric algorithms such as `RS256`, `RS384`, `RS512`, `ES256`, `ES384`, or `ES512`. If bearer tokens are logged or can be recovered from traffic captures, decode only the JWT header and claims for triage and compare the algorithm, issuer, key ID, subject, audience, role, and timestamp against expected issuance records. Investigate tokens with privileged claims that have no corresponding identity-provider issuance event. Look for sudden changes in user identity, impossible travel, privilege escalation, administrative API use, or access from unusual IP addresses shortly after authentication. Also review access to JWKS or certificate endpoints followed by authentication attempts using HMAC algorithms. Because many systems do not log full JWTs by default, absence of these indicators does not prove non-exploitation; correlate application authorization events with identity-provider token issuance logs wherever possible.

• "alg":"HS256"
• "alg":"HS384"
• "alg":"HS512"
• Authorization: Bearer eyJhbGciOiJIUzI1Ni
• Authorization: Bearer eyJhbGciOiJIUzM4NC
• Authorization: Bearer eyJhbGciOiJIUzUxMi
• alg=HS256
• alg=HS384
• alg=HS512
• PyJWT==2.12.
• PyJWT==2.11.
• PyJWT==2.10.
• PyJWT==2.9.
• PyJWT==2.8.
• PyJWT==2.7.
• PyJWT==2.6.
• PyJWT==2.5.
• PyJWT==2.4.
• PyJWT==2.3.
• PyJWT==2.2.
• PyJWT==2.1.
• PyJWT==2.0.

What your security team should do

• Prioritize upgrading all PyJWT installations to 2.13.0 or later, especially internet-facing APIs, identity services, API gateways, and microservices that validate JWTs.
• Inventory applications that accept JWTs and determine whether any validation path allows both HS* and RS*/ES* algorithms.
• Enforce issuer-specific and key-specific JWT algorithm allowlists in code and configuration.
• Search authentication logs for successful tokens using `HS256`, `HS384`, or `HS512` where only asymmetric algorithms are expected.
• Review public JWKS exposure and ensure public keys cannot be misused as shared secrets in application configuration.
• If suspicious forged-token activity is found, rotate signing keys, revoke sessions, and review privileged actions taken during the exposure window.
• Add regression tests and CI dependency checks to prevent reintroduction of vulnerable PyJWT versions or permissive algorithm validation.