Next.js schedules an October 14 security release for three upstream dependency flaws, two of them Critical

Three records can each name a Next.js version for the same app. One is the range in the manifest. Another is the exact version the lockfile resolved. The third is the build the deployment platform is serving ^[9][10]. A dev.to guide to preparing for the update points out that a manifest range may not identify the exact dependency the lockfile resolved ^[9]. Its check is to compare the lockfile with the deployed commit and with the platform's live release record ^[10].

We think the guide's most useful caveat is about its own tools. Commands such as `npm ls next` or `pnpm why next` inspect the installed dependency tree, and the guide says they do not by themselves prove which build is serving users ^[11]. The tree describes the commit that is checked out. Production runs whatever was last promoted, and a local checkout can be ahead of it ^[9].

The vulnerabilities are in upstream dependencies ^[1]. The announcement does not yet say which dependencies or Next.js versions are affected, whether a given app is exposed, or which upgrade command applies ^[6]. The guide notes that the labels "Critical" and "High" communicate severity but cannot tell a team whether its deployed app is affected ^[2]. Its position is to wait for the affected-version range, compare it with the inventory, and not change versions on a guess ^[12].

The rollout it sketches is the team's normal release process, run in order ^[13]:

1. The owner prepares a branch and updates the dependency according to the official instructions. 2. The owner regenerates the lockfile with the project's package manager and runs the repository's normal checks. 3. A reviewer confirms the diff contains the intended dependency change and that unrelated packages were not upgraded by accident. 4. The app moves through the existing staging and production promotion steps.

In our view step 3 matters most on a security release. Regenerating a lockfile can move packages nobody meant to touch, and the review is where the guide expects that to be caught ^[13]. The guide also advises against a broad dependency refresh just because a security release is coming ^[12]. A refresh done this week mostly hands the reviewer a longer diff to read on the 14th.

Out-of-band means the date sits outside the framework's normal release cadence, and the guide says not to assume otherwise ^[14]. It suggests assigning one person to check the official source that day and pass the published instructions to whoever owns each application ^[14].