Firebase Admin SDK version 11.4.0 is a minor release over 11.3.0, primarily focusing on internal improvements and dependency updates. Both versions provide a comprehensive suite of tools for Firebase server-side development, enabling developers to manage Firebase projects, authenticate users, and access Firebase services like Firestore, Realtime Database, and Cloud Storage from Node.js environments.
A key similarity is the continued support for core dependencies like uuid, jsonwebtoken, and the Google Cloud client libraries for Storage and Firestore. This ensures consistent functionality for common tasks like generating unique identifiers, handling JWT authentication, and interacting with cloud storage and database services. The developer experience remains largely consistent, as both versions expose the same API surface.
One notable difference that is not visible on the package.json is that release 11.4.0 contains some improvements related to credential handling, particularly for environments utilizing external account authentication instead of service accounts directly. While both releases maintain the same API towards developers, version 11.4.0 features a slightly larger unpacked size, indicating potentially tweaked configurations or added internal assets. Developers upgrading from 11.3.0 should expect a seamless transition, benefitting from potential stability enhancements and refined credential management, without necessitating code modifications related to the public API.
All the vulnerabilities related to the version 11.4.0 of the package
jsonwebtoken unrestricted key type could lead to legacy keys usage
Versions <=8.5.1 of jsonwebtoken library could be misconfigured so that legacy, insecure key types are used for signature verification. For example, DSA keys could be used with the RS256 algorithm.
You are affected if you are using an algorithm and a key type other than the combinations mentioned below
| Key type | algorithm | |----------|------------------------------------------| | ec | ES256, ES384, ES512 | | rsa | RS256, RS384, RS512, PS256, PS384, PS512 | | rsa-pss | PS256, PS384, PS512 |
And for Elliptic Curve algorithms:
| alg | Curve |
|-------|------------|
| ES256 | prime256v1 |
| ES384 | secp384r1 |
| ES512 | secp521r1 |
Update to version 9.0.0. This version validates for asymmetric key type and algorithm combinations. Please refer to the above mentioned algorithm / key type combinations for the valid secure configuration. After updating to version 9.0.0, If you still intend to continue with signing or verifying tokens using invalid key type/algorithm value combinations, you’ll need to set the allowInvalidAsymmetricKeyTypes option to true in the sign() and/or verify() functions.
There will be no impact, if you update to version 9.0.0 and you already use a valid secure combination of key type and algorithm. Otherwise, use the allowInvalidAsymmetricKeyTypes option to true in the sign() and verify() functions to continue usage of invalid key type/algorithm combination in 9.0.0 for legacy compatibility.
jsonwebtoken's insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC
Versions <=8.5.1 of jsonwebtoken library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the secretOrPublicKey argument from the readme link) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens.
You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function.
Update to version 9.0.0.
There is no impact for end users
jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify()
In versions <=8.5.1 of jsonwebtoken library, lack of algorithm definition and a falsy secret or key in the jwt.verify() function can lead to signature validation bypass due to defaulting to the none algorithm for signature verification.
You will be affected if all the following are true in the jwt.verify() function:
Update to version 9.0.0 which removes the default support for the none algorithm in the jwt.verify() method.
There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the none algorithm. If you need 'none' algorithm, you have to explicitly specify that in jwt.verify() options.
