CVE-2025-45768

Published Jul 31, 2025

Last updated a year ago

CVSS high 7.0
Jwt

Overview

Description
pyjwt v2.10.1 was discovered to contain weak encryption. NOTE: this is disputed by the Supplier because the key length is chosen by the application that uses the library (admittedly, library users may benefit from a minimum value and a mechanism for opting in to strict enforcement).
Source
cve@mitre.org
NVD status
Analyzed
CNA Tags
disputed
Products
pyjwt

Risk scores

CVSS 3.1

Type
Secondary
Base score
7
Impact score
4.7
Exploitability score
2.2
Vector string
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H
Severity
HIGH

Weaknesses

134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-311

Social media

Hype score
Not currently trending

  1. CVE-2025-45768 JWT Library Vulnerability https://t.co/hF17ClJrXI

    @VulmonFeeds

    31 Jul 2025

    56 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. CVE-2025-45768 pyjwt v2.10.1 was discovered to contain weak encryption. https://t.co/OzehEgM93v

    @CVEnew

    31 Jul 2025

    240 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. go-base is a Go RESTful API Boilerplate template with JWT Authentication, backed by PostgreSQL. In versions prior to 2026-05-18, the JWT signing secret is hardcoded to the known string "random", letting any attacker who reads the public repository forge tokens for arbitrary users, including admin roles, and completely bypass authentication on all protected endpoints. This value is set in two places: the dev.env template (line 10) and a programmatic fallback in cmd/serve.go (line 35), so the application uses it even when no .env file is present. The original mitigation in auth/jwt/tokenauth.go (lines 22 to 25) only caught the exact string "random", letting other weak secrets through, and replaced it with an in-memory key that was not persisted, invalidating all tokens on every restart and effectively causing a denial-of-service. This issue has been fixed in version 2026-05-18.•CVE-2026-48031
  2. SurrealDB before 3.1.0 silently substitutes the ES384 algorithm when a JWT access method is configured with ALGORITHM ES512 (DEFINE ACCESS ... TYPE JWT ALGORITHM ES512), because the underlying jsonwebtoken crate (v10.x) has no ES512 variant and the mapping defaults to ES384 without any error, warning, or log message. Users who supply the correct P-521 key for ES512 experience authentication handshake failures due to the curve mismatch with ES384 (which expects P-384), and tokens are rejected by external systems expecting genuine ES512 signatures. The flaw cannot be used to forge tokens or compromise data confidentiality or integrity, as ES384 remains cryptographically strong.•CVE-2026-63761
  3. Microsoft SharePoint Weak Authentication Vulnerability•CVE-2026-55040
  4. A flaw was found in Keycloak. This JWT algorithm confusion vulnerability in the JWT Authorization Grant flow allows an attacker with valid client credentials to bypass signature verification. By forging an assertion, the attacker can create unauthorized access tokens. This enables the attacker to impersonate any federated user linked to the affected Identity Provider, leading to unauthorized access and potential privilege escalation.•CVE-2026-11800
  5. 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.•CVE-2026-48524

References

Sources include official advisories and independent security research.