What is the CVSS score of CVE-2026-48524?

CVE-2026-48524 has a CVSS 3.1 base score of 3.7 (Low). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L. EPSS exploitation probability: 0.0%.

Is there a public PoC exploit available for CVE-2026-48524?

Yes, a public proof-of-concept exploit is available for CVE-2026-48524. Prioritise patching immediately. EPSS: 0.0%.

Is there a patch available for CVE-2026-48524?

Yes, a patch is available for CVE-2026-48524. Update the affected software to the latest version immediately.

PyJWT CVE-2026-48524

EUVD-2026-32916 LOW

Improper Cleanup on Thrown Exception (CWE-460)

2026-05-28 GitHub_M

GHSA-fhv5-28vv-h8m8 PYSEC-2026-177

Information Disclosure Python

3.7

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

3.7 LOW

AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

Low

Lifecycle Timeline

Patch available

May 28, 2026 - 17:01 EUVD

Analysis Generated

May 28, 2026 - 15:55 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

40,697 pypi packages depend on pyjwt (4,610 direct, 36,482 indirect)

Ecosystem-wide dependent count for version 2.13.0.

DescriptionGitHub Advisory

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient.get_signing_key() forces a fresh HTTP request to the JWKS endpoint for every JWT with an unknown kid value, with no rate limiting. Since kid comes from the unverified token header, an attacker can trigger unlimited outbound requests. The vulnerability surfaces only when a JWKS fetch fails; an attacker can attempt to provoke that with sustained unknown-kid traffic, but the outcome depends on upstream JWKS-endpoint behavior (rate limiting, transient errors) which is beyond the attacker's control. This vulnerability is fixed in 2.13.0.

AnalysisAI

Unconstrained outbound JWKS requests in PyJWT's PyJWKClient.get_signing_key() allow unauthenticated remote attackers to amplify HTTP traffic toward a downstream JWKS endpoint by submitting JWTs carrying arbitrary, unrecognized kid values. All PyJWT versions prior to 2.13.0 are affected when the PyJWKClient class is used for signature verification. The availability impact is low (CVSS A:L) and exploitation success is gated on the upstream JWKS provider exhibiting rate limiting or transient failures; no public exploit code exists and this CVE does not appear in CISA KEV.

Technical ContextAI

PyJWT is a widely-deployed Python library for encoding and decoding JSON Web Tokens per RFC 7519. The PyJWKClient class provides JWKS-backed signature verification by fetching public keys from a remote JWKS URI. The vulnerable code path is get_signing_key(), which unconditionally issues a fresh outbound HTTP request to the JWKS endpoint whenever the kid (Key ID) claim in an incoming JWT header is not found in a local cache. The critical flaw is that the kid field is parsed from the unverified token header - base64-decoded but not yet cryptographically validated - meaning any caller can inject arbitrary kid values without needing a valid signature. The absence of rate limiting or negative-result caching for unknown kids means each such crafted token generates a distinct JWKS fetch. The assigned CWE-460 (Improper Cleanup on Thrown Exception) appears to be a mismatch; the root cause more closely aligns with CWE-770 (Allocation of Resources Without Limits or Throttling), and this discrepancy should be verified against the NVD record. The affected CPE is cpe:2.3:a:jpadilla:pyjwt:*:*:*:*:*:*:*:*, covering all versions without a stated lower bound.

RemediationAI

Upgrade PyJWT to version 2.13.0 or later, which is the vendor-confirmed fix as documented in GitHub Security Advisory GHSA-fhv5-28vv-h8m8 (https://github.com/jpadilla/pyjwt/security/advisories/GHSA-fhv5-28vv-h8m8). For environments that cannot immediately upgrade, implement application-layer rate limiting on JWT verification endpoints to cap the rate at which tokens with unknown kid values are processed per source IP or session - this directly limits the attacker's ability to generate sustained JWKS fetch volume. Alternatively, maintain an explicit allowlist of valid kid values and reject tokens presenting unrecognized kids before invoking get_signing_key(), eliminating the outbound request entirely for unknown keys; note that this requires operational overhead to update the allowlist when identity providers rotate keys. Aggressive local caching of JWKS responses with a short TTL (e.g., 60 seconds) can also reduce fetch frequency but does not eliminate the root cause for novel unknown kids.