Security Vulnerability

[nishanth77]

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.

[JanEgner]

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 #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.

[eavdmeer]

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.

[CedigTiagoSerra]

But how can we avoid this appearing as a high-risk vulnerability in BlackDuck?

[panva]

@CedigTiagoSerra dispute it at the source.

[auvipy]

I was wandering why this was reported publicly?

[CedigTiagoSerra]

@panva how I do that? Can I "exclude" this from blackduck scan?

[rayluo]

@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?

[panva]

panva/jose#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.

[rayluo]

@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.

[jpadilla]

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.

[Syed-Mujeeb]

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!

[auvipy]

here is a relevant potential fix #1085

[panva]

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.

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.