Bug 2385868 (CVE-2025-45768)
| Summary: | CVE-2025-45768 pyjwt: pyjwt Weak Encryption Vulnerability | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability-draft | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | adudiak, amctagga, anpicker, anthomas, aoconnor, aprice, bdettelb, bniver, carogers, caswilli, dnakabaa, doconnor, dranck, eglynn, ehelms, erezende, flucifre, ggainey, gmeno, groman, haoli, hasun, hkataria, jajackso, jcammara, jfula, jjoyce, jkoehler, jmitchel, jneedle, joehler, jowilson, jsamir, jschluet, juwatts, jwendell, jwong, kaycoth, kegrant, kholdawa, koliveir, kshier, lball, lbrazdil, lchilton, lcouzens, lhh, ljawale, lphiri, lsvaty, luizcosta, mabashia, mbenjamin, mburns, mgarciac, mhackett, mhulan, mminar, mskarbek, ngough, nmoumoul, nweather, nyancey, oalbrigt, oezr, omaciel, ometelka, osousa, pbraun, pcreech, pgrist, ptisnovs, rbiba, rbobbitt, rcernich, rchan, sfeifer, shvarugh, simaishi, smallamp, smcdonal, sostapov, sskracic, stcannon, syedriko, teagle, tfister, thavo, tmalecek, tpfromme, ttakamiy, vereddy, veshanka, xdharmai, yguenane, zdohnal |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
A flaw was found in pyjwt. The library uses weak encryption, allowing an attacker to potentially decrypt sensitive data. A network-based attacker can exploit this vulnerability without authentication, possibly resulting in a denial of service or data exposure. This weakness stems from the use of inadequate cryptographic algorithms.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2385904, 2385905, 2385907, 2385902, 2385903, 2385906, 2389943, 2389944, 2389945, 2389946, 2392912, 2392913 | ||
| Bug Blocks: | |||
|
Description
OSIDB Bzimport
2025-07-31 21:01:54 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
Correction. There is no fix available for RHEL10 either. 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. |