NestJS developers will find subtle but important updates between @nestjs/common versions 4.5.1 and 4.5.2. Both versions share the same core dependencies, including cli-color for command-line styling, class-validator for robust data validation, and class-transformer for object transformation. They also rely on reflect-metadata as a peer dependency. The fundamental architecture and components exposed by @nestjs/common remain consistent, ensuring a smooth transition for projects already using version 4.5.1.
The key difference is the release date; version 4.5.2 was published on December 22, 2017, a week after version 4.5.1's release on December 15, 2017. This suggests that version 4.5.2 likely includes bug fixes, minor performance improvements, or tweaks addressing specific issues identified in the earlier 4.5.1 release. While the package manifest doesn't explicitly detail these changes, the rapid succession of releases hints at a quick response to community feedback or internal testing. Developers upgrading should anticipate increased stability and potentially subtle enhancements without any breaking changes, ensuring continued compatibility with existing NestJS applications. Due to the lack of detailed changelog it's wise to ensure proper workflow for testing and verifying updates in a development environment prior to deploying to production.
All the vulnerabilities related to the version 4.5.2 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.
