Came across something in demos/features/chart-group/package-lock.json around line 2637 that looked worth flagging.
This HIGH severity vulnerability stems from insecure path resolution in PostCSS's previousMap handler in versions ≤8.5.11. When parsing CSS containing sourceMappingURL comments, PostCSS dereferences the specified path against the local filesystem without validating URL schemes, blocking directory traversal, or enforcing allowlists. An attacker controlling CSS input can exploit this to read arbitrary files accessible to the Node process (leaking ~10 bytes via JSON.parse error traces), perform precise file-existence probes, or trigger resource exhaustion DoS via large-file reads. The flaw activates with default options and directly compromises any pipeline processing untrusted styles.
Something like this might fix it:
--- a/demos/features/chart-group/package.json
+++ b/demos/features/chart-group/package.json
@@ -... @@
- "postcss": "8.4.32",
+ "postcss": ">=8.5.12"
After updating package.json, execute `cd demos/features/chart-group && npm install` to regenerate the lockfile and apply the patched dependency tree.
For reference: rule CVE-2026-45623. Rated high.
If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Came across something in
demos/features/chart-group/package-lock.jsonaround line 2637 that looked worth flagging.This HIGH severity vulnerability stems from insecure path resolution in PostCSS's previousMap handler in versions ≤8.5.11. When parsing CSS containing sourceMappingURL comments, PostCSS dereferences the specified path against the local filesystem without validating URL schemes, blocking directory traversal, or enforcing allowlists. An attacker controlling CSS input can exploit this to read arbitrary files accessible to the Node process (leaking ~10 bytes via JSON.parse error traces), perform precise file-existence probes, or trigger resource exhaustion DoS via large-file reads. The flaw activates with default options and directly compromises any pipeline processing untrusted styles.
Something like this might fix it:
For reference: rule
CVE-2026-45623. Rated high.If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.