fix: upgrade Next.js to 15.5.7 (CVE-2025-55182) #1335
Conversation
This upgrade fixes CVE-2025-55182, a React Server Components RCE vulnerability.
ctate
requested review from
dominiksipowicz,
goncy,
lfades,
lpalmes and
okbel
as code owners
![vercel[bot]](https://avatars.githubusercontent.com/in/8329?s=60&v=4){kind=small}
There was a problem hiding this comment.
🔧 Build Fix:
The url parameter in the SWR fetcher callback is missing a type annotation, causing TypeScript to report it as implicitly having type any when strict mode is enabled.
View Details
📝 Patch Details
diff --git a/solutions/cron/components/post.tsx b/solutions/cron/components/post.tsx
index cdf93a32..58fe5be9 100644
--- a/solutions/cron/components/post.tsx
+++ b/solutions/cron/components/post.tsx
@@ -12,7 +12,7 @@ interface DataProps {
}
export default function Post({ interval }: { interval: string }) {
- const { data } = useSWR<DataProps>(`/api/data/${interval}`, (url) =>
+ const { data } = useSWR<DataProps>(`/api/data/${interval}`, (url: string) =>
fetch(url).then((res) => res.json())
)
Analysis
Missing type annotation for SWR fetcher parameter causes TypeScript compilation failure
What fails: TypeScript compiler fails with strict mode enabled because the url parameter in the SWR fetcher callback lacks an explicit type annotation, causing it to implicitly have type any.
How to reproduce:
cd solutions/cron
pnpm run buildResult:
./components/post.tsx:15:64
Type error: Parameter 'url' implicitly has an 'any' type.
[0m [90m 13 |[39m
[90m 14 |[39m [36mexport[39m [36mdefault[39m [36mfunction[39m [33mPost[39m({ interval }[33m:[39m { interval[33m:[39m string }) {
[31m[1m>[22m[39m[90m 15 |[39m [36mconst[39m { data } [33m=[39m useSWR[33m<[33mDataProps[33m>[39m([32m`/api/data/
Root cause: The tsconfig.json has "strict": true enabled, which enforces strict type checking. Function parameters must have explicit type annotations when used in contexts where the type cannot be inferred from the callback signature.
There was a problem hiding this comment.
🔧 Build Fix:
The package exports configuration doesn't declare TypeScript type definitions. The exports field only points to the JavaScript file, causing TypeScript compilation to fail with "Cannot find module" error when building dependent packages. The fix adds proper type declaration in both the exports field and as a top-level types field.
View Details
📝 Patch Details
diff --git a/starter/turborepo-with-hono/packages/constants/package.json b/starter/turborepo-with-hono/packages/constants/package.json
index 5e12fb9f..4265bbdd 100644
--- a/starter/turborepo-with-hono/packages/constants/package.json
+++ b/starter/turborepo-with-hono/packages/constants/package.json
@@ -1,8 +1,12 @@
{
"name": "@repo/constants",
"exports": {
- ".": "./dist/constants.js"
+ ".": {
+ "types": "./dist/constants.d.ts",
+ "default": "./dist/constants.js"
+ }
},
+ "types": "./dist/constants.d.ts",
"scripts": {
"build": "tsc"
},
Analysis
TypeScript module resolution fails for @repo/constants in turborepo-with-hono
What fails: TypeScript compilation in the api app fails when importing @repo/constants because the package.json exports configuration doesn't properly declare type definitions.
How to reproduce:
cd starter/turborepo-with-hono
rm -rf packages/constants/dist
pnpm turbo run buildResult before fix:
[ERROR] Error: src/index.ts(2,26): error TS2307: Cannot find module '@repo/constants' or its corresponding type declarations.
Result after fix: Build succeeds without TypeScript errors. The module is properly resolved with correct type definitions.
Root cause: The @repo/constants package.json had an exports field pointing only to the JavaScript file, without declaring the TypeScript type definitions. When TypeScript tries to resolve the module with moduleResolution: "nodenext", it cannot find the type information and fails with TS2307.
Solution: Updated the exports field in package.json to properly declare both the types and default exports, and added a top-level types field for compatibility.
There was a problem hiding this comment.
🔧 Build Fix:
The Turbo cache configuration doesn't include .vercel/** in the build outputs, causing the Vercel adapter output to be excluded when the build task is cached. This results in a missing deployment directory during Vercel deployments when a cache hit occurs.
View Details
📝 Patch Details
diff --git a/storage/blob-sveltekit/turbo.json b/storage/blob-sveltekit/turbo.json
index 520fded2..3f7ad9bb 100644
--- a/storage/blob-sveltekit/turbo.json
+++ b/storage/blob-sveltekit/turbo.json
@@ -2,7 +2,7 @@
"$schema": "https://turborepo.com/schema.json",
"pipeline": {
"build": {
- "outputs": [".svelte-kit/**"]
+ "outputs": [".svelte-kit/**", ".vercel/**"]
},
"lint": {}
}
Analysis
Turbo cache excludes Vercel adapter output causing deployment failure
What fails: Vercel deployment fails with "No Output Directory named 'public' found" when build task uses Turbo cache
How to reproduce:
- Run
pnpm turbo buildwhen build is cached (Turbo cache hit) - Check for
.vercel/outputdirectory - it will not exist
cd storage/blob-sveltekit
rm -rf .vercel .svelte-kit
pnpm turbo build # First run - no cache
pnpm turbo build # Second run - cache hit, .vercel/output is missing
ls .vercel/output # Does not existResult: When Turbo has a cache hit, it only restores outputs listed in turbo.json#pipeline.build.outputs. The file only specified [".svelte-kit/**"], which excluded .vercel/** - the output generated by @sveltejs/adapter-vercel. During cached builds, the .vercel/output directory was not present, causing Vercel's deployment to fail looking for deployment artifacts.
Fix: Add .vercel/** to the outputs array in turbo.json to ensure Vercel adapter output is cached and restored with the build.
This upgrade fixes CVE-2025-55182, a React Server Components RCE vulnerability.