MediumGHSA-7322-jrq4-x5hfCVE-2021-41106

File reference keys leads to incorrect hashes on HMAC algorithms

Published 29 Sept 2021 · Updated 8 Jul 2026

Affected packages

lcobucci/jwtComposer
Affected
>=3.4.0 <3.4.6
Fixed in
3.4.6
Update to the fixed version for your release line, for example:composer require lcobucci/jwt:^3.4.6
lcobucci/jwtComposer
Affected
>=4.0.0 <4.0.4
Fixed in
4.0.4
Update to the fixed version for your release line, for example:composer require lcobucci/jwt:^4.0.4
lcobucci/jwtComposer
Affected
>=4.1.0 <4.1.5
Fixed in
4.1.5
Update to the fixed version for your release line, for example:composer require lcobucci/jwt:^4.1.5

Details

Impact

Users of HMAC-based algorithms (HS256, HS384, and HS512) combined with Lcobucci\JWT\Signer\Key\LocalFileReference as key are having their tokens issued/validated using the file path as hashing key - instead of the contents.

The HMAC hashing functions take any string as input and, since users can issue and validate tokens, people are lead to believe that everything works properly.

Patches

All versions have been patched to always load the file contents, deprecated the Lcobucci\JWT\Signer\Key\LocalFileReference, and suggest Lcobucci\JWT\Signer\Key\InMemory as the alternative.

Workarounds

Use Lcobucci\JWT\Signer\Key\InMemory instead of Lcobucci\JWT\Signer\Key\LocalFileReference to create the instances of your keys:

-use Lcobucci\JWT\Signer\Key\LocalFileReference;
+use Lcobucci\JWT\Signer\Key\InMemory;

-$key = LocalFileReference::file(__DIR__ . '/public-key.pem');
+$key = InMemory::file(__DIR__ . '/public-key.pem');

Is GHSA-7322-jrq4-x5hf in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected lcobucci/jwt, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.