Agreed, this is a pain for me too. My app is currently deployed on the problematic version. The app is also not very important and there is nothing an attacker could exploit so I'd love to disable this feature...

I hear you, and this is valid feedback. You're right that blocking deploys outright can put you in a tough spot, especially when you're trying to ship a fix for something more urgent and the CVE in question might not even be exploitable in your specific context.

That said, Railway operates as a shared infrastructure platform, so we do have to weigh the risk of vulnerable dependencies being exploited in ways that could affect not just your workload, but others on the platform as well, such as cryptomining or resource abuse that can impact neighbors.

Your suggestion about a notification-first approach with a deadline rather than an immediate hard block is reasonable feedback. I'd encourage you to submit this as a feature request at https://station.railway.com/roadmap so other users can upvote it and our team can properly evaluate it against our security model.

The CVEs listed in the error message blocking me from a push were a couple of extremely non-worrying DOS/hang vulnerabilities. I.e. things that are completely my problem and not Railway's problem. If it burns my budget or brings my site down, that's for me to deal with. Furthermore, as I brought up in my initial post, Railway blocked me from pushing out a release with the same versions of these dependencies that were already serving. So clearly the push did not introduce additional risk for me, or for Railway.

I have written and reviewed many dozens of serious postmortems for service outages totaling in the tens of millions of dollars of revenue loss, and if I discovered that this kind of nanny check added any additional friction to pushing out the temporary or permanent fixes for an ongoing incident, the first P0 postmortem action item I'd list would be to add a manual override for the nanny check, without question. (I am quite certain that Railway itself would not tolerate this kind of non-overridable block in its own infrastructure!)

If the suggestion is to file a roadmap request, for me that translates to finding a different infrastructure provider. My business is tiny right now so I'm under no illusion that my "wallet vote" really matters, but Northflank Render seems like a great option that will give me the control I need. Disappointing, since I love Railway's simplicity and am in general a huge fan, but I guess Railway's philosophy is not compatible with my business requirements. :/

I wrote this up in a lot more detail on my devlog: https://anukari.com/blog/devlog/railway-knows-better-than-you

Is there a flag that one can use to bypass that check? I have a very old app that needs to be updated and upgrading next.js is not an option

No bypass flag. Railway replied in a lot more detail here:

https://news.ycombinator.com/item?id=46316167

Thanks for link, hope they will allow us to bypass the error asap..

I've also responded in https://station.railway.com/community/security-alert-react-next-js-remote-cod-2b0bab9d re: bypass flag

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

Sorry for the frustration this is causing!

[cross-posting from Security Alert: React/Next.js Remote Code Execution (CVE-2025-55182)]

---

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.

Failing to deploy from the local computer using CLI due to mysterious "Invalid Character" complaints on some .ts files. There is none after a solid check. I guess that there are bugs in the CLI deployment tools. Given this background, I tried my luck to deploy with GitHub. Bingo! The build hit the "security vulnerabilities" and stopped. I would expect a wiser approach to automatically run "npm audit" to fix it on the fly and continue. Overall, the platform has a good concept, but the quality of implementation needs to catch up and wise up.