[GHSA-9gxv-x7rp-r2hc] gree/jose - "None" Algorithm treated as valid in tokens

[RainSignal]

Updates

• Affected products
• CWEs

Comments

1. Patched version exists (2.2.1)

The advisory states no solution is available, but version 2.2.1
contains a fix. The patch can be verified at:
https://github.com/nov/jose-php/blob/2.2.1/src/JOSE/JWS.php

The fix in 2.2.1 addresses the algorithm confusion attack in
_verify() by adding a $using_autodetected_alg flag. When the
algorithm is auto-detected from the JWT header (i.e. $expected_alg
is not explicitly provided by the caller), HMAC algorithms (HS256,
HS384, HS512) are now explicitly rejected with an exception:
"HMAC algs MUST be explicitly specified as $expected_alg"

This prevents attackers from changing the algorithm in the JWT
header from RS256 to HS256 and using the public key as the HMAC
secret to forge a valid signature.

2. Additional fix: timing attack

Version 2.2.1 also fixes a timing attack vulnerability by replacing
direct string comparison (===) with hash_equals() for HMAC
signature verification, preventing timing-based side-channel attacks.

3. Description is incorrect

The current description refers to vulnerabilities in other JWT
libraries (node-jsonwebtoken, pyjwt, namshi/jose, php-jwt, jsjwt)
and does not describe the actual vulnerability in gree/jose. The
correct description should be:

The _verify() method in JOSE_JWS trusts the algorithm specified
in the JWT header when $expected_alg is not explicitly provided
by the caller. This allows an attacker to change the algorithm
from RS256 to HS256 in the token header and sign the token using
the server's public key as the HMAC secret, bypassing signature
verification entirely.