didn't receive any notifications from Railway regarding this. What were the criteria used to identify the subset of identified impacted customers?

I would assume version numbers in package.json

i'd have assumed so to, but didn't hear anything from Railway. would have been really nice to have gotten an email about it, would definitely have saved me a headache. But still, also a good lesson and will be staying on top of security news going forwards.

There may have been some missed notifications for sure - we only have these stats from users of Railpack, so if you're using a custom Docker image or Nixpacks, we wouldn't know about it unfortunately.

ok cool, upgrading to Railpack!

Update: We've pushed out a feature to block deployments of any impacted versions.

If you see any such errors in your build log, please upgrade your React/Next versions IMMEDIATELY.

You will not be able to deploy until you have upgraded to a patched version without the security vulnerability.

I have updated package json and package-lock json but still can't seem bypass this check, are there any cached version you are consulting???
Also, I am running this from a monorepo, and all my frontend does not run in railway, still I can't push any changes to backend services because of this

Can you share a link to your service please?

https://railway.com/project/18c58081-5bb6-4bc3-b0ed-815b6422e8a8/service/f8302f9d-ac5a-4ecd-9e42-8298c40d3437?environmentId=7c504e98-0121-460a-8e63-d3fe84ede6e6

Hmm, could you try redeploying with NO_CACHE=1 service variable?

No suffice

Saw your latest deploy failed

Do you have any dependencies in your monorepo referencing those vulnerable versions? Are you able to share your package.json here (for your frontend package and root monorepo)?

it is weird you guys are doing a full scale grep on nextjs, but might be worth, I had a folder somewhere in there with an old package.json file (it was not deployable even)

Ahh yes, we want to be extra sure here because this is a really scary vulnerability. Sorry for the inconvenience!

Great work, thanks for all the hard work you guys put into Railway!

I had the same issue. My .lock file was not part of the Watch Paths . So when I re-deployed it would still give me the same error.

Are you referencing the impacted versions anywhere, e.g. a peer dependency?

I have upgraded my Next version within my monorepo to 16.0.10 and I am blocked from deploying the rest of my services within the monorepo. What I see in the pnpm.lock are other libraries referencing the old vulnerable version of Next. How should I resolve this? I have a critical update to release in my app, and I am currently blocked.

Are you able to update the other libraries to see if they've pulled in the latest (or a patched) version of Next?

Otherwise, you can try setting it in the overrides field in your package.json

Overrides are not working.

Please update your block to only affect the actual deployments of NextJS and look at the actual deployment of NextJS's version. This is quite frustrating and unnecessary.

We can't do that unfortunately - really sorry for the inconvenience, but you'll need to update those libraries that are not depending on a vulnerable Next version.

If you can share your package.json here, I'm happy to help you figure out the overrides.

This is unacceptable. You are infrastructure. What I deploy should get deployed. It's not your responsibility to keep my application safe.

We are in a feature migration right now and are unable to re-deploy an accidental staging deploy right now due to this.

This is a monorepo with several services and two front ends. My frontends are built on NextJS and are completely safe and have been since Vercel sent out the email a week ago - as soon as I got the email, I promptly updated my NextJS apps to 16.0.10 -

Libraries simply reference as peer dependencies - they don't force a Next version. Your change has completely screwed up an important update I had for one of my apps. Coincidentally, the front end is actually deployed on Vercel, while the services are here.

I see your side and I completely empathize with you [0], however we also have to consider the larger userbase of Railway which this change is targeted at - if we allow people (some non-technical folks, vibe coders, etc.) to deploy vulnerable versions, we're putting them at risk.

If you want to override all of your peer dependencies, you can do something similar to the below (depending on your package manager):

{
  // ...
  "pnpm": {
    "overrides": {
      // ...
      "next": "^16.0.10"
      // ...
    }
  }
}

[0] our railway.com frontend hosted on Railway itself also failed to build because we had these deps in some other packages that weren't used in live code. So, I know this is frustrating because we're going through similar frustrations on our end, and I'm really sorry - we're trying to do right by everyone and unfortunately a supply chain attack of this level isn't something that everyone is going to find a happy middleground on. Better monorepo detection is a very reasonable ask that I'll surface, but the quickest way to unblock you right now is to either update the libraries with the vuln peer deps or use the above. Again, I'm sorry

Understand where you're coming from...but now the discussion on our side is when do we move away from Railway... experienced folks don't like being forced into stuff like this.

Your "workaround" still required a release/deployment

That's entirely fair. We always aim to strike a balance between "delightful UX" <-> "right levels of escape hatch" and this is unfortunately not an escape hatch we can give away :-/

Sorry!

Hey, i am also facing the same issue. i have upgraded my next to 15.2.8. ans still getting the same error security vulnerability detected.

I am also still being blocked by this error even after upgrading to next@16.0.10.

I was able to get unstuck with a NO_CACHE=1

Will add my voice to the list of those fleeing railway ASAP though, not only due to the handling of this issue. Surprise downtimes, UI frequently not loading, etc..

For anyone facing this issue while waiting for your dependencies to release an update with the patched Next.js version, you can add the following to your package.json to force all packages to use the latest Next.js with security fixes:

"pnpm": {

"overrides": {

"next": "16.0.10"

}

}

replace "pnpm" with : "npm", "yarn", "bun" if you use another package manager

Then run your package manager's install command to update the lockfile.

However, I recommend leaving it temporarily and checking regularly for updates to your dependencies.