jsonwebtoken pinned to 0.4.0 — pre-fix algorithm confusion

The manifest contains:

"jsonwebtoken": "0.4.0",

The brief explicitly cites jsonwebtoken <= 8.5.1 as vulnerable to the algorithm-confusion class of bugs; 0.4.0 is dramatically older and is vulnerable to all of: CVE-2015-9235 (algorithm confusion when both HMAC and RSA keys are accepted), CVE-2022-23529/23539/23540/23541 (signature/algorithm validation flaws fixed in 9.0.0), and the alg: none bypass. 0.4.0 has no algorithms option whitelisting at all.

1. Pull a valid token from the app.
2. Strip the signature and set alg to none in the header ({"alg":"none","typ":"JWT"}.<claims>.).
3. Submit it to any endpoint that calls jwt.verify — 0.4.0 accepts unsigned tokens.
4. Alternatively, sign forged claims with HS256 using the server's RSA public key.

Full authentication bypass anywhere jsonwebtoken.verify is used. No credentials needed.

Line confirms "jsonwebtoken": "0.4.0" as an exact pin — this is from 2014 and predates every algorithm-confusion/alg:none fix, including CVE-2015-9235 and the CVE-2022-2353x series fixed in 9.0.0. Juice Shop indeed uses this library to verify JWTs (e.g., in lib/insecurity.ts), so any endpoint behind jwt.verify is reachable from unauthenticated network input. The scope explicitly states to treat the app as production and not dismiss findings due to its training nature. The PoC (alg=none token or HS256-signed-with-RSA-pubkey) is directly applicable to this version.

package.json line pins "jsonwebtoken": "0.4.0", which predates CVE-2015-9235 and lacks any algorithms whitelist, so an unauthenticated remote attacker can forge tokens by setting alg:none or HS-vs-RS confusing the verifier — the PoC shows this requires only an HTTP request, no credentials and no victim interaction. Successful exploitation impersonates any user (including admin) anywhere jwt.verify gates access, yielding full read, full write, and the ability to disrupt service via privileged actions (H/H/H). Scope is Unchanged because the auth bypass operates within the same application/security authority that issues the JWTs. AC is Low: trivial header manipulation with no special preconditions visible in the manifest.