Moderate Vulnerability: PostCSS XSS Exposure via Vulnerable Dependency in Next.js

[MasterProvider]

Summary

Is this issue only happening on my end, or does it affect other users as well?

"dependencies": {
    "@next/third-parties": "^16.2.6",
    "next": "^16.2.6",
    "react": "^19.2.6",
    "react-dom": "^19.2.6",
  },
  "devDependencies": {
    "eslint": "^9",
    "eslint-config-next": "^16.2.6"
  }

# npm audit report

postcss  <8.5.10
Severity: moderate
PostCSS has XSS via Unescaped </style> in its CSS Stringify Output - https://github.com/advisories/GHSA-qx2v-qp2m-jg93
fix available via `npm audit fix --force`
Will install next@9.3.3, which is a breaking change
node_modules/postcss
  next  9.3.4-canary.0 - 16.3.0-canary.5
  Depends on vulnerable versions of postcss
  node_modules/next

2 moderate severity vulnerabilities

Additional information

No response

Example

No response

[Parisan8626]

Just so you know there's a known issue that affects pretty much everyone using Next.js between versions 9.3.4-canary.0 and 16.3.0-canary.5. The real problem is in PostCSS (<8.5.10), which sneaks in as a transitive dependency.

Just upgrade to Next.js 14.2.5 or higher. The fix is already being included in the next canary releases.

Whatever you do, don't run npm audit fix --force — seriously, don't. It'll downgrade your Next.js to version 9.3.3 and most likely break your app.

No panic though. This one's considered moderate and only messes with CSS processing during build time.

[bazhanius]

this temporary rule in package.json should help:

"overrides": {
    "postcss": "^8.5.10"
  }

[wanhei1]

This is a known issue affecting Next.js users. Here's a comprehensive summary:

The Problem

The PostCSS vulnerability (CVE) is in a transitive dependency. Even if you don't use PostCSS directly, Next.js uses it internally for CSS processing.

Immediate Fix

Add this to your package.json:

{
  "overrides": {
    "postcss": "^8.5.10"
  }
}

Then run:

npm install
npm audit  # Verify the vulnerability is resolved

For Yarn users

{
  "resolutions": {
    "postcss": "^8.5.10"
  }
}

For pnpm users

{
  "pnpm": {
    "overrides": {
      "postcss": "^8.5.10"
    }
  }
}

Verify the fix

# Check if the vulnerability persists
npm audit --audit-level=moderate

# Verify postcss version
npm ls postcss

Long-term

The Next.js team is aware of this. Watch for the next patch release which should update the PostCSS dependency automatically.

Note: This is a dev-time vulnerability (PostCSS runs during build), so production runtime risk is lower. But it's still important to patch for CI/CD security.

[Ortenzio]

There have been a few patch releases to 16.2 since this issue was raised. Will it be addressed in that minor version, or only in 16.3?

[pratik1258m]

This affects other users as well when a dependency tree includes a vulnerable version of a transitive dependency (in this case, postcss via next). Running npm audit fix --force is not recommended here because it attempts to solve it by downgrading next to a very old version (9.3.x), which will break your Next.js 16 application.

To resolve this issue, you can force the package manager to resolve postcss to a safe version (version 8.5.10 or higher) using dependency overrides in your package.json.

Depending on the package manager you use, add the following to your package.json:

1. If using npm

Add the overrides field:

"overrides": {
  "postcss": "^8.5.10"
}

2. If using pnpm

Add the pnpm.overrides field:

"pnpm": {
  "overrides": {
    "postcss": "^8.5.10"
  }
}

3. If using Yarn

Add the resolutions field:

"resolutions": {
  "postcss": "^8.5.10"
}

---

Next Steps:

After adding the override to your package.json:

1. Delete your lockfile (package-lock.json, pnpm-lock.yaml, or yarn.lock).
2. Delete the node_modules directory: rm -rf node_modules.
3. Run the install command again (e.g., npm install, pnpm install, or yarn install).
4. Run npm audit (or equivalent) to verify that the vulnerability is gone.

[logusivam]

No, this is not just happening on your end — this affects everyone using Next.js between versions 9.3.4-canary.0 and 16.3.0-canary.5, so you're not alone. Here's the full picture and what to actually do about it.

