Ant Design (antd) has released version 1.3.0, building upon the foundation of its previous stable version, 1.2.1. Both versions provide a comprehensive UI design language and React-based component library for building elegant and efficient user interfaces. This makes antd a strong choice for developers prioritizing design consistency and development speed.
A notable change in the newer version is in dependency management. Specifically within the dependencies, rc-table has been updated from version 4.0.6 to 4.1.1, while rc-upload has been updated from 1.12.0 to 1.13.0. Rc-slider was also updated from 3.6.2 to 3.7.0. These updates likely include bug fixes, performance improvements, and potentially new features in the table, upload, and slider components. Developers using these components should review the changelogs of rc-table, rc-upload and rc-slider for specific details on the updates.
Both versions depend on a wide array of rc-* components, such as rc-form, rc-menu, rc-select, and others, showing an overall stable dependency base. The development dependencies remain largely consistent between the two versions, including tools for testing, linting, and building the library. This ensures a consistent development environment for contributing to or customizing the antd library. The library is released under the MIT license. Developers can leverage the library's versatile components to accelerate web application development, while also benefiting from the consistent design and well-maintained ecosystem around the Ant Design project.
All the vulnerabilities related to the version 1.3.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.