Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Summary

PostCSS auto-detects a '/*# sourceMappingURL=... */' comment inside the CSS text it is asked to parse and, unless the caller explicitly passes 'map: false', attempts to load that path from disk as a "previous source map." This happens on every 'postcss.parse()' / 'postcss().process()' call by default (opt-out, not opt-in). 'loadMap()' builds the candidate path via 'join(dirname(opts.from), annotation)', where annotation is the raw, attacker-controlled string from the CSS comment. 'path.join()' normalizes but does not sandbox '..' segments, so a '../../../' prefix walks the resolved path outside the intended directory. If 'opts.from' is not set at all, the annotation is used completely unmodified -- an absolute path in the CSS comment is read verbatim. 8.5.12 already fixed a strictly worse variant of this (any file, any extension, could be read) by requiring the resolved path to end in '.map' 'loadFile()'. That fix did not address the traversal itself, only the target extension. Since the 'join(dirname(file), map)' logic has existed unchanged since PostCSS 8.0.0 (Feb 2020), any file ending in '.map' remains readable through this path in the current release (8.5.16). Once loaded, 'MapGenerator.isMap()' treats the mere presence of a loaded "previous map" as an implicit request to generate 'result.map', even when the caller never set the map option. If the loaded map has a 'sourcesContent' field (common for maps emitted by bundlers/transpilers), that content is merged into 'result.map' and returned to the caller -- disclosing the traversed-to file's content to whoever supplied the CSS. This issue affects PostCSS versions through 8.5.17.