Ant Design, a popular UI design language and React UI library, saw a minor version bump from 0.9.3 to 0.9.4 in early November 2015. While the core functionalities and dependencies remained largely consistent between the two releases, developers might find value in upgrading to 0.9.4 for subtle improvements and potential bug fixes. The dependency list, encompassing crucial components like rc-menu, rc-tabs, rc-table, and others from the rc-* family, remains identical, suggesting a focus on refining existing features rather than introducing significant architectural changes. Similarly, the development dependencies, crucial for building and contributing to the library, such as webpack, babel, and various ESLint plugins, are unchanged. This indicates a stable development environment and adherence to existing coding standards. The release dates highlight a very short timeframe between the releases which could hint to a patch for a bug found in the previous version. Although a comprehensive changelog is unavailable from this data, developers can infer that the upgrade likely addresses minor issues, performance tweaks, or improved compatibility within the existing component ecosystem. Therefore, upgrading from 0.9.3 to 0.9.4 offers a low-risk path to inheriting the latest refinements and bug fixes within the Ant Design framework.
All the vulnerabilities related to the version 0.9.4 of the package
semver vulnerable to Regular Expression Denial of Service
Versions of the package semver before 7.5.2 on the 7.x branch, before 6.3.1 on the 6.x branch, and all other versions before 5.7.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.
superagent vulnerable to zip bomb attacks
Affected versions of superagent
do not check the post-decompression size of ZIP compressed HTTP responses prior to decompressing. This results in the package being vulnerable to a ZIP bomb attack, where an extremely small ZIP file becomes many orders of magnitude larger when decompressed.
This may result in unrestrained CPU/Memory/Disk consumption, causing a denial of service condition.
Update to version 3.7.0 or later.
Prototype Pollution Protection Bypass in qs
Affected version of qs
are vulnerable to Prototype Pollution because it is possible to bypass the protection. The qs.parse
function fails to properly prevent an object's prototype to be altered when parsing arbitrary input. Input containing [
or ]
may bypass the prototype pollution protection and alter the Object prototype. This allows attackers to override properties that will exist in all objects, which may lead to Denial of Service or Remote Code Execution in specific circumstances.
Upgrade to 6.0.4, 6.1.2, 6.2.3, 6.3.2 or later.
qs vulnerable to Prototype Pollution
qs before 6.10.3 allows attackers to cause a Node process hang because an __ proto__
key can be used. In many typical web framework use cases, an unauthenticated remote attacker can place the attack payload in the query string of the URL that is used to visit the application, such as a[__proto__]=b&a[__proto__]&a[length]=100000000
. The fix was backported to qs 6.9.7, 6.8.3, 6.7.3, 6.6.1, 6.5.3, 6.4.1, 6.3.3, and 6.2.4.
mime Regular Expression Denial of Service when MIME lookup performed on untrusted user input
Affected versions of mime
are vulnerable to regular expression denial of service when a mime lookup is performed on untrusted user input.
Update to version 2.0.3 or later.
Prototype Pollution in extend
Versions of extend
prior to 3.0.2 (for 3.x) and 2.0.2 (for 2.x) are vulnerable to Prototype Pollution. The extend()
function allows attackers to modify the prototype of Object causing the addition or modification of an existing property that will exist on all objects.
If you're using extend
3.x upgrade to 3.0.2 or later.
If you're using extend
2.x upgrade to 2.0.2 or later.
cookiejar Regular Expression Denial of Service via Cookie.parse function
Versions of the package cookiejar before 2.1.4 are vulnerable to Regular Expression Denial of Service (ReDoS) via the Cookie.parse
function and other aspects of the API, which use an insecure regular expression for parsing cookie values. Applications could be stalled for extended periods of time if untrusted input is passed to cookie values or attempted to parse from request headers.
Proof of concept:
ts\nconst { CookieJar } = require("cookiejar");
const jar = new CookieJar();
const start = performance.now();
const attack = "a" + "t".repeat(50_000);
jar.setCookie(attack);
console.log(`CookieJar.setCookie(): ${performance.now() - start}ms`);
CookieJar.setCookie(): 2963.214399999939ms