PostCSS sourceMappingURL arbitrary file read (CVE-2026-45623, CVSS 7.5) — reachable through Tailwind CSS's build pipeline

View raw markdownEdit on GitHub ↗

TL;DR

PostCSS — the CSS transform engine underneath Tailwind CSS, Vite, and most modern frontend build pipelines — parsed the /*# sourceMappingURL=PATH */ comment in any CSS it processed and read that path off the local filesystem with no traversal check, allowlist, or scheme validation, by default, no configuration needed. Anyone who can get untrusted CSS into a PostCSS process() call (user-uploaded themes, CMS templates, a build step over a third-party CSS file) can read arbitrary files the Node process can access and leak the first ~10 bytes of file content through a JSON.parse error message, plus get a precise file-existence oracle. CVE-2026-45623, GHSA-6g55-p6wh-862q, CVSS 7.5. Fixed in PostCSS 8.5.12 — Tailwind CSS projects pull PostCSS as a transitive dependency, so npm update postcss (or bumping Tailwind past whatever version pins the old PostCSS) is the fix.

What happened

PostCSS's PreviousMap class parses source-map comments embedded in CSS — the standard /*# sourceMappingURL=... */ annotation used to point a browser's devtools at the original, pre-build source file. In versions 8.5.11 and earlier, PreviousMap took whatever path followed sourceMappingURL= and dereferenced it directly against the local filesystem, with no check that the path stayed inside the project directory, no scheme restriction (so file:// and relative ../../ traversal both work), and no allowlist.

Because this runs by default with no opt-in flag, any code path that hands attacker-influenced CSS to PostCSS's process() is exploitable — this includes build tools that transform third-party or user-supplied stylesheets, CMS theme uploaders, "paste your CSS" playground tools, and any Tailwind CSS build that processes CSS from a source you don't fully control. The read isn't a clean file dump: PostCSS attempts to JSON.parse() the file contents as a source map, and the resulting SyntaxError message leaks roughly the first 10 bytes of the target file's content. Combined across many requests, an attacker can also use the technique as a precise file-existence oracle, and target large files to induce a denial-of-service by forcing repeated reads.

Fixed in PostCSS 8.5.12, published alongside the GHSA-6g55-p6wh-862q advisory on 2026-07-20. Tailwind CSS itself doesn't ship a first-party CVE here — it's exposed purely through its PostCSS dependency — but because Tailwind's build pipeline is PostCSS-based by design, any project on Tailwind ≤ the version pinning PostCSS ≤ 8.5.11 inherits the vulnerability.

Am I affected?

# Check your resolved PostCSS version
npm ls postcss 2>/dev/null | grep postcss

# Or check package-lock.json / pnpm-lock.yaml directly
grep -A2 '"postcss":' package-lock.json | grep '"version"'

You're affected if: - Your resolved postcss version is ≤ 8.5.11, and - Your build pipeline (Tailwind CSS, Vite, or a custom PostCSS setup) processes any CSS you don't fully control — third-party themes, CSS pasted/uploaded by users, CSS pulled from an external URL, or CSS from a dependency you haven't audited.

If you are affected

  1. Upgrade PostCSS to 8.5.12 or later: npm install postcss@latest (or update whatever version range your package.json / Tailwind version pins).
  2. If you can't upgrade immediately, don't run untrusted CSS through any postcss.process() call — strip sourceMappingURL comments from third-party/user-supplied CSS before processing, or process it in an isolated environment with no filesystem access to sensitive paths.
  3. Audit for exploitation: if you have logs of JSON.parse / source-map errors from your CSS build pipeline around requests containing unusual sourceMappingURL paths (especially ones referencing ../, /etc/, ~/.ssh, .env, or cloud-credential file locations), treat as a potential prior read attempt.

Prevention

→ prevention/package-vetting-checklist.md → prevention/supply-chain-attack-surface.md → Don't feed untrusted/user-supplied content into any build-tool parser (CSS, SVG, YAML, etc.) without first checking whether that parser reads external resources by default — source-map comments are a recurring "resource reference hidden in plain content" pattern.

Sources