CVE-2026-48524

What it actually does

PyJWT versions prior to 2.13.0 can issue a fresh outbound HTTP request to the configured JWKS endpoint every time PyJWKClient.get_signing_key() processes a JWT whose unverified header contains an unknown kid value. Because the kid field is attacker-controlled before signature validation, a remote unauthenticated attacker can send many tokens with random kid values and cause repeated JWKS lookups without built-in rate limiting. The practical impact is availability degradation: excess outbound requests, authentication latency, JWKS provider throttling, and possible request-handling failures, especially when JWKS fetches fail or upstream identity-provider behavior becomes unstable.

Why it matters to the business

Applications that validate JWTs with affected PyJWT versions may experience degraded login, API authentication, or service availability if attackers flood them with tokens containing random key identifiers. This can increase dependency on external identity-provider availability, consume outbound network capacity, trigger provider rate limits, and cause user-facing authentication failures. The CVSS and EPSS values indicate relatively low current likelihood and limited impact, and it is not listed in CISA KEV or ransomware use, but internet-exposed authentication paths should still be remediated because exploitation requires no account access and can be automated.

How an attack unfolds

An attacker identifies an application endpoint that accepts JWT bearer tokens and uses PyJWT's PyJWKClient to resolve signing keys from a JWKS URL. The attacker crafts JWTs with syntactically valid headers but random or nonexistent kid values; the token signature does not need to be valid because key selection occurs using the unverified header. For each unknown kid, affected PyJWT versions attempt a fresh HTTP request to the JWKS endpoint. By sending sustained traffic with many unique kid values, the attacker attempts to force the application into excessive outbound JWKS fetches. If the JWKS endpoint is slow, intermittently failing, or rate-limits the application, authentication handling can slow down or fail, producing a denial-of-service condition for protected routes.

How to fix it

Upgrade PyJWT to version 2.13.0 or later wherever PyJWKClient is used. Update direct and transitive dependencies in requirements files, lockfiles, container images, virtual environments, and deployed artifacts. If immediate upgrade is not possible, add compensating controls: rate-limit requests that reach JWT validation, reject obviously malformed or oversized JWTs before JWKS resolution, cache JWKS responses with sensible TTLs, apply backoff/circuit-breaking around JWKS fetch failures, and monitor or restrict outbound access to the JWKS endpoint. Ensure identity-provider/JWKS endpoints have appropriate capacity and rate-limit policies, but do not rely on the upstream provider as the primary mitigation.

How to confirm the fix worked

Confirm that deployed Python environments use PyJWT 2.13.0 or later, for example with package inventory, SCA tooling, pip show PyJWT, pip freeze, poetry.lock, Pipfile.lock, requirements files, SBOMs, and container image scans. Validate running services rather than only source repositories. In a controlled test environment, send multiple JWTs with unique unknown kid header values to a protected endpoint and verify that the application does not produce a one-to-one outbound JWKS request for every token and does not degrade under modest invalid-token volume. Review application and egress logs to confirm reduced JWKS fetch frequency, stable authentication latency, and absence of repeated PyJWKClient fetch failures after patching.

Typical attack path

1. Discover or guess an API, web, or service endpoint that accepts JWT bearer tokens.
2. Craft JWTs with arbitrary payloads and headers containing random, nonexistent kid values.
3. Send a high volume of requests using those JWTs to endpoints that trigger token validation.
4. Cause the application to call PyJWKClient.get_signing_key() for each unknown kid.
5. Force repeated outbound HTTP requests from the application to the configured JWKS endpoint.
6. Amplify latency or failures if the JWKS provider rate-limits, times out, or returns transient errors.
7. Degrade authentication-dependent functionality or produce denial-of-service symptoms for legitimate users.

How to detect it

To determine whether this was already exploited, correlate application authentication logs, web/API access logs, outbound proxy logs, firewall egress logs, DNS logs, APM traces, and identity-provider/JWKS access logs. Look for spikes in requests with Authorization: Bearer tokens that fail validation, especially where each request contains a different kid value in the JWT header. On the application side, search for repeated PyJWT or PyJWKClient exceptions, repeated unknown signing-key messages, JWKS fetch timeouts, and increased authentication latency. On the network side, look for a sudden increase in outbound HTTP GET requests from applications to JWKS URLs such as /.well-known/jwks.json, /jwks.json, or OpenID Connect JWKS URIs, particularly when paired with 429, 5xx, timeout, or connection-reset responses. On the identity-provider side, look for abnormal JWKS endpoint request rates from the same application egress IPs without a corresponding legitimate key rotation event. Forensic review should focus on the time window around authentication degradation, elevated 401/403 responses, and outbound JWKS fetch failures.

• PyJWKClientError
• Unable to find a signing key that matches
• Fail to fetch data from the url
• get_signing_key
• PyJWKClient.get_signing_key
• /.well-known/jwks.json
• /jwks.json
• Authorization: Bearer
• "kid"
• jwks_uri
• HTTP 429
• Read timed out
• Connection reset by peer

What your security team should do

• Prioritize upgrade of internet-facing services and authentication gateways that use PyJWT with PyJWKClient for JWKS-based JWT validation.
• Set a minimum allowed PyJWT version of 2.13.0 in dependency policy, CI checks, SCA rules, and base images.
• Search code for PyJWKClient and get_signing_key usage to identify applications where attacker-supplied JWT headers can trigger JWKS lookups.
• Add or tune rate limits on unauthenticated and authentication-failure-heavy endpoints that process bearer tokens.
• Implement observability for outbound JWKS fetch volume, JWKS fetch failures, JWT validation failures, and authentication latency.
• Review identity-provider logs for spikes in JWKS requests from application egress addresses, especially paired with high invalid-token rates.
• Prepare detection content for repeated unknown kid values and PyJWKClientError events, even though public exploit maturity and EPSS are currently low.
• If patching is delayed, add temporary circuit breakers, caching, and backoff around JWKS retrieval and consider blocking abusive sources at the edge.