fix(deps): resolve all 26 open Dependabot alerts via active pnpm overrides#545
fix(deps): resolve all 26 open Dependabot alerts via active pnpm overrides#545coderdan wants to merge 2 commits into
Conversation
…rides Root cause: the root package.json has a top-level npm-format `overrides` block that pnpm ignores, so earlier fixes (next >=15.5.15, lodash >=4.18.0, postcss >=8.5.10, vite catalog pin) never took effect, and the catalog:security pins for next/vite were referenced by nothing. - Add range-scoped security overrides to pnpm-workspace.yaml (the active location): next, lodash, js-cookie, postcss, vite 7.x, esbuild 0.27/28, js-yaml 3.x/4.x - Reference catalog:security next from packages/nextjs devDependencies so the 15.5.18 pin actually resolves (peer range unchanged) - Give wizard an explicit @anthropic-ai/sdk ^0.106.0 dependency — the vulnerable 0.81.0 was a stale auto-installed peer of claude-agent-sdk (which wants >=0.93.0); overrides don't rewrite peer resolutions - Bump root js-yaml to ^4.2.0; temporarily exclude js-yaml from the 7-day cooldown (3.15.0 security release is 6 days old — remove the exclusion after 2026-07-04) Verified: no vulnerable versions remain in the lockfile; full turbo build (10 packages), wizard tests (139), and script tests (20) pass.
📝 WalkthroughWalkthroughThis PR updates workspace security overrides and validation, revises supply-chain cooldown guidance, and bumps dependency versions in the root and package manifests. ChangesDependency and workspace override updates
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@package.json`:
- Line 61: The root npm-format overrides entry for js-yaml is stale and still
pins the vulnerable 4.1.1 version even though devDependencies.js-yaml was bumped
to ^4.2.0. Update the package.json overrides.js-yaml value to match the new safe
version, or remove the dead npm overrides block entirely if pnpm-workspace.yaml
is now the source of truth; check the js-yaml entries in package.json to keep
them consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 42b994b8-ad53-4cc5-b0f5-c1cd530b9e89
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (4)
package.jsonpackages/nextjs/package.jsonpackages/wizard/package.jsonpnpm-workspace.yaml
There was a problem hiding this comment.
Pull request overview
This PR aims to eliminate a set of open Dependabot security alerts by making pnpm overrides actually apply (moving them into pnpm-workspace.yaml), pinning security-sensitive toolchain deps via catalogs, and ensuring a published runtime package (@cipherstash/wizard) no longer pulls a vulnerable peer version.
Changes:
- Added pnpm workspace-level
overridestargeting vulnerable transitive dependency ranges (Next, lodash, js-cookie, postcss, vite, esbuild, js-yaml). - Activated the existing
catalog:securityNext.js pin by addingnext: catalog:securitytopackages/nextjsdevDependencies. - Updated
@cipherstash/wizardto depend directly on@anthropic-ai/sdk@^0.106.0and refreshed lockfile resolutions accordingly.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| pnpm-workspace.yaml | Adds effective pnpm overrides for vulnerable transitive deps and a temporary minimumReleaseAgeExclude entry. |
| pnpm-lock.yaml | Captures the resulting dependency graph changes (Next/esbuild/js-yaml/etc.) after applying overrides and catalog pins. |
| packages/nextjs/package.json | Adds next: catalog:security to ensure the workspace resolves the pinned Next version for dev/test. |
| packages/wizard/package.json | Adds an explicit @anthropic-ai/sdk runtime dependency to avoid a vulnerable peer resolution path. |
| package.json | Bumps root js-yaml devDependency range to ^4.2.0. |
Files not reviewed (1)
- pnpm-lock.yaml: Generated file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| "dependencies": { | ||
| "@anthropic-ai/claude-agent-sdk": "^0.3.143", | ||
| "@anthropic-ai/sdk": "^0.106.0", | ||
| "@cipherstash/auth": "catalog:repo", |
- Restore fast-uri 3.1.3: the lockfile regen let the 7-day cooldown demote ajv's fast-uri to 3.1.2, un-fixing GHSA-4c8g-83qw-93j6 / CVE-2026-13676; pin the patched release until it matures - Replace the js-yaml minimumReleaseAgeExclude entry (name-scoped, first-party-only list) with exact pins (3.15.0 / matured 4.2.0, evicting immature 4.3.0) installed via a one-off --config.minimumReleaseAge=0 run per SKILL.md; locked versions are not re-age-checked so normal installs need no bypass - Delete the inert npm-format overrides block and stale workspaces.catalogs duplicate from root package.json (dead config that contradicted the live pins; the overrides copy still pinned vulnerable js-yaml 4.1.1) - Annotate every override with its Dependabot alert + GHSA ID, note the esbuild-outside-tsup-range tradeoff, and document the wizard's @anthropic-ai/sdk dep as a peer-resolution pin (not unused) - Gate both escape hatches in the supply-chain e2e test: overrides must stay range-scoped and ≤12 entries; minimumReleaseAgeExclude must stay first-party-only - Fix SKILL.md's cooldown-bypass recipe: the documented --ignore-workspace-min-release-age flag does not exist in pnpm 10; the one-off equivalent is --config.minimumReleaseAge=0 with an exact pin Verified: full turbo build (10 pkgs), wizard tests (139), script tests (20), supply-chain e2e (14, incl. 2 new gates) all pass; frozen-lockfile install passes with no bypass.
|
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@pnpm-workspace.yaml`:
- Around line 59-64: The js-yaml pin comment is stale because it still
references the removed `--ignore-workspace-min-release-age` workaround, which no
longer matches the updated `SKILL.md` recipe. Update the explanatory comment
near the `js-yaml@<3.15.0` entry in `pnpm-workspace.yaml` so it points to the
current `pnpm install --config.minimumReleaseAge=0` flow and remove the old flag
reference while keeping the note about the bypass/maturity window.
In `@skills/stash-supply-chain-security/SKILL.md`:
- Around line 141-147: The one-off pnpm install override is using the wrong
config flag format, so pnpm 10.33.2 will ignore it. Update the install example
in SKILL.md to use the kebab-case CLI override with pnpm install and the
minimum-release-age setting, and make sure the guidance around the one-off run
matches the accepted pnpm config override form.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ce94914e-4930-4ed5-a911-b51d53e0926f
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (4)
e2e/tests/supply-chain.e2e.test.tspackage.jsonpnpm-workspace.yamlskills/stash-supply-chain-security/SKILL.md
💤 Files with no reviewable changes (1)
- package.json
| # #153 GHSA-h67p-54hq-rp68 / CVE-2026-53550 — js-yaml merge-key DoS, 3.x line. | ||
| # Exact pin: 3.15.0 is the only patched 3.x release. Installed with the | ||
| # one-off --ignore-workspace-min-release-age bypass (published 2026-06-26, | ||
| # matures 2026-07-04) per SKILL.md, instead of a minimumReleaseAgeExclude | ||
| # entry. | ||
| 'js-yaml@<3.15.0': '3.15.0' |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Stale flag reference: comment still cites the removed --ignore-workspace-min-release-age flag.
This comment says the js-yaml pin was installed with --ignore-workspace-min-release-age "per SKILL.md," but the updated SKILL.md recipe (lines 138-154 of that file) now documents pnpm install --config.minimumReleaseAge=0 instead — the old flag name was removed from the doc in this same PR. A future reader following "per SKILL.md" will find a different command than the one referenced here.
📝 Proposed fix to align the comment with the updated SKILL.md recipe
# `#153` GHSA-h67p-54hq-rp68 / CVE-2026-53550 — js-yaml merge-key DoS, 3.x line.
# Exact pin: 3.15.0 is the only patched 3.x release. Installed with the
- # one-off --ignore-workspace-min-release-age bypass (published 2026-06-26,
+ # one-off `--config.minimumReleaseAge=0` bypass (published 2026-06-26,
# matures 2026-07-04) per SKILL.md, instead of a minimumReleaseAgeExclude
# entry.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # #153 GHSA-h67p-54hq-rp68 / CVE-2026-53550 — js-yaml merge-key DoS, 3.x line. | |
| # Exact pin: 3.15.0 is the only patched 3.x release. Installed with the | |
| # one-off --ignore-workspace-min-release-age bypass (published 2026-06-26, | |
| # matures 2026-07-04) per SKILL.md, instead of a minimumReleaseAgeExclude | |
| # entry. | |
| 'js-yaml@<3.15.0': '3.15.0' | |
| # `#153` GHSA-h67p-54hq-rp68 / CVE-2026-53550 — js-yaml merge-key DoS, 3.x line. | |
| # Exact pin: 3.15.0 is the only patched 3.x release. Installed with the | |
| # one-off `--config.minimumReleaseAge=0` bypass (published 2026-06-26, | |
| # matures 2026-07-04) per SKILL.md, instead of a minimumReleaseAgeExclude | |
| # entry. | |
| 'js-yaml@<3.15.0': '3.15.0' |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pnpm-workspace.yaml` around lines 59 - 64, The js-yaml pin comment is stale
because it still references the removed `--ignore-workspace-min-release-age`
workaround, which no longer matches the updated `SKILL.md` recipe. Update the
explanatory comment near the `js-yaml@<3.15.0` entry in `pnpm-workspace.yaml` so
it points to the current `pnpm install --config.minimumReleaseAge=0` flow and
remove the old flag reference while keeping the note about the bypass/maturity
window.
| 2. Run a one-off install with the cooldown disabled for that single run | ||
| (pnpm ≥ 10 has no dedicated flag; the CLI config override is the one-off | ||
| equivalent and does not persist): | ||
|
|
||
| ```bash | ||
| # pnpm flag for a one-off install: | ||
| pnpm install <pkg>@<version> --ignore-workspace-min-release-age | ||
| pnpm install --config.minimumReleaseAge=0 | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🌐 Web query:
Does pnpm's --config.minimumReleaseAge CLI flag actually override the minimumReleaseAge setting for a single install, or is it config-file-only in pnpm 10.x?
💡 Result:
In pnpm 10.x, the --config.minimum-release-age CLI flag does override the minimumReleaseAge setting for a single install [1][2]. Pnpm treats the minimumReleaseAge as a configurable setting that can be defined in multiple ways, including in the pnpm-workspace.yaml file, via environment variables, or through CLI flags [2][3]. When you set this value explicitly via the CLI, such as using --config.minimum-release-age=, pnpm respects that value for the duration of that command [1][2]. Furthermore, as of recent updates in the pnpm 10.x lifecycle, explicitly setting minimumReleaseAge via the CLI or other configuration methods also causes the minimumReleaseAgeStrict setting to default to true [2][3]. This ensures that the constraint is actively enforced (i.e., the installation will fail if no version meets the age requirement), rather than silently falling back to an immature version [2][3]. For users who have not explicitly configured the setting, the built-in default of 1440 minutes remains non-strict for backward compatibility [2][3].
Citations:
- 1: Add a way to enforce a minimum package age policy pnpm/pnpm#9921
- 2: fix(config): default minimumReleaseAgeStrict to true when user sets minimumReleaseAge pnpm/pnpm#11436
- 3: https://pnpm.io/next/settings
🌐 Web query:
pnpm 10.33.2 minimumReleaseAge CLI override --config.minimumReleaseAge=0 single install
💡 Result:
To disable the minimum release age constraint for a single pnpm install command, you can use the following CLI override: pnpm install --config.minimum-release-age=0 Note the following details regarding this configuration: 1. CLI Syntax: When passing this configuration via the CLI, the setting must use the kebab-case format (--config.minimum-release-age=0) rather than camelCase (--config.minimumReleaseAge=0) to be correctly parsed [1]. 2. Availability: This method of overriding the configuration via the CLI is supported in newer versions of pnpm, including pnpm 11+ and late 10.x versions that introduced the minimumReleaseAge feature [2][3][1]. 3. Configuration Precedence: While you can override the setting per-command, the recommended approach for persistent settings is to define minimumReleaseAge within your pnpm-workspace.yaml file [4]. 4. Strict Enforcement: In recent versions, if you explicitly configure a minimumReleaseAge (whether via config file or CLI), pnpm defaults to strict mode (minimumReleaseAgeStrict: true). This ensures the constraint is enforced rather than silently falling back to insecure or older package versions [2]. If you are using pnpm 10.33.2 specifically, the --config.minimum-release-age=0 syntax is the correct way to bypass the age gate for a single invocation [2][1].
Citations:
- 1: chore: add pnpm package age gate for supply chain mitigation contedra/toolkit#40
- 2: fix(config): default minimumReleaseAgeStrict to true when user sets minimumReleaseAge pnpm/pnpm#11436
- 3: https://pnpm.io/blog/releases/11.0
- 4: Add a way to enforce a minimum package age policy pnpm/pnpm#9921
🌐 Web query:
pnpm 10.33.2 minimumReleaseAgeStrict CLI flag config file override issue 9921 11436
💡 Result:
In pnpm, an issue was identified where the minimumReleaseAge setting could appear ineffective because it would silently fall back to installing an immature version if no mature version satisfied the requested range [1][2][3]. This was addressed in pull request #11436 [1]. As of the fix, minimumReleaseAgeStrict now defaults to true whenever a user explicitly sets minimumReleaseAge via any configuration method (e.g., pnpm-workspace.yaml, CLI flags, global config.yaml, or environment variables) [1][4][3]. This ensures that the age constraint is strictly enforced [1]. Key details regarding this behavior include: - Backward Compatibility: The built-in default value for minimumReleaseAge (1440 minutes) remains non-strict to preserve existing behavior for users who have not explicitly configured the setting [1][4][3]. - Overriding: Users who wish to revert to the previous "silent fallback" behavior can do so by explicitly setting minimumReleaseAgeStrict: false in their configuration [1][4][3]. - Tracking: The changes were associated with issue #11433, which reported that the setting was not being respected in monorepos [2], and the foundational feature was introduced via issue #9921 [5][6]. This fix was implemented in pnpm v11.0.4 [2].
Citations:
- 1: fix(config): default minimumReleaseAgeStrict to true when user sets minimumReleaseAge pnpm/pnpm#11436
- 2: v11 does not respect minimumReleaseAge setting in monorepo pnpm/pnpm#11433
- 3: pnpm/pnpm@42a8f29
- 4: pnpm/pnpm@e3ccf6b
- 5: Add a way to enforce a minimum package age policy pnpm/pnpm#9921
- 6: pnpm/pnpm@38e2599
Use the kebab-case CLI override
pnpm install --config.minimum-release-age=0 is the form pnpm 10.33.2 understands for a one-off override; --config.minimumReleaseAge=0 won’t be applied.
🧰 Tools
🪛 SkillSpector (2.3.7)
[error] 3: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
(Privilege Escalation (PE3))
[error] 13: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
(Privilege Escalation (PE3))
[error] 63: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
(Privilege Escalation (PE3))
[error] 63: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
(Privilege Escalation (PE3))
[error] 65: [PE3] Credential Access: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Remediation: Remove references to credential paths. Use environment variables or secrets managers. For docs, use placeholder paths (e.g., /path/to/config). Never load .env or token files in production code paths.
(Privilege Escalation (PE3))
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@skills/stash-supply-chain-security/SKILL.md` around lines 141 - 147, The
one-off pnpm install override is using the wrong config flag format, so pnpm
10.33.2 will ignore it. Update the install example in SKILL.md to use the
kebab-case CLI override with pnpm install and the minimum-release-age setting,
and make sure the guidance around the one-off run matches the accepted pnpm
config override form.
Why Dependabot couldn't fix these itself
Nearly all 26 open alerts are transitive deps Dependabot can't PR against, and the repo's previous mitigation attempts were silently inert:
package.jsonhad a top-leveloverridesblock in npm format, which pnpm ignores — it containednext: >=15.5.15,lodash: >=4.18.0,postcss: >=8.5.10,vite: catalog:security… none of it ever applied (and itsjs-yaml: 4.1.1pinned the vulnerable version). Deleted in this PR, along with the staleworkspaces.catalogsduplicate that still advertised vulnerable pins (next 15.5.10,vite 6.4.1).catalog:securitypins fornext: 15.5.18/vite: 8.0.13inpnpm-workspace.yamlwere referenced by no package.@anthropic-ai/sdk@0.81.0was a stale auto-installed peer ofclaude-agent-sdk(peer floor>=0.93.0) — verified empirically that pnpm overrides rewrite peer ranges, not peer resolutions, so an explicit dep is the only working fix.What this PR does
Range-scoped overrides in
pnpm-workspace.yaml(the location pnpm actually reads), each annotated in-file with its alert + advisory:next@<15.5.18 → ~15.5.18lodash@<4.18.0 → ^4.18.0js-cookie@<3.0.7 → ^3.0.7postcss@<8.5.10 → ^8.5.10vite@>=7.0.0 <7.3.5 → ~7.3.5esbuild@>=0.27.3 <0.28.1 → ^0.28.1^0.27.0; builds pass, retire by bumping tsup once it declares^0.28js-yaml@<3.15.0 → 3.15.0(exact)js-yaml@>=4.0.0 <5 → 4.2.0(exact, matured)fast-uri@<3.1.3 → 3.1.3(exact)^3.1.3)Manifest changes:
packages/nextjs:next: catalog:securitydevDep — makes the existing 15.5.18 pin real; peer range^14 || ^15unchanged. (Kept alongside the override deliberately: tested override-only and it floats to 15.5.19 instead of the catalog-pinned version.)packages/wizard: explicit@anthropic-ai/sdk: ^0.106.0(alert fix(protect): proper handling of composite types #128, GHSA-p7fg-763f-g4gf / CVE-2026-41686) — the only alert reaching published-package runtime (npx stash init). This is a peer-resolution pin, never imported — documented in the workspace file so it isn't tidied away as unused.js-yaml→^4.2.0.Cooldown bypass (per SKILL.md): js-yaml 3.15.0 (published 2026-06-26) and fast-uri 3.1.3 (2026-06-29) are inside the 7-day window. Both are exact-pinned and were admitted via a single one-off
pnpm install --config.minimumReleaseAge=0run — no persistentminimumReleaseAgeExcludeentry (an earlier revision used one; removed after review). Locked versions aren't re-age-checked, so normal and--frozen-lockfileinstalls need no bypass. Also fixed SKILL.md's bypass recipe — the--ignore-workspace-min-release-ageflag it documented doesn't exist in pnpm 10.New CI gates in
e2e/tests/supply-chain.e2e.test.ts: overrides must stay range-scoped (no blanket pins) and ≤12 entries;minimumReleaseAgeExcludemust stay first-party-only.Verification
--frozen-lockfileinstall ✅.changeset status(exercises@manypkg/get-packages→ js-yaml 3.15.0) and a fullchangeset versionrun with a throwaway changeset (exercises@changesets/parse→ js-yaml 4.2.0) both work — changelogs and version bumps generated correctly, then reverted.Follow-ups
fast-uripin to^3.1.3after 2026-07-06 (noted in the workspace comment).^0.28and retire the esbuild override note.Summary by CodeRabbit
Security
Tests
Documentation