fix(deps): force deepmerge-ts to 8.x to patch CVE-2026-40345

[mrivas00]

Why

Audit and Trivy Image Scan (api) are failing on every PR against main. Both report the same advisory — this is one problem, not two.

GHSA-ggr8-5vv4-36mx / CVE-2026-40345 — deepmerge-ts stack exhaustion when merging recursive object graphs. Vulnerable <8.0.0; the tree had 7.1.5.

It is a production-tree dependency through @prisma/client's optional dependency on the prisma CLI:

@repo/database > @prisma/client > prisma > @prisma/config > deepmerge-ts@7.1.5

• Audit — pnpm audit --prod --audit-level moderate → 1 high.
• Trivy Image Scan (api) — Total: 1 (HIGH: 1, CRITICAL: 0), fix available. The web image is clean.

This is unrelated to any feature branch; main is affected too. Its last green Trivy run was 2026-08-17 12:44, and the advisory landed at 14:08 the same day.

Why an override

Dependabot already tried and gave up with security_update_not_possible / latest-resolvable-version: 7.1.5: @prisma/config@7.9.1 pins deepmerge-ts at exactly 7.1.5 (no range), and prisma@latest is 7.9.1.

No published @prisma/config carries the bump — not 7.9.1, not the newest prerelease 7.10.0-dev.58 (published 2026-08-17, i.e. after deepmerge-ts 8.0.0 shipped on 2026-08-16). Upstream knows and has not moved: the tracking issue is open, unlabelled and with no maintainer reply (prisma/orm#30052), and the only fix for it is an open, community-authored PR against v7 with no maintainer review (prisma/orm#30054).

Prisma 8 drops @prisma/config entirely (prisma@8.0.0-rc.6 depends on @prisma/cli-engine + @prisma/orm-toolchain instead), so this resolves itself on that major — but that is an RC and not an option now.

So a workspace override is the only path, which is what pnpm-workspace.yaml already documents for exactly this case.

What changed

pnpm-workspace.yaml — one entry in overrides, plus the lockfile re-resolution.

"deepmerge-ts": ^8.0.1 # GHSA-ggr8-5vv4-36mx / CVE-2026-40345 (@prisma/client>prisma>@prisma/config)

Unscoped rather than @prisma/config>deepmerge-ts, per the primary rule in that file ("declare the override on the vulnerable package itself"): @prisma/config is the only consumer in the lockfile, and an unscoped override already breaks the exact pin — verified, not assumed. The comment carries both upstream links so the override can be dropped once a published @prisma/config ships deepmerge-ts >= 8.

Major-bump safety

deepmerge-ts 8 is a major, so this was checked rather than trusted:

• @prisma/config uses exactly one thing from it — const { deepmerge } = await import("deepmerge-ts"), passed as c12's merger. deepmerge is unchanged in v8.
• v8's breaking changes are type-level (generics reshuffled) plus renamed internals (mergeRecords → mergeRecordsFast). @prisma/config ships prebuilt JS and its .d.ts never references deepmerge-ts, so none of that surfaces.
• minimumReleaseAge: 1440 is satisfied — 8.0.1 was published 2026-08-16.

Verification

Check	Result
Lockfile re-resolution	deepmerge-ts@8.0.1
pnpm audit --prod --audit-level moderate	No known vulnerabilities found
prisma validate	config loaded from prisma.config.ts, schema valid
prisma generate	client generated
pnpm format / pnpm lint / pnpm type-check	pass

The two prisma invocations are the point of the functional check: they exercise the @prisma/config → deepmerge code path on the new major.

Trivy was not re-run locally (it needs a full image build), but its single finding named this exact package and version, so it clears with the lockfile. CI on this PR is the real confirmation.