jpadilla
Security Vulnerability
Hi Team, The pyJWT version 2.10.1 been reported as a high vulnerability on NVD database(CVE-2025-45768) and in blackduck as well(BDSA-2025-8013). Since this is a high severity can you please please look into this issue and if possible provide us a tentative date on the new releases.
Issue description: Pyjwt is vulnerable to weak encryption due to insufficient HMAC and RSA key length in the JSON web signature (JWS) implementation. A remote attacker could exploit this Vulnerability in order to manipulate data or gain unauthorized access.
My 2 cents' worth on this, after a bit of web research: This CVE, and about six more on other JWT library implementations, are listed here: https://gist.github.com/ZupeiNie and several issues were raised by the same team against some of those libs (which all went nowhere AFAICT, with not a single response to maintainers' requests for details/clarifications).
The "insufficient key length" seems to refer to the fact that pyjwt does not enforce that a key (and of course I'm not talking about the "none" algorithm) has "sufficient" length, see also https://github.com/jpadilla/pyjwt/issues/1009.
IMHO this is far from being a high-severity vulnerability. It would perhaps have been a good idea to implement a length check before first release, just to avoid inadvertent misuse. Now, it would be an incompatible, breaking change.
I would have to agree with the evaluation of @JanEgner. This does not make Pyjwt "vulnerable to weak encryption". If you produce a JWT using a key of insufficient length for the purpose you want to use it for, then your code is vulnerable to weak encryption, not Pyjwt. A library should never decide that my key length is insufficient, as it has no way to determine what the goal of my token is.
But how can we avoid this appearing as a high-risk vulnerability in BlackDuck?
@panva said,
dispute it (the CVE) at the source.
The current CVE situation is likely affecting the ecosystem of pyjwt's 6 million daily downloads. What are the next steps? Is anybody from PyJWT team (@jpadilla ? @mark-adams ?) working on a disputation? Or will it be a new optional parameter in pyjwt's next release to allow opt-in for a key length check thus make CVE system happy?
https://github.com/panva/jose/discussions/813
I've tried disputing all of the ones coming from this source but I don't think that's the way it works. @jpadilla and I talked about it and I guided him to do the same I did for https://www.npmjs.com/package/jose (35M weekly across npm and jsDelivr). The aim is to reject them, in the meantime, have them marked as disputed.
@jpadilla and I talked about it and I guided him to do the same I did
@panva , how did you get in touch with @jpadilla ? I sent him an email to the email address listed on his github profile yesterday. Did not hear back from him, yet. As the maintainer of another repo that accounts for half of pyjwt's daily downloads, I would like to understand the plan here so that we can act accordingly for our own downstream ecosystem.
I'm looking into disputing the score. I'll likely still introduce minimum length requirements throughout. Next release would warn and allow you to opt-in to strict enforcement.
Hi all,
I'm also encountering this vulnerability issue in PyJWT flagged by Checkmarx. We're seeing a high severity warning in our pipeline due to this.
- Tool: Checkmarx
- PyJWT version: 2.10.1
- Severity: High
This is currently blocking us from pushing to production due to our security policies. It would be great to get a fix or a mitigation recommended soon.
Thanks for your work on PyJWT!
here is a relevant potential fix https://github.com/jpadilla/pyjwt/pull/1085
I'm also encountering this vulnerability issue in
PyJWTflagged by Checkmarx. We're seeing a high severity warning in our pipeline due to this.
The assignment is disputed. As a matter of fact all assignments from this source are unanomously disputed. There is no ground for tooling to flagging this other than having out of date data.
The assignment is disputed. As a matter of fact all assignments from this source are unanomously disputed. There is no ground for tooling to flagging this other than having out of date data.
Thanks for the information. Indeed https://nvd.nist.gov/vuln/detail/CVE-2025-45768 has been marked as disputed. Do you know whether https://github.com/advisories/GHSA-xpf8-484v-j9w6 will also need to be disputed?
@rayluo The information i have from github is that all of these will remain unreviewed such that no tooling from github would start notifying users.
Hi, what is the status of this issue? @jpadilla I see 2 open pull requests
joserfc implemented the key length check at import_key step:
- https://github.com/authlib/joserfc/blob/main/src/joserfc/_rfc7518/oct_key.py#L90-L92
- https://github.com/authlib/joserfc/blob/main/src/joserfc/_rfc7518/rsa_key.py#L169-L171
Hi Team,
We're also running into this vulnerability warning for PyJWT(v2.10.1) in our pipeline. Our security tool (Checkmarx) is flagging it as High severity and it is blocking our production deployment.
Tool: Checkmarx PyJWT version: <=2.10.1 Severity: High
It would be very helpful if we could get an update on whether a fix or mitigation is planned, or if there is any recommended workaround for now.
Hi, Our Black Duck scan flagged BDSA-2025-8013 for PyJWT (weak encryption due to insufficient HMAC/RSA key lengths). We understand this is disputed, but it’s still showing as High severity. Any update or guidance on this? Thanks!
