NestJS is a progressive Node.js framework designed for building efficient, reliable and scalable server-side applications. Examining versions 4.3.1 and 4.3.0 of the @nestjs/common package reveals subtle but potentially important distinctions for developers. Both versions share identical dependencies, relying on cli-color for enhanced console output, class-validator for robust data validation, and class-transformer for transforming plain JavaScript objects. They also share the same peer dependency on reflect-metadata, a crucial library for enabling reflection capabilities within TypeScript applications, and the same MIT license, authored by Kamil Mysliwiec.
The key difference lies in the release date and potentially very minor bug fixes or internal improvements made between the two versions. Version 4.3.1 was released approximately two hours after 4.3.0. While the core functionalities remain consistent, developers should opt for the newer 4.3.1 to ensure they are leveraging the most up-to-date iteration of the package, even with the minor difference. This practice helps mitigate potential risks associated with undiscovered bugs or compatibility issues present in the earlier release. For those using semantic versioning, this patch version suggests a small, safe update for NestJS projects seeking the most stable and current feature set within the 4.3.x range. Consider reviewing the changelog, if available, to confirm the specifics of the updates included.
All the vulnerabilities related to the version 4.3.1 of the package
nest allows a remote attacker to execute arbitrary code via the Content-Type header
File Upload vulnerability in nestjs nest prior to v.11.0.16 allows a remote attacker to execute arbitrary code via the Content-Type header.
SQL Injection and Cross-site Scripting in class-validator
In TypeStack class-validator, validate() input validation can be bypassed because certain internal attributes can be overwritten via a conflicting name. Even though there is an optional forbidUnknownValues parameter that can be used to reduce the risk of this bypass, this option is not documented and thus most developers configure input validation in the vulnerable default manner. With this vulnerability, attackers can launch SQL Injection or XSS attacks by injecting arbitrary malicious input.
The default settings for forbidUnknownValues has been changed to true in 0.14.0.
NOTE: a software maintainer agrees with the "is not documented" finding but suggests that much of the responsibility for the risk lies in a different product.
Inefficient Regular Expression Complexity in validator.js
validator.js prior to 13.7.0 is vulnerable to Inefficient Regular Expression Complexity
Prototype pollution in class-transformer
class-transformer through 0.2.3 is vulnerable to Prototype Pollution. The 'classToPlainFromExist' function could be tricked into adding or modifying properties of 'Object.prototype' using a 'proto' payload.
