PostCSS Vulnerability: CVE-2023-44270 Explained

At a glance

The current release, PostCSS 8.5.32, includes the fix.

What the bug was

The issue was in how the PostCSS tokenizer handled the carriage-return character (\r) inside comments. With specially crafted input, text that the author placed inside a CSS comment could end up in the PostCSS output as real CSS nodes, such as rules or properties.

In other words, a comment that looked harmless to a human or a linter could smuggle actual CSS through processing. The official fix changed carriage-return parsing in the tokenizer.

Who was really affected?

The advisory states that the problem affects linters using PostCSS to parse external, untrusted CSS. The realistic risk applies when:

• your tool processes CSS supplied by other people, for example a service that accepts user stylesheets, and
• you rely on PostCSS output to decide whether that CSS is safe.

If you only run PostCSS on stylesheets your own team writes, the practical risk is low. That said, upgrading is easy and removes the audit warning, so there is little reason not to.

How to check your project

First, list every copy of PostCSS in your dependency tree:

npm ls postcss

Any version below 8.4.31 is affected. Then run the audit:

npm audit

pnpm and Yarn users can run pnpm why postcss / pnpm audit or yarn why postcss / yarn npm audit.

How to fix it

1. Update your direct dependency

npm install --save-dev postcss@latest

2. Update the packages that pull in old copies

The vulnerable copy is often nested inside another tool, such as an old build tool, loader or framework. Update that parent package. npm ls postcss shows which one it is.

3. Use overrides as a last resort

If a parent package cannot be updated, npm (v8.3+) lets you force a version:

"overrides": {
  "postcss": "^8.4.31"
}

Then delete node_modules and reinstall. Test your build afterwards, because forcing a major version on a package that expected PostCSS 7 can break it.

When the warning is a false alarm

Audit tools report vulnerable versions, not real exploitability. If the old PostCSS copy belongs to a dev-only tool that only processes your own files, the risk is minimal. Still, document the decision if you choose not to update, and revisit it when the parent package releases an update.

Security practices for PostCSS projects

• Commit your lockfile so every install uses the same reviewed versions and integrity hashes.
• Download from official sources: npm, or the official GitHub repository, as on our download section.
• Review plugins before adding them. A plugin runs as code in your build, so prefer maintained, widely used packages.
• Do not treat PostCSS as a sanitizer. If you accept CSS from users, sanitise or sandbox it separately.
• Watch advisories via npm audit, GitHub Dependabot or similar tools.

Are there other PostCSS vulnerabilities?

CVE-2023-44270 is the advisory most audit reports show for the postcss package. Advisories can be published at any time, so check the GitHub Advisory Database and the official release notes for the latest information rather than relying on any single article, including this one.

Quick answers

Is PostCSS safe to use?

Yes, when kept up to date. Version 8.5.32 contains the fix for CVE-2023-44270.

Does this affect the CSS my visitors download?

No. PostCSS runs at build time. The issue concerns how PostCSS parses input, not how browsers read your final CSS.

Which version should I use?

The latest 8.x release. See what the latest PostCSS version is.