GHSA-jc38-x7x8-2xc8 has wrong affected version info?

[oldpec]

Description

GHSA-jc38-x7x8-2xc8

has:
Affected versions <= 4.2.99
Patched versions None

but from what I can see it is fixed on branches, eg:
#655

As a side effect

roave/security-advisories

has picked up the details from the GHSA

Roave/SecurityAdvisories@d59bd7f

and is blocking all installs of web-token/jwt-framework

- web-token/jwt-framework is locked to version 4.1.7 and an update of this package was not requested.
    - roave/security-advisories dev-latest conflicts with web-token/jwt-framework <=4.2.99.

[Spomky]

Thanks for the detailed report. You're right on both counts.

1. The advisory metadata is wrong. The fix for GHSA-jc38-x7x8-2xc8 is already released in 3.4.10, 4.0.7 and 4.1.7. The Affected <= 4.2.99 / Patched: None values are incorrect, which is why roave/security-advisories ends up conflicting with every version. I'm correcting the advisory to set the patched versions (3.4.10 / 4.0.7 / 4.1.7) and the proper affected ranges, and to list the split packages (web-token/jwt-library, web-token/jwt-bundle, web-token/jwt-experimental) alongside web-token/jwt-framework so the constraints resolve correctly.

2. Recommendation: avoid depending on web-token/jwt-framework directly. web-token/jwt-framework is the development monorepo (it replaces all the real packages). Requiring it pulls the entire codebase into your project, including web-token/jwt-experimental, which contains experimental and/or deprecated algorithms (e.g. Blake2b, ES256K, HS1, RS1, A*CTR, AES-CCM variants, ChaCha20-Poly1305, etc.). You almost never want those in your dependency tree.

Prefer the focused packages instead:

• web-token/jwt-library: the core library (keys, signatures, encryption with the standard, recommended algorithms);
• web-token/jwt-bundle: if you're on Symfony.

Only add web-token/jwt-experimental explicitly if you have a specific, justified need for one of those algorithms. This keeps your attack surface smaller and your dependency footprint clean.

[hostep]

@Spomky: I did attempt to fix those in:

• [GHSA-jc38-x7x8-2xc8] PHP JWT Framework: JWSVerifier uses algorithm from unprotected header, enabling algorithm confusion attacks github/advisory-database#8095
• [GHSA-3prj-6hqw-cm82] PHP JWT Library: PBES2-HS*+A*KW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service github/advisory-database#8096

But I used the "Suggest improvements for this vulnerability" form to adapt them and maybe that form isn't doing exactly what is needed, so maybe try to double check those suggestions.

As for the wrong package being used, we use it for many of our projects that are based on the popular Magento e-commerce platform which has this package as requirement (in their JWTFrameworkAdapter module):

$ composer why web-token/jwt-framework
magento/module-jwt-framework-adapter 100.4.5 requires web-token/jwt-framework (^4.0)
magento/product-community-edition    2.4.9   requires web-token/jwt-framework (^4.0)
web-token/jwt-framework              4.1.7   replaces web-token/jwt-bundle (self.version)
web-token/jwt-framework              4.1.7   replaces web-token/jwt-experimental (self.version)
web-token/jwt-framework              4.1.7   replaces web-token/jwt-library (self.version)

Do you believe this is incorrect? If yes, let me know and I'll try to inform the Magento developers so they can switch to the correct dependency.

[stof]

@hostep they should depend on web-token/jwt-library