CVE-2026-48524
Pyjwt Project Pyjwt ≤ 2.13.0
Raw vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:LSummary
CVE-2026-48524 is a low-severity Improper Cleanup on Thrown Exception (CWE-460) vulnerability in Pyjwt Project Pyjwt. Its CVSS base score is 3.7 (Low).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Client Execution (T1203); ranked at the 26th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SC-24 (Fail in Known State) and SI-17 (Fail-safe Procedures) — see the control section below for these in your framework.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-32916
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 1 hardening rule · 1 OS baseline
—
Mitigating Controls (NIST 800-53 r5) AI
Requires the system to fail to a known state on indicated failures, directly forcing proper state cleanup instead of leaving inconsistent state after an exception.
Mandates explicit fail-safe procedures on failures, which structurally enforces cleanup actions that the weakness omits.
Requires application of security engineering principles (e.g., fail-safe, complete mediation) during design that would eliminate improper exception cleanup.
Requires generation of appropriate error messages on exceptional conditions, directly enforcing correct handling rather than silent or incorrect behavior.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly enforce proper exception handling and resource cleanup.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can detect missing cleanup paths, thereby mitigating the weakness before deployment.
Documented operating procedures may specify exception handling but do not guarantee implementation.
Logging captures unhandled exceptions, aiding detection but not preventing the weakness.
Monitoring can surface unhandled exceptions but does not enforce proper handling.
Secure SDLC mandates exception-handling and cleanup practices that reduce improper state after thrown exceptions.
Application security requirements can specify robust exception handling and resource-release rules.