Ant Design saw a small version bump from 1.3.2 to 1.4.0, representing incremental improvements and bug fixes within the library. Both versions are described as a UI design language, highlighting their purpose of providing a comprehensive set of React components for building user interfaces.
The core dependencies remain largely consistent between the two versions, indicating a stable foundation. Developers familiar with version 1.3.2 should find the upgrade to 1.4.0 seamless. One notable change within dependencies is the updated version of rc-table dependency, shifting from "~4.1.1" to "~4.1.4". This suggests enhancements or fixes specifically related to the table component.
In the devDependencies section, the publishing tool bisheng moved from "^0.5.0" to "^0.7.0", marking a significant upgrade for documentation and site generation. While other devDependencies remain largely the same, this change indicates potential improvements in the build and deployment processes of the Ant Design library itself.
Developers using Ant Design can expect a gradual evolution rather than a revolutionary change. The consistent set of dependencies indicates reliability, and small version increments of dependencies suggest refined functionalities. For those already using Ant Design, upgrading provides the benefit of bug fixes and incremental improvements, while new users can confidently choose either version as a solid starting point.
All the vulnerabilities related to the version 1.4.0 of the package
Nunjucks autoescape bypass leads to cross site scripting
In Nunjucks versions prior to version 3.2.4, it was possible to bypass the restrictions which are provided by the autoescape functionality. If there are two user-controlled parameters on the same line used in the views, it was possible to inject cross site scripting payloads using the backslash \ character.
If the user-controlled parameters were used in the views similar to the following:
<script>
let testObject = { lang: '{{ lang }}', place: '{{ place }}' };
</script>
It is possible to inject XSS payload using the below parameters:
https://<application-url>/?lang=jp\&place=};alert(document.domain)//
The issue was patched in version 3.2.4.
Regular Expression Denial of Service (ReDoS) in micromatch
The NPM package micromatch prior to version 4.0.8 is vulnerable to Regular Expression Denial of Service (ReDoS). The vulnerability occurs in micromatch.braces() in index.js because the pattern .* will greedily match anything. By passing a malicious payload, the pattern matching will keep backtracking to the input while it doesn't find the closing bracket. As the input size increases, the consumption time will also increase until it causes the application to hang or slow down. There was a merged fix but further testing shows the issue persisted prior to https://github.com/micromatch/micromatch/pull/266. This issue should be mitigated by using a safe pattern that won't start backtracking the regular expression due to greedy matching.
Regular Expression Denial of Service (ReDoS) in braces
A vulnerability was found in Braces versions prior to 2.3.1. Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) attacks.
Regular Expression Denial of Service in braces
Versions of braces prior to 2.3.1 are vulnerable to Regular Expression Denial of Service (ReDoS). Untrusted input may cause catastrophic backtracking while matching regular expressions. This can cause the application to be unresponsive leading to Denial of Service.
Upgrade to version 2.3.1 or higher.
Uncontrolled resource consumption in braces
The NPM package braces fails to limit the number of characters it can handle, which could lead to Memory Exhaustion. In lib/parse.js, if a malicious user sends "imbalanced braces" as input, the parsing will enter a loop, which will cause the program to start allocating heap memory without freeing it at any moment of the loop. Eventually, the JavaScript heap limit is reached, and the program will crash.
Prototype pollution in object-path
A prototype pollution vulnerability has been found in object-path <= 0.11.4 affecting the set() method. The vulnerability is limited to the includeInheritedProps mode (if version >= 0.11.0 is used), which has to be explicitly enabled by creating a new instance of object-path and setting the option includeInheritedProps: true, or by using the default withInheritedProps instance. The default operating mode is not affected by the vulnerability if version >= 0.11.0 is used. Any usage of set() in versions < 0.11.0 is vulnerable.
Upgrade to version >= 0.11.5
Don't use the includeInheritedProps: true options or the withInheritedProps instance if using a version >= 0.11.0.
Read more about the prototype pollution vulnerability
If you have any questions or comments about this advisory:
Prototype Pollution in object-path
This affects the package object-path before 0.11.6. A type confusion vulnerability can lead to a bypass of CVE-2020-15256 when the path components used in the path parameter are arrays. In particular, the condition currentPath === '__proto__' returns false if currentPath is ['__proto__']. This is because the === operator returns always false when the type of the operands is different.
Prototype Pollution in object-path
object-path is vulnerable to Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution'). The del() function fails to validate which Object properties it deletes. This allows attackers to modify the prototype of Object, causing the modification of default properties like toString on all objects.