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.

and this is unfortunately not an escape hatch we can give away :-/

This was incredibly short-sighted. You are not giving an escape hatch, you are giving a "please proceed" button for services that are not even vulnerable to people who know as much as you. Or you know better than 100% of your customers?

Did you even know that not all next apps are vulnerable? If you knew this and still decided to do this, then what's the reason? You don't trust your customers to make the technical decisions?

This was the worst way to handle this. Cannot believe that someone thought this was ok.

Is there a link where I can read what is required in a CVE for railway to do this again? Or was this just a one-time stunt because the CVE went viral?

react2shell fix literally says no vulnerabilities found, but railway still flags

This is a very valid point. I'm hearing your side, and I will circle back on this with an update here.

You should not rely on react2shell. It only detects attack vectors that have been disclosed to the public. There are vectors that have not - we have seen evidence of this in our recent incident [0]. We have been and will continue to refine our WAF ruleset to block them, but the best protection here is to upgrade to a patched version.

[0] https://blog.railway.com/p/incident-report-december-16-2025

Edit: sorry my comment may have been inaccurate - it looks like you’re using the tool from vercel labs for fixing deps? In that case yes, we consider peer deps as well

So, here's an update - sorry for the delay!

I've added a new env var you can add to your service that will disable vuln checking:

RAILWAY_DANGEROUSLY_SKIP_VULNERABILITY_CHECK="I_ACCEPT_THE_RISKS"

Setting this in your service variables will fully disable our automated third-party dependency vuln scanner, and allow you to deploy. You will also see this warning in your build logs:

We STRONGLY encourage you to upgrade any and all impacted packages, even a peer dependency, but this escape hatch will give you an out if you cannot do that right now or need to release urgently.

My apologies for the mis-step here. We were caught between a rock and a hard place with an incident [0] caused by the exploitation of this vulnerability, and hence we err'd on the side of heavy-handed measures. But that doesn't excuse the mistake.

We'll handle this better next time. Thank you for the feedback, and if there's anything we can to do earn your trust back - please let us know, we're always listening!

[0] https://blog.railway.com/p/incident-report-december-16-2025

Note: this is being gradually rolled out across our fleet as of the time of this post - if it doesn't work for you, please try again in ~1 hour from the time of this post. If it still doesn't work then, please let me know.