[Snyk] Security upgrade next from 16.2.10 to 16.2.11

[snyk-io]

Snyk has created this PR to fix 2 vulnerabilities in the pnpm dependencies of this project.

Snyk changed the following file(s):

• packages/next/package.json

⚠️ Warning

Failed to update the pnpm-lock.yaml, please update manually before merging.

Vulnerabilities that will be fixed with an upgrade:

	Issue
	Server-side Request Forgery (SSRF) SNYK-JS-NEXT-18233136
	Server-side Request Forgery (SSRF) SNYK-JS-NEXT-18233752

Breaking Change Risk

Notice: This assessment is enhanced by AI.

---

Important

• Check the changes in this PR to ensure they won't cause issues with your project.
• Max score is 1000. Note that the real score may have changed since the PR was raised.
• This PR was automatically created by Snyk using the credentials of a real user.

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

---

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Server-side Request Forgery (SSRF)

[snyk-io]

This is a patch version upgrade from next@16.2.10 to next@16.2.11. According to official announcements, this release is part of a security update to address multiple vulnerabilities.

As a patch release focused on security, it is not expected to contain breaking API changes. The changelog for the preceding version, v16.2.10, also indicates it contained no functional changes.

Recommendation: Given this is a security release, upgrading is recommended. No breaking changes are anticipated.

Notice 🤖: This content was augmented using artificial intelligence. AI-generated content may contain errors and should be reviewed for accuracy before use.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

🧪 E2E Test Results

No test result files found.

---

❌ Some E2E test jobs failed:

• Vercel Prod: failure
• Local Dev: skipped
• Local Prod: skipped
• Local Postgres: skipped
• Windows: failure

Check the workflow run for details.

[github-actions]

📊 Workflow Benchmarks

❌ The benchmark run for b0e3012 failed. See the run logs for details.

No benchmark results were produced.

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt)}

_{All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.}

_{Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.}