GHSA-9v7f-9g4p-ffgj CVE-2026-102267 PYSEC-2026-4144
PyJWT: PyJWKClient follows redirects when fetching JWKS
- Severity
- 7.4 / 10
- Critical · CVSS 3.1
- Exploit chance (EPSS)
- 0.16%
- Chance of exploitation in the next 30 days. Higher than 5.01% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
- CWE-345 Insufficient Verification of Data Authenticity
- CWE-918 Server-Side Request Forgery (SSRF)
- Fix
2.14.0- Upgrade pyjwt to this version or later
Description
Summary
PyJWT 2.13.0 PyJWKClient followed HTTP redirects while fetching a JWKS,
without validating the redirect destination. A configured trusted endpoint
could therefore redirect the client to a different host.
Impact
When an application uses PyJWKClient with caller-supplied request headers and
an attacker can influence the configured endpoint's response, the redirected
request could expose those headers and the redirected response could be used as
authoritative key material. This could cause JWKS trust poisoning and, in
affected mixed-configuration applications, forged JWT acceptance. The issue
requires an attacker-influenced redirect from the configured JWKS endpoint; it
is not triggered by a token kid alone.
Affected versions
PyJWT <= 2.13.0.
Fix
The issue is fixed on master in commit
0a795b8e1f6ef08f634aa7086fc41cc6d5ce3e56.
PyJWKClient now disables automatic redirects for JWKS fetches. Regression
tests verify that a redirect is rejected without contacting its destination,
while normal fetches, headers, caching, errors, timeouts, and SSL context remain
covered.
The fix is present in the unreleased development branch. The patched version will be recorded after a released PyJWT 2.x version containing the fix is confirmed.
Credit
Credit: the original reporter of GHSA-9v7f-9g4p-ffgj. Additional redirect header-leak and cache-poisoning evidence from the newer duplicate report GHSA-43g3-98cx-x446 is preserved in the duplicate record and informed this canonical advisory update.
Maintainer update — 2026-09-11
The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| pyjwt | < 2.14.0 |
2.14.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
pyjwt PyPI → 2.14.0
- pip
pip install --upgrade "pyjwt>=2.14.0"- poetry
poetry add "pyjwt>=2.14.0"- uv
uv add "pyjwt>=2.14.0"
Severity breakdown
CVSS 3.1 7.4
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
How to prevent it
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CWE-345: Insufficient Verification of Data Authenticity
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
CWE-918: Server-Side Request Forgery (SSRF)
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-pxh4-856f-4h89 PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery | High | Also affects pyjwt |
| GHSA-gvp8-978c-rx2q PyJWT.decode() reintroduces options-dict mutation, enabling silent claim-verification bypass on dict reuse | Medium | Also affects pyjwt |
| GHSA-x33g-cr3x-6449 PyJWT accepts inconsistent OKP x/d JWKs, causing public/private key identity confusion | High | Also affects pyjwt |
| GHSA-w6j9-cwv2-h6wq PyJWT: Malformed RSA JWK aborts parsing of an entire JWK Set | High | Also affects pyjwt |
| GHSA-w2cx-738m-mc7w PyJWT accepts public JWK containers as HMAC secrets | High | Also affects pyjwt |
| GHSA-r6x4-923q-g947 PyJWT BOM Bypass | High | Also affects pyjwt |
| GHSA-p4g4-x82p-q773 PyJWT: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard | High | Also affects pyjwt |
| GHSA-jwrc-g2q2-pq5p PyJWT: ReDoS vulnerability when calling the `is_pem_format` function. | Medium | Also affects pyjwt |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor