auth0/node-jsonwebtoken

const SUPPORTED_ALGS = ['RS256', 'RS384', 'RS512', 'ES256', 'ES384', 'ES512', 'HS256', 'HS384', 'HS512', 'none'];

The algorithm families and the algorithm-to-key-type mapping are declared independently in sign.js, verify.js and lib/validateAsymmetricKey.js. Only the first two gate the PS algorithms on platform support. verify.js even declares two identical RSA lists (PUB_KEY_ALGS and RSA_KEY_ALGS). The lists agree today, but adding or removing an algorithm means editing three places, and missing one leaves sign and verify disagreeing about what is allowed.

Move the algorithm families and the key-type mapping into one shared module under lib/, apply the PS-support gate there once, and import that module from all three files.

if (header.alg.startsWith('HS') && secretOrPublicKey.type !== 'secret') {

Take a token with an empty signature part, an alg of HS256 and a caller who passes algorithms: ['HS256']. If the key resolves to null or undefined, every earlier guard passes: lines 108, 112, 116, 120 and 144. Execution then reads .type on null and throws a TypeError. A common setup triggers this: an async key resolver that returns no key for an unknown kid. The attacker controls both the kid and the empty signature. The throw happens inside the key-resolver callback instead of reaching the caller's done callback, so it can surface as an uncaught exception or unhandled rejection and take the process down. Line 150 has the same problem for RS, PS and ES algorithms.

Once the key is resolved, and before the algorithm and key-type checks, return done(new JsonWebTokenError('secret or public key must be provided')) whenever the key is null or undefined and the header algorithm is not none. Add tests for unsigned tokens with a missing key under explicit HS and RS algorithm lists.

if (typeof payload[claim] !== 'undefined') {
  return failure(new Error('Bad "options.' + key + '" option. The payload already has an "' + claim + '" property.'));
}

This check runs inside Object.keys(...).forEach(...), so the return only exits that iteration. In callback mode, failure() calls the callback with the error and then execution carries on into signing. The callback is wrapped in once() only after this point, so it is called again with a valid signed token. A caller who passes, say, audience while the payload already has aud sees an error and then a success, and the token keeps the payload's original claim. Depending on the caller, that means double responses, a "headers already sent" error, or a token issued after an error was reported. Sync mode is not affected, because failure() throws there.

Replace the forEach with a plain for...of loop so return failure(...) exits sign. Alternatively, wrap the callback in once() before the first possible failure() call. Add an async test asserting the callback runs exactly once on this conflict.

const parts = jwtString.split('.');
...
decodedToken = decode(jwtString, { complete: true });

verify splits, base64-decodes and JSON-parses the attacker-supplied token before the signature is checked, and jws.verify then decodes it a second time. The work grows only linearly with input size, so this is not an amplification bug. Still, the library has no upper bound of its own: we searched the production code for a length check and found none. Protection against oversized tokens depends entirely on every caller's HTTP layer.

Add an optional maxTokenLength setting with a conservative default of a few kilobytes. Reject longer tokens with a JsonWebTokenError before any splitting or parsing.

secretOrPublicKey = createPublicKey(secretOrPublicKey);
...
secretOrPublicKey = createSecretKey(typeof secretOrPublicKey === 'string' ? Buffer.from(secretOrPublicKey) : secretOrPublicKey);

Both entry points carry the same try-asymmetric-then-fall-back-to-secret cascade. With only two copies this is acceptable, but a fix to one copy could easily miss the other.

If a third copy appears, extract a small lib/toKeyObject helper that takes the asymmetric factory as an argument.