Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The fix for GHSA-6g55-p6wh-862q added a guard in lib/previous-map.js PreviousMap.loadFile() that restricts an attacker-controlled sourceMappingURL (from a CSS comment) to a .map extension and, for untrusted maps, rejects .. traversal and absolute paths. The traversal/absolute rejection is nested inside if (cssFile) { ... }. When PostCSS is invoked without the from option, cssFile is falsy and that branch is skipped, leaving only the .map extension check. PreviousMap is constructed by lib/input.js whenever pathAvailable && sourceMapAvailable (under Node with source-map available), independent of opts.from/opts.map (the constructor returns early only for opts.map === false). So postcss([]).process(css) on attacker CSS reaches loadFile with cssFile undefined, and an attacker / sourceMappingURL=/abs/path/x.map / (or ../-traversing path) is read via readFileSync. When the file is valid JSON, its sources (filesystem paths) and sourcesContent (source contents) are disclosed in the…
Recommended action: Upgrade to 8.5.23 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Details File: lib/previous-map.js Line: 87-98 (loadFile), 129-144 (loadMap) Root Cause 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()).…
Recommended action: Upgrade to 8.5.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PostCSS's PreviousMap parses the / sourceMappingURL=PATH / comment from any CSS string passed to process() and dereferences PATH against the local filesystem with no scheme, allowlist, or traversal check. An attacker who controls the CSS input can cause the host process to read any file readable by Node and leak the first ~10 bytes of its content through the resulting JSON.parse SyntaxError message. The bug also yields a precise file-existence oracle and a controllable-read primitive that may be combined with large-file targets for DoS. The behaviour is triggered with PostCSS's default options — no from, no map, no plugins required — and is therefore reachable from any pipeline that runs untrusted CSS through PostCSS (CMS themes, user-uploaded styles, browser-extension/userstyle processors, build pipelines for third-party packages, blog comment renderers, etc.). Details The dangerous chain lives in lib/previous-map.js and is wired into every Input construction at…
Recommended action: Upgrade to 8.5.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PostCSS: XSS via Unescaped </style in CSS Stringify Output Summary PostCSS v8.5.5 (latest) does not escape </style sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML <style tags, </style in CSS values breaks out of the style context, enabling XSS. Proof of Concept Tested output (Node.js v22, postcss v8.5.5): Impact Impact non-bundler use cases since bundlers for XSS on their own. Requires some PostCSS plugin to have malware code, which can inject XSS to website. Suggested Fix Escape </style in all stringified output values: Credits Discovered and reported by Sunil Kumar (@TharVid)
Recommended action: Upgrade to 8.5.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 8.4.31 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 PoC
Recommended action: Upgrade to 8.2.13 or 7.0.36 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The npm package postcss from 7.0.0 and before versions 7.0.36 and 8.2.10 is vulnerable to Regular Expression Denial of Service (ReDoS) during source map parsing.
Recommended action: Upgrade to 8.2.10 or 7.0.36 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.