Summary
@clerk/shared@4.13.0 (latest as of 2026-05-21) still pins js-cookie@3.0.5, which is affected by GHSA-qjx8-664m-686j — a HIGH-severity prototype-hijack in Cookies.assign() enabling cookie-attribute injection. Patched in js-cookie >= 3.0.7.
This advisory is now blocking pnpm audit --audit-level=high for every downstream consumer of @clerk/backend / @clerk/shared who runs that audit in pre-push or CI gates.
Affected versions
@clerk/shared@^4.13.0 (and earlier major-4 series)
@clerk/shared@^3.x (also pins js-cookie 3.0.5 transitively)
- Therefore
@clerk/backend@2.33.x and @clerk/backend@3.x are both affected
- Equivalent Astro / Next.js / React-SDK packages that depend on
@clerk/shared
Reproduction
$ npm view @clerk/shared@4.13.0 dependencies.js-cookie
3.0.5
$ npm view js-cookie@3.0.5 --json | jq '.deprecated // "not deprecated"'
"not deprecated"
$ pnpm audit --audit-level=high # in any project that depends on @clerk/backend
# → 1 high: js-cookie GHSA-qjx8-664m-686j via .>@clerk/backend>@clerk/shared>js-cookie
Why the consumer-side workaround is undesirable
We tried pnpm.overrides to force js-cookie@>=3.0.7 in our own package.json. The override resolved the js-cookie advisory but triggered a 1176-line lockfile re-resolution that surfaced 8 additional HIGH-severity advisories from newer transitive resolutions (wrangler, minimatch, undici, lodash, underscore). Net: more vulnerabilities introduced than fixed. So we reverted the override.
The clean fix is upstream — @clerk/shared bumps its js-cookie pin from 3.0.5 to ^3.0.7. The semver diff (3.0.5 → 3.0.7) is patch-only and reverse-compatible.
Request
Please bump js-cookie to ^3.0.7 in @clerk/shared's package.json and ship a patch release for the 3.x and 4.x lines so downstream consumers can clear the audit without architectural workarounds.
Happy to open a PR if helpful — the change is mechanical.
Summary
@clerk/shared@4.13.0(latest as of 2026-05-21) still pinsjs-cookie@3.0.5, which is affected by GHSA-qjx8-664m-686j — a HIGH-severity prototype-hijack inCookies.assign()enabling cookie-attribute injection. Patched injs-cookie >= 3.0.7.This advisory is now blocking
pnpm audit --audit-level=highfor every downstream consumer of@clerk/backend/@clerk/sharedwho runs that audit in pre-push or CI gates.Affected versions
@clerk/shared@^4.13.0(and earlier major-4 series)@clerk/shared@^3.x(also pins js-cookie 3.0.5 transitively)@clerk/backend@2.33.xand@clerk/backend@3.xare both affected@clerk/sharedReproduction
Why the consumer-side workaround is undesirable
We tried
pnpm.overridesto forcejs-cookie@>=3.0.7in our ownpackage.json. The override resolved the js-cookie advisory but triggered a 1176-line lockfile re-resolution that surfaced 8 additional HIGH-severity advisories from newer transitive resolutions (wrangler,minimatch,undici,lodash,underscore). Net: more vulnerabilities introduced than fixed. So we reverted the override.The clean fix is upstream —
@clerk/sharedbumps itsjs-cookiepin from3.0.5to^3.0.7. The semver diff (3.0.5 → 3.0.7) is patch-only and reverse-compatible.Request
Please bump
js-cookieto^3.0.7in@clerk/shared'spackage.jsonand ship a patch release for the 3.x and 4.x lines so downstream consumers can clear the audit without architectural workarounds.Happy to open a PR if helpful — the change is mechanical.