Vulnerabilities

PostCSS before 8.5.19 contains a path-traversal and information-exposure flaw in PreviousMap.loadFile(): when the 'from' option is unset, the library resolves an attacker-controlled sourceMappingURL without confining it to the CSS file's directory, accepting absolute paths or directory-traversal sequences. An application that parses untrusted CSS under these conditions can be made to read an unintended or attacker-chosen source-map file from the local filesystem. The loaded map's 'sources' and 'sourcesContent' fields, which typically embed original source code and internal file paths, may then be exposed to the application and potentially leaked to the attacker. Any application or build pipeline using PostCSS prior to 8.5.19 to process untrusted CSS with 'from' unset is affected, while deployments that always set 'from' or only handle trusted local CSS are not. No exploitation in the wild is currently reported (EPSS 0.5%, not in CISA KEV), but a public advisory with a proof-of-concept reference is available on the project's GitHub.

Do: Upgrade PostCSS to 8.5.19 or later and refresh lockfiles/rebuild affected applications and CI pipelines. As an interim mitigation, always set the 'from' option when parsing untrusted CSS, and audit services that accept user-supplied CSS (e.g., online converters or editors) for possible disclosure of source-map contents.

PostCSS 8.5.11 and earlier mishandle the /*# sourceMappingURL=PATH */ comment: the PreviousMap code dereferences PATH against the local filesystem with no scheme restriction, allowlist, or traversal check when processing any CSS string. An attacker who controls the CSS input, such as a user-uploaded stylesheet, CMS theme, userstyle, or blog-comment renderer content, can make the host Node process read any file readable by it and leak roughly the first 10 bytes of the content through a JSON.parse SyntaxError message, while also gaining a precise file-existence oracle and a controllable-read primitive that can be combined with large-file targets for denial of service. The behavior triggers with PostCSS's default options (no 'from', no 'map', no plugins required), so any pipeline that runs untrusted CSS through PostCSS at runtime is affected. All consumers of PostCSS 8.5.11 and prior are affected; build pipelines handling only trusted, first-party CSS are far less exposed. Exploitation has not been confirmed in the wild (EPSS ~0.6%, not in CISA KEV), but a public advisory with a PoC reference exists.

Do: Upgrade to PostCSS 8.5.12 or later, and audit your dependency tree (npm ls postcss / lockfiles) since PostCSS is commonly pulled in transitively by build tooling. Where PostCSS runs on untrusted CSS at runtime (CMS themes, uploaded styles, userstyle processors), strip or sanitize sourceMappingURL comments as an interim mitigation until patched. No in-the-wild exploitation is known; patching build-time-only use of trusted CSS is lower priority.