Bug 2385868 (CVE-2025-45768) - CVE-2025-45768 pyjwt: pyjwt Weak Encryption Vulnerability
Summary: CVE-2025-45768 pyjwt: pyjwt Weak Encryption Vulnerability
Keywords:
Status: NEW
Alias: CVE-2025-45768
Product: Security Response
Classification: Other
Component: vulnerability-draft
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On: 2385904 2385905 2385907 2385902 2385903 2385906 2389943 2389944 2389945 2389946 2392912 2392913
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-07-31 21:01 UTC by OSIDB Bzimport
Modified: 2025-12-03 04:37 UTC (History)
96 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2025-07-31 21:01:54 UTC
pyjwt v2.10.1 was discovered to contain weak encryption.

Comment 4 Oyvind Albrigtsen 2025-08-15 11:53:09 UTC
Is there a patch available? The versions where it's fixed is only available on RHEL10.

Example from RHEL9.6:
# python3 -m pip download --no-binary :all: --no-deps PyJWT
Collecting PyJWT
  Downloading pyjwt-2.10.1.tar.gz (87 kB)
     |████████████████████████████████| 87 kB 6.7 MB/s             
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Saved ./pyjwt-2.10.1.tar.gz
Successfully downloaded PyJWT

Comment 5 Oyvind Albrigtsen 2025-08-28 12:23:26 UTC
Correction. There is no fix available for RHEL10 either.

Comment 6 Sage McTaggart 2025-10-16 20:29:15 UTC
Disputed at MITRE, https://nvd.nist.gov/vuln/detail/CVE-2025-45768

Dear all: We were noticing our code was affected by this CVE, as we use pyjwt 2.4.0

Although the library enables the use of shorter key lengths, it would only be true if we invoked it in a horrible way, and intentionally chose shorter key lengths. In addition the key lengths are well within the recommended standards https://datatracker.ietf.org/doc/html/rfc7518 

We dug into the standards and could not easily find a recommended key length in the listed ones. The standard I would use is https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-5.pdf which supports personal information, and states that SHA 256 is an option thru 2030. 

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-117.pdf refers to passwords 

https://datatracker.ietf.org/doc/html/rfc2437 --really only goes into details relating to key length and password for RSA, does not provide suggestions for RSA. 

https://datatracker.ietf.org/doc/html/rfc7518 --The
   algorithms respectively use HMAC SHA-256, HMAC SHA-384, and HMAC
   SHA-512 as the PRF and use 128-, 192-, and 256-bit AES Key Wrap keys.
   Their derived-key lengths respectively are 16, 24, and 32 octets.

regarding JWT though:
The 

SHA 256 is the minimum algorithm used for HMAC and RSA. https://github.com/jpadilla/pyjwt/blob/6293865c82ef24af76455c2522806ac2b1c75d6b/docs/algorithms.rst#L7

In https://github.com/jpadilla/pyjwt/blob/master/jwt/api_jwt.py and https://github.com/jpadilla/pyjwt/blob/master/jwt/api_jws.py I do not see a reference to a minimum key length. My understanding is that it would thus be based off the accepted algorithm, as provided by the customer in some cases (asymmetric key encryption)

In conclusion, I agree with the dispute and don't think this is a valid CVE.


Note You need to log in before you can comment on or make changes to this bug.