---

What's actually happening

This is a real, confirmed vulnerability — not a false positive. The advisory GHSA-qx2v-qp2m-jg93 (CVE-2026-41305, CVSS 6.1, Moderate) was published on April 20, 2026 and affects postcss < 8.5.10. The vulnerability itself is:

PostCSS does not escape </style> sequences when stringifying CSS ASTs. When user-submitted CSS is parsed and re-stringified for embedding in HTML <style> tags, </style> in CSS values can break out of the style context, enabling XSS.

Next.js bundles postcss as a transitive dependency and has been pinning it at 8.4.31 — below the fixed version of 8.5.10 — which is why your npm audit flags it. Additionally, @next/third-parties (which you also have in your dependencies) independently pins next@16.3.0-canary.14 in its own devDependencies, which also bundles the vulnerable postcss — meaning you're hit by two separate vectors of the same issue.

---

What NOT to do

Do not run npm audit fix --force. The suggested "fix" of downgrading to next@9.3.3 is a catastrophic breaking change — it would roll back your Next.js by roughly 7 major versions and break your entire project. Ignore that suggestion entirely.

---

The correct fix — use npm overrides to force the patched postcss version

Since the vulnerability is in a nested transitive dependency (Next.js's bundled postcss, not your own direct postcss), the right approach is to force the resolved version using npm's overrides field in your package.json:

{
  "dependencies": {
    "@next/third-parties": "^16.2.6",
    "next": "^16.2.6",
    "react": "^19.2.6",
    "react-dom": "^19.2.6"
  },
  "devDependencies": {
    "eslint": "^9",
    "eslint-config-next": "^16.2.6"
  },
  "overrides": {
    "postcss": "^8.5.10"
  }
}

Then reinstall:

npm install

Verify the fix:

npm audit

The postcss advisory should no longer appear. Also verify your build still works:

npm run build

---

How to verify it resolved

Run:

npm ls postcss

Every postcss entry in the tree should now show 8.5.10 or higher. If any still show 8.4.x, the override didn't apply to that path — check for conflicting version pins.

---

Is this exploitable in a typical Next.js app?

The practical risk depends on your use case. The XSS requires:

1. Your app accepts user-submitted CSS as input, AND
2. That CSS is parsed by PostCSS and re-stringified into a <style> tag in your HTML output

In a typical Next.js app that only uses PostCSS at build time (for Tailwind, CSS Modules, etc.) with no user-supplied CSS at runtime, this vulnerability is not exploitable in production — PostCSS only runs during your build, not on live user input. However, the overrides fix is still the right thing to do: it resolves the audit warning cleanly, costs nothing, and eliminates the risk entirely for any edge case where PostCSS might be invoked at runtime.

---

Summary

What	Detail
Affected range	Next.js 9.3.4-canary.0 through 16.3.0-canary.5
Root cause	Next.js bundles postcss@8.4.31; fixed version is 8.5.10+
Advisory	GHSA-qx2v-qp2m-jg93 / CVE-2026-41305 (Moderate, 6.1)
@next/third-parties additional vector	Pins next@16.3.0-canary.14 in its own devDeps, same issue
Wrong fix	npm audit fix --force — downgrades Next.js to 9.3.3, never do this
Correct fix	Add "overrides": { "postcss": "^8.5.10" } to package.json

Hope this helps — if it answers your question, would you mind clicking "Mark as answer" so others searching for the same thing can find it quickly?

[MasterProvider]

I'd like to close this issue because it has been resolved on my end after upgrading to next@^16.2.10. Thanks for your help!

[imRahul05]

One improvement to the suggested workaround is to scope the override to Next.js instead of applying it globally.

Instead of:

{
  "overrides": {
    "postcss": "^8.5.10"
  }
}

consider:

{
  "overrides": {
    "next": {
      "postcss": "^8.5.10"
    }
  }
}

This has a couple of benefits:

• It limits the override to the transitive dependency used by Next.js, rather than affecting every postcss dependency in the project.
• It reduces the risk of unintentionally changing the dependency tree for other packages that may legitimately require a different PostCSS version.
• It makes the intent explicit: this is a temporary workaround for the dependency bundled by Next.js until an upstream release includes the patched version.