Skip to content
This repository was archived by the owner on Jul 29, 2026. It is now read-only.

fix(deps): upgrade next 16.2.0 → 16.2.11 to patch security vulnerabilities - #92

Draft
caimanoliveira wants to merge 10 commits into
mainfrom
claude/kind-keller-xft63d
Draft

fix(deps): upgrade next 16.2.0 → 16.2.11 to patch security vulnerabilities#92
caimanoliveira wants to merge 10 commits into
mainfrom
claude/kind-keller-xft63d

Conversation

@caimanoliveira

Copy link
Copy Markdown
Owner

Summary

  • Upgrades next from 16.2.0 to 16.2.11 (latest patch release) to resolve 14 high/moderate CVEs
  • Fixes ws package to patch uninitialized memory disclosure and memory exhaustion DoS
  • Build verified clean after upgrade — all 22 routes compile and pass TypeScript checks

CVEs patched by this upgrade

Severity Advisory Description
High GHSA-q4gf-8mx6-v5v3 DoS via Server Components
High GHSA-8h8q-6873-q5fj DoS via Server Components (variant)
High GHSA-26hh-7cqf-hhc6 Middleware/proxy bypass via segment-prefetch routes
High GHSA-3g8h-86w9-wvmq Cache poisoning via middleware redirects
High GHSA-ffhc-5mcf-pf4q XSS via CSP nonces in App Router
High GHSA-vfv6-92ff-j949 Cache poisoning in RSC cache-busting
High GHSA-gx5p-jg67-6x7h XSS in beforeInteractive scripts
High GHSA-mg66-mrh9-m8jx DoS via connection exhaustion in Cache Components
High GHSA-h64f-5h5j-jqjh DoS in Image Optimization API
High GHSA-c4j6-fc7j-m34r SSRF via WebSocket upgrades
High GHSA-492v-c6pp-mqqv Middleware/proxy bypass via dynamic route parameter injection
High GHSA-wfc6-r584-vfw7 Cache poisoning in RSC responses
High GHSA-267c-6grr-h53f Middleware/proxy bypass via segment-prefetch (incomplete fix follow-up)
High GHSA-36qx-fr4f-26g5 Middleware/proxy bypass in Pages Router i18n
High GHSA-58qx-3vcg-4xpx ws: Uninitialized memory disclosure
High GHSA-96hv-2xvq-fx4p ws: Memory exhaustion DoS from tiny fragments

Remaining known issues

postcss <8.5.10 and sharp <0.35.0 remain flagged as they are transitive bundled deps inside next itself. The only npm-proposed remediation is a destructive downgrade to next@9.3.3, which is not feasible.

Test plan

  • next build succeeds with 0 errors and 0 TypeScript warnings
  • All 22 routes (static + dynamic) render correctly in the build manifest

Generated by Claude Code

…erabilities

Resolves high-severity CVEs: DoS via Server Components, cache poisoning in RSC
responses, middleware/proxy bypasses (GHSA-267c, GHSA-492v, GHSA-26hh), XSS in
CSP nonces and beforeInteractive scripts, SSRF via WebSocket upgrades, and ws
memory disclosure. Fixes ws to safe version as well.

Remaining postcss/sharp advisories are bundled transitive deps inside Next.js
itself — independent remediation requires a breaking downgrade to v9 (infeasible).

Co-Authored-By: Claude <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 22, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
mentoria-crm Ready Ready Preview, Comment Jul 22, 2026 8:20am
splinter Ready Ready Preview, Comment Jul 22, 2026 8:20am
splinter-yhcm Ready Ready Preview, Comment Jul 22, 2026 8:20am

…pgrade next

Three changes to get mentoria-crm deploying on Vercel:

1. Remove `supabase` devDependency — its postinstall script downloads the CLI
   binary from GitHub releases (403s in restricted envs, blocking npm install).
   The CLI is a local dev tool; install globally or via npx when needed.

2. Guard Supabase createClient() with env-var fallbacks in src/lib/supabase.ts
   so Next.js build-time SSR doesn't throw "supabaseUrl is required" when
   NEXT_PUBLIC_SUPABASE_URL hasn't been embedded yet.

3. Upgrade next 16.2.0 → 16.2.11 in mentoria-crm (same CVE set as the main
   splinter app).

Co-Authored-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude <noreply@anthropic.com>
Turbopack auto-detects the workspace root by looking for lockfiles and was
selecting the parent splinter/ directory (which has its own package-lock.json)
instead of mentoria-crm/. Locally the parent node_modules happen to be
installed, so the build passes. On Vercel only the subdirectory node_modules
are present, causing every module import to fail silently.

Setting turbopack.root = __dirname forces Turbopack to use the correct
package root and eliminates the "multiple lockfiles detected" warning.

Co-Authored-By: Claude <noreply@anthropic.com>
…dirname

__dirname is a CJS global not available in ESM module context. When Next.js
loads next.config.ts through jiti in ESM mode on Vercel, __dirname is undefined
and turbopack.root silently falls back to auto-detection, which selects the
parent splinter/ directory (finding its package-lock.json first). Vercel only
installs mentoria-crm/node_modules, so module resolution from the parent root
fails at build time.

process.cwd() is always available in Node.js (CJS and ESM alike) and resolves
to mentoria-crm/ when next build runs from the Vercel rootDirectory.

Co-Authored-By: Claude <noreply@anthropic.com>
next@16.2.11 requires Node.js >=20.9.0. Without an engines field, Vercel
may run the build with Node.js 18 (the project's configured default), causing
the build to fail. This explicitly tells Vercel to select Node.js 20 or 22.

Co-Authored-By: Claude <noreply@anthropic.com>
Overrides any stale Vercel project-level settings that may be causing
the persistent build failure. Explicitly sets next build + npm install
so Vercel uses the correct commands from the mentoria-crm rootDirectory.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Rps3biMKthxMansv3vyyd
…work key

outputDirectory: ".next" was bypassing Vercel's Next.js adapter that converts
the .next/ build output into the .vercel/output/ serverless deployment format.
Adding framework: "nextjs" ensures the adapter is explicitly selected.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Rps3biMKthxMansv3vyyd
Bare `next build` may not have node_modules/.bin in PATH on Vercel.
`npm run build` is the canonical form and ensures npm's PATH injection
is active, so the Next.js binary in mentoria-crm/node_modules/.bin is
found regardless of how Vercel invokes the command.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Rps3biMKthxMansv3vyyd
Turbopack's workspace-root detection walks up from mentoria-crm/ and
finds the parent splinter/package-lock.json, selecting splinter/ as the
project root. On Vercel (rootDirectory: mentoria-crm) only
mentoria-crm/node_modules is installed, so Turbopack cannot resolve
any module from the parent root → build fails.

Switching to webpack avoids Turbopack's root detection entirely.
turbopack.root in next.config.ts is kept in case Turbopack is re-enabled
later, but is not used by webpack.

Also: reflects engines field in package-lock.json after npm install.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Rps3biMKthxMansv3vyyd
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants