CVE-2026-45623

What it actually does

PostCSS 8.5.11 and earlier parses source map comments in CSS input by default. When attacker-controlled CSS contains a comment such as /*# sourceMappingURL=PATH */, the PreviousMap logic dereferences PATH on the local filesystem without restricting schemes, absolute paths, or directory traversal. This can allow an unauthenticated attacker who can submit CSS for processing to make the Node.js process read arbitrary files that the process account can access. The direct disclosure is limited to roughly the first 10 bytes through the resulting JSON.parse SyntaxError message, but the behavior also creates a reliable file-existence oracle and may be abused for denial of service by targeting large files or special filesystem paths.

Why it matters to the business

Applications and services that process untrusted CSS with vulnerable PostCSS versions can unintentionally expose sensitive local file fragments, confirm the presence of files, or suffer resource exhaustion. The highest-risk use cases are CMS theme editors, user-uploaded stylesheets, blog or comment renderers, browser-extension or userstyle processing services, and build systems that process third-party CSS. Although this issue is not currently listed in CISA KEV and has low EPSS at 0.00608, it is remotely reachable in affected workflows, requires no authentication or user interaction, and was published 15 days ago, so internet-facing CSS processing paths should be upgraded promptly.

How an attack unfolds

An attacker first identifies an application feature that accepts CSS and passes it to PostCSS process() using default or vulnerable source map handling. The attacker submits CSS containing a sourceMappingURL comment that points to a local path, such as an absolute path or a traversal sequence. Vulnerable PostCSS attempts to open and parse the referenced local file as a source map. Because normal system or application files are not valid JSON source maps, JSON.parse throws a SyntaxError that includes a small prefix of the file content. The attacker observes error output, API responses, build logs, preview output, or other surfaced diagnostics to recover leaked bytes. By repeating requests with different paths, the attacker can determine whether files exist, infer platform and deployment details, and potentially target large or blocking file paths to degrade service availability.

How to fix it

Upgrade PostCSS to version 8.5.12 or later everywhere it is used, including direct dependencies, transitive dependencies, build tooling, CMS/theme processors, and server-side rendering or preview services. Regenerate lockfiles and redeploy applications after upgrading. If immediate upgrade is not possible, do not process untrusted CSS with vulnerable PostCSS versions; strip or reject sourceMappingURL comments before processing; run CSS processing in a sandbox with a dedicated low-privilege account; restrict filesystem access with containers, chroot/jails, seccomp/AppArmor/SELinux, or read-only mounts; suppress detailed parser errors from user-visible responses; and apply resource limits for CPU, memory, file size, and processing time.

How to confirm the fix worked

Confirm that all deployed package manifests and lockfiles resolve PostCSS to 8.5.12 or later. Use package-manager commands such as npm ls postcss, yarn why postcss, or pnpm why postcss across application and build repositories, including container images and CI worker images. Test exposed CSS ingestion paths with a harmless sourceMappingURL pointing to a known nonexistent file and verify that the service does not attempt local filesystem reads or disclose parser details. Review dependency scanner output and software composition analysis results for PostCSS versions 8.5.11 and earlier. Validate that user-facing responses and logs no longer include local-file JSON.parse failures triggered by CSS sourceMappingURL comments.

Typical attack path

1. Find a feature, API, upload workflow, build job, or rendering service that accepts CSS from untrusted users or third-party packages.
2. Submit CSS containing a crafted source map comment, for example a /*# sourceMappingURL=... */ directive pointing to a local file path.
3. Cause the vulnerable PostCSS version to resolve and read the referenced local path during processing.
4. Collect returned error details, preview output, logs, or build artifacts containing JSON.parse SyntaxError text.
5. Repeat against sensitive or diagnostic paths to leak file prefixes or confirm file existence.
6. Optionally target very large or special files to increase CPU, memory, or I/O consumption and cause denial of service.

How to detect it

Review logs from web applications, CSS preview/rendering services, CMS theme editors, upload pipelines, CI/CD build systems, server-side rendering workers, and dependency build logs. Look for submitted CSS containing sourceMappingURL comments that reference absolute paths, parent-directory traversal, file URLs, Windows drive paths, UNC paths, or sensitive locations such as /etc/passwd, /proc, /var, /home, C:\Windows, or application secret files. Search error telemetry for JSON.parse SyntaxError messages occurring during PostCSS processing, especially errors that include unexpected characters from non-JSON files. Investigate repeated requests with varied sourceMappingURL values, 4xx/5xx spikes from CSS-processing endpoints, build failures triggered by third-party CSS, and elevated memory or I/O during CSS parsing. If exploitation is suspected, preserve request bodies, response bodies, application logs, build artifacts, worker stdout/stderr, package versions, and container filesystem access logs where available.

• /*# sourceMappingURL=
• sourceMappingURL=/etc/passwd
• sourceMappingURL=../../
• sourceMappingURL=..%2f..%2f
• sourceMappingURL=file://
• sourceMappingURL=/proc/self/environ
• sourceMappingURL=/proc/self/cmdline
• sourceMappingURL=/var/log/
• sourceMappingURL=/home/
• sourceMappingURL=/root/
• sourceMappingURL=/app/.env
• sourceMappingURL=.env
• sourceMappingURL=package.json
• sourceMappingURL=C:\\Windows\\
• sourceMappingURL=C:/Windows/
• sourceMappingURL=\\\\
• SyntaxError: Unexpected token
• Unexpected token
• JSON.parse
• PreviousMap
• postcss

What your security team should do

• Prioritize inventory and upgrade of any internet-facing or multi-tenant service that accepts user-controlled CSS and uses PostCSS 8.5.11 or earlier.
• Update PostCSS to 8.5.12 or later in source repositories, lockfiles, container images, CI/CD workers, CMS plugins, and build toolchains.
• Search application logs, build logs, and API error logs for sourceMappingURL directives referencing absolute paths, traversal sequences, file URLs, or sensitive system paths.
• Ensure parser exceptions and build errors are not returned verbatim to untrusted users.
• Add input validation to remove or block sourceMappingURL comments from untrusted CSS unless source maps are explicitly required and safely resolved.
• Run CSS processing workloads with least-privilege filesystem access and resource limits to reduce data disclosure and denial-of-service impact.
• Create SIEM detections for suspicious CSS source map references and JSON.parse SyntaxError messages associated with local files.
• Monitor dependency management systems for transitive PostCSS reintroduction below version 8.5.12.