This might be a false positive, but pnpm-lock.yaml around line 1 looked worth a second pair of eyes.
VULNERABILITY CONFIRMED — CVE-2026-73646 (HIGH): pnpm-lock.yaml pins postcss 8.5.16, which is affected by a path traversal / information disclosure flaw in lib/previous-map.js. The vulnerable loadMap() function passes attacker-controlled sourceMappingURL annotation values directly to path resolution (join(dirname(opts.from), annotation)), and loadFile() accepts traversed (e.g., ../../) or absolute .map paths. If the application processes untrusted or attacker-influenced CSS (user uploads, third-party styles, CMS content) without map: false, an attacker can craft a malicious sourceMappingURL to make PostCSS load arbitrary reachable .map files and leak their sourcesContent through result.map — potentially exposing source code, internal file contents, or secrets embedded in source maps. Impact: confidentiality breach (no integrity/availability impact). Risk: HIGH when untrusted CSS is processed; LOW/defense-in-depth only if all input is fully trusted. Remediation: upgrade postcss to >= 8.5.18 and regenerate the lockfile; as an interim mitigation, pass { map: false } to PostCSS when handling untrusted CSS.
Something like this might fix it:
--- a/package.json
+++ b/package.json
@@
"dependencies": {
- "postcss": "8.5.16",
+ "postcss": "8.5.18",
}
--- a/pnpm-lock.yaml (regenerated by package manager, do not hand-edit)
+++ b/pnpm-lock.yaml
@@
- postcss: 8.5.16
+ postcss: 8.5.18
# Apply the upgrade and regenerate the lockfile:
# pnpm up postcss@8.5.18 (or edit package.json to "^8.5.18" then run `pnpm install`)
# pnpm audit # verify the finding is resolved
# Interim mitigation while upgrading (when processing untrusted CSS):
-const result = postcss(plugins).process(untrustedCss, { from: file });
+const result = postcss(plugins).process(untrustedCss, { from: file, map: false });For reference: rule CVE-2026-73646. Rated high.
The suggested change is untested against this project, so please read it before applying it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
This might be a false positive, but
pnpm-lock.yamlaround line 1 looked worth a second pair of eyes.VULNERABILITY CONFIRMED — CVE-2026-73646 (HIGH): pnpm-lock.yaml pins postcss 8.5.16, which is affected by a path traversal / information disclosure flaw in lib/previous-map.js. The vulnerable loadMap() function passes attacker-controlled sourceMappingURL annotation values directly to path resolution (join(dirname(opts.from), annotation)), and loadFile() accepts traversed (e.g., ../../) or absolute .map paths. If the application processes untrusted or attacker-influenced CSS (user uploads, third-party styles, CMS content) without map: false, an attacker can craft a malicious sourceMappingURL to make PostCSS load arbitrary reachable .map files and leak their sourcesContent through result.map — potentially exposing source code, internal file contents, or secrets embedded in source maps. Impact: confidentiality breach (no integrity/availability impact). Risk: HIGH when untrusted CSS is processed; LOW/defense-in-depth only if all input is fully trusted. Remediation: upgrade postcss to >= 8.5.18 and regenerate the lockfile; as an interim mitigation, pass { map: false } to PostCSS when handling untrusted CSS.
Something like this might fix it:
For reference: rule
CVE-2026-73646. Rated high.The suggested change is untested against this project, so please read it before applying it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.