dependabot/npm_and_yarn/apps/web/next-16.2.11

pnpm-lock.yaml not updated — CI fails on frozen-lockfile install

apps/web/package.json

package.json declares next@16.2.11 but pnpm-lock.yaml still pins next@16.0.10. All CI workflows use `pnpm install --frozen-lockfile`; pnpm aborts when the lockfile is out of sync with the manifest. Every CI job (build, lint, typecheck, e2e, preview provision) will fail. Dependabot typically updates both files atomically — the lockfile update appears to have been dropped. Fix: comment `@dependabot rebase` on the PR to trigger a regeneration.

eslint-config-next at 16.0.7 will lag behind next@16.2.11 after merge

apps/web/package.json

The lockfile shows eslint-config-next@16.0.7 while next will be 16.2.11. These packages are typically kept at the same minor version. Not a CI blocker (ESLint configs are loose about Next.js minor versions) but worth a follow-up Dependabot bump.

Security patches not actually installed — lockfile still pins vulnerable next@16.0.10

apps/web/package.json

Despite the package.json change, the deployed binary remains next@16.0.10 because the lockfile drives what pnpm installs. All 9 patched CVEs (4 HIGH, 5 MODERATE) remain exploitable in production until the lockfile is regenerated and deployed. This PR provides a false sense of security — the version string changed but the running code did not. Three CVEs are directly relevant: GHSA-m99w-x7hq-7vfj (DoS via Server Actions — project has 3 public-facing Server Actions), GHSA-q8wf-6r8g-63ch (DoS via SVG in Image Optimization — project uses next/image), GHSA-955p-x3mx-jcvp (disclosure of internal Server Function endpoints — amplifies the DoS attack surface). GHSA-p9j2-gv94-2wf4 (SSRF via rewrites) and GHSA-89xv-2m56-2m9x (SSRF via custom server) are NOT applicable — no rewrites defined, Vercel deployment not a custom server.

GHSA-6gpp-xcg3-4w24: Middleware bypass (Turbopack + single locale) — low current risk, patch anyway

apps/web/package.json

Requires Turbopack AND a single i18n locale. Project has no i18n config, so the current combination is not active. However, middleware uses a broad matcher on all routes and redirects to the platform app — if Turbopack or i18n is enabled later, exposure is immediate. The patch eliminates this risk class entirely.

GHSA-4c39-4ccg-62r3 / GHSA-68g3-v927-f742: Cache confusion + Edge payload — low risk, covered by patch

apps/web/package.json

Server Actions run on Node.js runtime (not Edge), so GHSA-4c39-4ccg-62r3 (unbounded Edge payload) does not apply. Cache confusion CVEs (GHSA-68g3-v927-f742, GHSA-4633-3j49-mh5q) could affect request body caching on form submissions, but the marketing site's POST bodies are small and well-formed. Patch resolves these regardless.

GHSA-p9j2-gv94-2wf4 and GHSA-89xv-2m56-2m9x — confirmed NOT applicable

apps/web/package.json

SSRF via rewrites: next.config.ts uses only redirects, no rewrites — not exposed. SSRF in Server Actions on custom servers: deployed on Vercel (not a custom server) — not exposed.

Consider adding Server Action rate limiting for the 3 public contact forms

apps/web/src/app/(marketing)

The DoS CVE (GHSA-m99w-x7hq-7vfj) targets Server Actions on public-facing routes. Once the patch lands, the vulnerability is closed at the framework level, but adding request-level rate limiting (e.g. Vercel's edge rate limiting or a simple in-memory debounce) would provide defense-in-depth against abuse of the 3 contact form actions (acceso, contacto, demo). Not blocking.