Bump `deepmerge-ts` to >= 8.0.0 in `@prisma/config` (CVE-2026-40345)

[samjoffe]

Bump deepmerge-ts to >= 8.0.0 in @prisma/config (CVE-2026-40345)

What problem are you trying to solve?

@prisma/config@7.9.1 pins deepmerge-ts to an exact version:

"dependencies": {
  "c12": "3.3.4",
  "deepmerge-ts": "7.1.5",
  "effect": "3.20.0",
  "empathic": "2.0.0"
}

deepmerge-ts < 8.0.0 is affected by CVE-2026-40345 / GHSA-ggr8-5vv4-36mx (High, CVSS 8.2,
CWE-674 uncontrolled recursion): stack exhaustion when merging self-referential object graphs.
Patched in 8.0.0.

To be upfront about severity in Prisma's context: I don't believe this is practically exploitable
through @prisma/config. The only deepmerge-ts call site is the merger passed to c12 in
loadConfigTsOrJs, so the merged input is the developer's own prisma.config.ts — and c12
executes that file through jiti anyway. Anyone who can plant a recursive object graph there
already has code execution on the machine. This is a dependency-hygiene request, not an exploit
report.

The concrete pain is scanner noise. Because the dependency is an exact pin rather than a range,
@prisma/config transitively holds every consumer at the affected version and package managers
will not dedupe up to a patched release. Any project with Prisma in the tree now gets a High
finding from npm audit / Dependabot / Snyk / AWS Inspector, and the only consumer-side fix is a
manual override:

// npm / pnpm
"overrides": { "deepmerge-ts": "^8.0.1" }
// yarn
"resolutions": { "deepmerge-ts": "^8.0.1" }

That works, but it is a workaround every downstream team has to discover and carry
independently, and forcing a transitive dependency across a major version is not something most
teams want to do blind.

Proposed solution

Bump deepmerge-ts to ^8.0.1 in @prisma/config.

Worth flagging that 8.0.0 is a major release with breaking changes that touch this use case, so it
is not a no-op bump:

• Map values now merge recursively by default
• deepmergeInto no longer leak-mutates its inputs
• DeepMergeMetaMetaData → DeepMergeMergeInfo, DeepMergeIntoFunctionUtils → DeepMergeIntoUtils

@prisma/config only uses the plain deepmerge export as a c12 merger, so the renamed types
should not matter. The recursive-Map change is the one worth a look, though config objects rarely
carry Maps. 8.0.0 also adds cycle detection and a maxDepth option, which is the actual fix.

Alternatives considered

• Consumer-side overrides / resolutions — works, but does not scale; every downstream repo
  re-solves the same problem.
• Relaxing the pin to ^7.1.5 — does not help, since the fix only exists in 8.x.

Scope and impact

Affects every consumer of @prisma/config, i.e. anyone installing Prisma. No API change for
Prisma users if the bump stays contained to the c12 merger call site.

Environment: found on @prisma/config@7.9.1 (current latest on npm as of 2026-08-17).
deepmerge-ts 8.0.0 and 8.0.1 were both released 2026-08-16 and the advisory published 2026-08-17,
so this is very fresh — apologies if it is already on your radar.

[rodrigo-miguel01]

Confirming from a downstream project, with two data points that might save some evaluation time.

deepmerge-ts@7.1.6 does not resolve this. It was published on 2026-08-11, five days before 8.0.0, so it reads like the low-risk patch-line fix — but the advisory range is <8.0.0, so 7.1.6 is still flagged. Moving the pin within 7.x would leave the scanner noise exactly where it is; the major is the only way out.

The override to 8.x works in practice. We've been running "overrides": { "deepmerge-ts": "^8.0.2" } against prisma@7.9.1 for a few days, and prisma validate, prisma generate and prisma migrate dev all behave normally. That's a small sample and only exercises a config without Maps in it, but it matches the reasoning above: the renamed types aren't part of the c12 merger path, and nothing in the plain deepmerge export changed shape.

8.0.2 is the current release, if the bump lands.