fix(deps): bump deepmerge-ts from 7.1.5 to 8.0.1 - #30054
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
Included review availability: Your plan includes up to 10 reviews per rolling hour; 9 remain after this review. 📝 WalkthroughWalkthrough
ChangesDependency security update
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This localized dependency update removes the reported vulnerability and has passed the stated tests, builds, type checks, audit, and frozen-lockfile installation; no actionable merge-blocking risk remains. Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 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 |
|
The PR Code Security run failed before any job started: that workflow hands |
Merging this PR will improve performance by 22.36%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ⚡ | getBinaryTargetForCurrentPlatform |
2.1 ms | 1.7 ms | +22.36% |
Tip
Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.
Comparing lazerg:fix/issue-30052-deepmerge-ts-8 (10689fd) with v7 (05ce490)
Footnotes
-
30 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩
* fix(deps): force deepmerge-ts to 8.x to patch CVE-2026-40345 @prisma/config pins deepmerge-ts at exactly 7.1.5, which is vulnerable to GHSA-ggr8-5vv4-36mx (stack exhaustion when merging recursive object graphs). It reaches the production tree through @prisma/client's optional dependency on the prisma CLI, so both supply-chain gates fail on every PR: `pnpm audit --prod` (1 high) and the Trivy scan of the api image (1 HIGH, fix available). Dependabot cannot resolve it -- it reports `security_update_not_possible` because the exact pin caps the resolvable version at 7.1.5 -- and no published @prisma/config carries the bump yet, so a workspace override is the only path. The upstream fix is still open: prisma/orm#30054 The override is unscoped rather than parent-scoped, per the primary rule in pnpm-workspace.yaml: @prisma/config is the only consumer in the tree, and an unscoped override already breaks the exact pin. * docs(deps): link upstream tracking issue in deepmerge-ts override The override comment only pointed at the community PR. Add the upstream issue that tracks the bump (prisma/orm#30052) so the reason the override exists is readable from the issue alone, without inferring it from a PR diff.
… reason Nothing audited the dependency tree in either repo. Both were at zero advisories on 2026-08-09 and nothing has watched since, which is how a high-severity one appeared on 2026-08-16 and sat unnoticed until it was tripped over by accident. The gate fails two ways. An advisory not recorded in audit-allowlist.json fails the build. So does a recorded entry that no longer matches any advisory — so when upstream ships a fix, CI breaks and says to delete the entry, instead of leaving a stale "we looked at this once" note in the repo. Both proven: emptying the allowlist fails with the advisory named, and a phantom entry fails as obsolete. One entry, deepmerge-ts GHSA-ggr8-5vv4-36mx (CVE-2026-40345), accepted with the analysis recorded in the allowlist. In short: the only path is prisma -> @prisma/config -> deepmerge-ts, and @prisma/config calls deepmerge in exactly one place, loadConfigTsOrJs(), merging prisma.config.ts layers through c12. This repo has no prisma.config.* file and that input is never request-influenced, while the CVSS 8.2 assumes an app feeding attacker-controlled JSON to the public API. No fix exists to take: every stable prisma from 6.19.3 to 7.9.1, and the 7.10.0 dev prereleases, pin "deepmerge-ts": "7.1.5" exactly. deepmerge-ts 8.0.0 shipped 2026-08-16. `npm audit fix --force` proposes prisma 6.12.0, a major downgrade. An override would force past an exact pin across a major, which is not something this project does. prisma/orm#30054 has the bump and is mergeable; the entry names it, and the stale check is what makes sure we act on it. Plain .mjs with no dependencies, byte-identical in both repos. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XYeFzET7gtfvEKMs47kshi
2 participants
What this fixes
pnpm audit --prodis whattest-template.ymlgates on, and onv7it currently reports one high advisory: GHSA-ggr8-5vv4-36mx / CVE-2026-40345, uncontrolled recursion indeepmerge-ts, reached throughpackages__config>deepmerge-ts. Patched in 8.0.0.Since
@prisma/configpins the exact version, every downstream install is held at 7.1.5 and package managers cannot dedupe up to a patched release, so consumers have to carry their ownoverrides/resolutionsto clear the finding.Changes
Bumps
deepmerge-tsfrom 7.1.5 to 8.0.1 inpackages/config, plus the lockfile.I bumped the manifest instead of adding a
pnpm-workspace.yamloverride, since everything in that block is a transitive dependency.deepmerge-tsis declared directly by@prisma/config, so an override would quiet the audit here while the published manifest still pointed downstream at 7.1.5.8.0.0 is a major release, so I checked its breaking changes against the only call site, the
deepmergepassed as the c12mergerinloadConfigTsOrJs:deepmergeIntois not used here, only the plaindeepmergeexport is.DeepMergeMetaMetaDataandDeepMergeIntoFunctionUtilsrenames touch types this package never references.The
@ts-expect-errorabovemergeris still required, so the c12 type mismatch it covers is unchanged.How I checked
pnpm audit --prod:No known vulnerabilities found, against 1 high before the bumppnpm --filter @prisma/config test: 142 passed, 2 skippedpnpm --filter "@prisma/config..." buildandtsc --noEmit -p packages/configboth cleanCI=true pnpm install --frozen-lockfilepassesRangeError: Maximum call stack size exceededon 7.1.5 and returns normally on 8.0.1Fixes #30052