Railway Breach May Expose Store API Keys: Rotate Now

Railway Breach May Expose Store API Keys: Rotate Now
Railway Breach May Expose Store API Keys: Rotate Now
Affiliate disclosure: This post contains affiliate links. If you buy through them, I may earn a commission at no extra cost to you. Full disclosure

Railway, the cloud platform many store owners use to host automations and custom apps, said Oct. 21 that attackers may have read customers’ stored API keys and passwords.

If you run n8n, an order-sync script or a custom Shopify app on Railway, your Shopify Admin API token, Stripe key and email platform key may be in the exposed pile. At Ecommerce Paradise I treat that as a same-day rotation job, because those three credentials touch your orders, your money and your customer list.

If nothing you own lives on Railway, this one is not yours. The same question still applies to every freelancer, VA and vendor who holds a key to your store. Below: what Railway has actually said, why two other platform leaks this year make this look like a pattern, what the exposure looks like for a high-ticket store with hypothetical math, and six rotation steps in the order I would run them.

When a vendor leaks your keys, the business that carries the fallout should be an LLC, not you personally. Form your LLC with Northwest, the best LLC formation service for ecommerce owners. Plaintiffs and regulators start with the address on an LLC filing, and Northwest’s registered agent address keeps yours off that public record. Start your LLC the right way →

Railway Says Attackers May Have Read Customer Environment Variables

Railway published “Security Disclosure: Wednesday October 21st” at 20:44 UTC on its company blog, bylined Jacob Cooper. According to the post, Railway detected “anomalous activity involving systems that store customer environment variables” earlier that morning. An unauthorized third party may have accessed encrypted environment variables, and for some of them may have obtained the decrypted contents.

Environment variables are where apps keep their secrets. Per Railway, they can include API keys and database or registry credentials. Railway said its initial analysis suggests the impact may be limited to a subset of users, that the review is ongoing, and that it will email affected accounts once it confirms who they are.

Railway’s instructions were not subtle. Roll all environment variables stored in Railway, roll any private registry credentials, and review the logs of the services those credentials touch. The company also said it notified upstream providers so they could revoke exposed keys, and it linked the incident to a series of attacks on platform companies aimed at compromising AI inference providers.

The operational damage came on top of the security problem. Per the incident page on Railway’s status site, the dashboard, API and CLI went unavailable at 09:28 UTC on Oct. 21 and builds were paused in all regions. Deployments stayed paused after the security notice at 21:59 UTC. TechCrunch reported that the pause effectively froze customers’ websites and apps.

Recovery has been uneven. The same status page shows Railway invalidated all of its own API tokens at 04:17 UTC on Oct. 22, so existing integrations stopped working until new tokens were created. Builds returned for Enterprise workspaces at 03:32 UTC and for Pro at 06:29 UTC. In the latest entry I could retrieve, timestamped 07:11 UTC on Oct. 22, Hobby, Free and Trial workspaces were still waiting and deployments were slow to start. Check the page yourself, because that entry is already a day old.

Plenty is still unknown. Railway has not said how many users are affected, how the attackers got in, or which systems were compromised. TechCrunch said Railway did not respond to its request for comment and named no spokesperson. Railway’s “subset of users” language also sits awkwardly next to its instruction that all users rotate, and neither TechCrunch nor Railway resolves that tension.

One more gap matters to Shopify operators. None of the coverage I found mentions Shopify, Stripe or any ecommerce platform by name. The exposure runs through whatever you stored in Railway, not through a flaw in those products. GitGuardian, a secrets-security firm, advised treating every variable as exposed, including “sealed” ones, since Railway’s disclosure does not say whether sealed variables were affected.

Vercel, OpenCode, Railway: The 2026 Pattern of Stolen Secrets

Railway is the third platform incident this year where the prize was other people’s credentials. In April, Vercel disclosed that an attacker compromised a third-party AI tool, Context.ai, used that foothold to take over a Vercel employee’s Google Workspace account, and then enumerated and decrypted customers’ non-sensitive environment variables. Vercel’s incident bulletin says it declared remediation complete and closed the incident on Oct. 16, five days before Railway’s disclosure. Its advice was the same as Railway’s: rotate the variables and mark secrets as sensitive so they cannot be read back later.

Then came OpenCode. The open source AI coding tool disclosed a breach on Saturday, Oct. 17. Per TechCrunch’s Oct. 19 report, attackers got into an older system overnight and exposed API keys for 1.4% of users of its Console product. Developers reported unauthorized charges on their AI accounts, some in the hundreds of dollars and a few over $1,000. Anthropic and Google blocked the keys they believed were exposed, and OpenAI worked with OpenCode to restore access and refund credits.

OpenCode called it a large-scale distillation attack, meaning an attempt to harvest access to AI models. It did not explain how the attackers got in, and TechCrunch noted that some skeptics think it was an ordinary breach with no proven distillation purpose. Railway’s own explanation, attacks aimed at AI inference providers, borrows the same frame. Treat both claims as the companies’ attributions, not established fact.

The wider backdrop is a government warning. Help Net Security reported in September that CISA was warning about Chinese AI firms siphoning capabilities from American models. If attackers want AI provider keys, any platform that stores customer secrets next to AI workloads is a target, and a lot of ecommerce automation now sits on exactly those platforms.

This is not the first stolen-credential story I have covered for store owners. On Wednesday I wrote about stolen UpdraftCentral keys being used to backdoor WordPress stores. Yesterday I covered the PHP2Shell patches and attackers probing WordPress stores. TechCrunch says the Railway attack appears separate from PHP2Shell. The common thread is not one attacker. It is that credentials are now the cheapest way into a store.

Why a Railway Leak Reaches Your Shopify Admin and Stripe Account

This section is my analysis, not reporting.

My read: assume you are in the subset until Railway’s email says otherwise. Railway has not told anyone how big the subset is, and waiting for an email while credentials are loose is a bad trade. Rotating costs you hours. Being wrong costs you customers.

Here is why store owners in particular should care. Railway’s own n8n Shopify template deploys the self-hosted automation tool n8n with Postgres and Redis for order notifications, inventory sync, low-stock alerts, fulfillment orchestration and refund tracking. The setup calls for a Shopify Admin API access token or OAuth2 credentials from a custom app, with read and write scopes on orders, inventory, fulfillments and products. Those tokens live in n8n’s credential store, encrypted with a key called N8N_ENCRYPTION_KEY, which is itself an environment variable.

My inference, which Railway has not confirmed: the key that unlocks your stored credentials and the database connection that holds them can both sit in the pool of variables that may have been read. I would not bet a customer list on the attacker missing one of them. If you copied that template, or any template like it, you are the exact person this incident was written for.

Now the hypothetical math. Say a high-ticket store does 20 orders a month at a $2,200 average order value, which is $44,000 in monthly revenue. That is about 0.67 orders a day. If your order-push automation is down for two days while you rotate tokens, roughly 1.3 orders sit unforwarded to suppliers, around $2,900 of revenue waiting on a manual fix. That is the cost of doing this carefully. Compare it with a read-write Shopify token in the wrong hands: every customer name, address, phone number and order history you have processed, plus the ability to touch fulfillments. For a store selling furniture, spas or powersports, those customers are people who just spent four figures with you.

Then there is who pays. Railway’s terms of service, effective April 20, 2026, cap its liability at the greater of $100 or the amounts you paid it, and exclude consequential damages such as lost profits and data loss “to the fullest extent allowed by applicable law,” per the terms page. Some states do not allow those limits, so I am not telling you the clause holds in every case. I am not a lawyer. My read is that your recovery from the vendor will be small compared with your exposure to your own customers.

A survey I covered found 93% of surveyed firms lack control of saved card data, and it fits the same pattern of data you hold but do not fully control. That asymmetry is why entity structure and insurance belong in this conversation. If your store still operates as a sole proprietorship, see my walkthrough at how to form your business before the next incident rather than after it. Ask an insurance broker whether your policy covers a vendor-caused data exposure, because many small business policies were written before this kind of loss was common.

Scenarios, with thresholds. If you have no automation hosted on Railway, spend 20 minutes confirming that with whoever built your tools and move on. If Railway hosts something minor, like a test project or an internal dashboard with no payment or customer keys, rotate within 24 hours. If Railway hosts anything holding a Shopify token, a Stripe key, a supplier feed password or an email platform key, rotate those before you do anything else today and pull your logs. If you cannot redeploy because builds are still queued, revoke the old credentials at the source anyway. A broken sync for a day is cheaper than a live key in unknown hands.

There is a fair counterargument. Self-hosting automation to avoid per-task fees is a sensible trade at low volume, and Railway moved fast to rotate bucket credentials, invalidate its API tokens and tell users what to do. But a few dollars a month in saved task fees looks different the day the setup becomes your only line into Shopify. A managed tool like those I priced in my Zapier pricing breakdown is not immune either. I covered a security hole in the AI running Shop Pay checkout last month. The point is not that hosted tools are safe. It is that fewer places holding your keys means fewer incidents you have to rotate through.

If you sell on WordPress or WooCommerce instead of Shopify, the same logic favors a managed host where someone else patches the stack. Cloudways is one I point people to for that. My notes on hosting WooCommerce sites at scale cover what to ask a host before you move.

As more tools such as Claude Duet get permission to act for your business, I expect the number of credentials you have to track to grow, not shrink. The deeper problem for most store owners is that you have no map of where your keys live. A VA connected an app two years ago, a freelancer built a Zap, a developer left a script running. This is the operator complexity that sinks stores when it is Black Friday and something breaks. If you would rather have a team that owns that map, that is what my team does when we build and run a store for you through the turnkey done-for-you service.

Tired of being the person who rotates API keys at midnight? Let my team build and run your high-ticket store, with the infrastructure already mapped and locked down. See the turnkey done-for-you service →

Rotate Shopify, Stripe and Klaviyo Keys After the Railway Breach

Run these six steps in this order. The sequence matters, because GitGuardian’s guidance is to rotate the upstream credential first and update the app second.

  1. Inventory every place a key lives. List every automation, custom app, headless storefront and internal tool, and who hosts each. Check your Railway dashboard if you have one, and ask your developer or VA directly. Then paste only the variable names, never the values, into Claude and ask it to sort them into a rotation order by blast radius: payments first, store admin second, email and helpdesk third.
  2. Rotate the Shopify token. Per Shopify’s developer docs, you cannot rotate the API key or secret of an admin-created custom app. You uninstall and reinstall the app, which generates a new token, and requests and webhooks break until your code uses it. Do not delete the app, because Shopify says that removes the configuration for good and you cannot create another admin-created app. For anything new, use an OAuth flow in the Dev Dashboard. Do this inside Shopify, then check Apps and staff accounts for anything you do not recognize.
  3. Roll your Stripe key. Stripe says rotating a key revokes it and generates a replacement, and you can roll immediately or schedule the old key to expire. If your automation only needs to read orders or create refunds, replace the full secret key with a restricted key that does only that. Then read Stripe’s API request logs for requests you do not recognize. If one processor is your only way to get paid, build the backup plan I laid out for processor failures while you are in there.
  4. Replace email, helpdesk and supplier keys. Create a new private API key in Klaviyo with the narrowest scopes your flow needs, swap it in, verify, and delete the old one. Do the same for Omnisend if you use it. Repeat it for Gorgias or whatever helpdesk is connected. Then handle the feed credentials you use with Inventory Source or any other supplier integration. Sequence each one as create, update, verify, delete.
  5. Review logs further back than you think. Railway has not published when access began. I would go back at least 30 days on Shopify, Stripe, your email platform and any cloud account those variables touched, and keep an alert on for unusual activity through Cyber Monday. My high-ticket Black Friday stress-test checklist has the rest of the pre-peak list.
  6. Close the door for next time. Put every secret in a password manager or secrets vault, mark variables as sensitive wherever your host allows it, give each workflow its own key, and turn on two-step verification on the Google Workspace account that owns your hosting and GitHub logins. The Vercel incident started with a Google Workspace account takeover. If you want a second set of eyes on your stack, book a call through my discovery page.

Frequently Asked Questions

Do I need to do anything if I do not use Railway?
Not for this incident. Spend 20 minutes finding out where your automations are hosted and who holds your keys, because a developer you hired may have used Railway or a similar platform without telling you.

Is my Shopify store itself hacked?
Nothing I found says so. The reporting I read does not name Shopify, and the exposure is about credentials stored in Railway, not a flaw in the store platform. Rotate your tokens anyway if they ever touched Railway, and read my note on Shopify’s guidance to app developers after recent hijacks.

What if I cannot redeploy because Railway builds are paused?
Revoke or roll the credential at the source anyway. Your automation may break until Railway restores builds for your plan tier, but a dead sync is better than a live key in unknown hands.

Will Railway compensate affected customers?
Nothing I found shows an announcement. A write-up by Dennis Weidner noted that Railway had announced compensation after a February 2026 incident but nothing for this one at the time of writing, and the terms of service cap liability. I am not a lawyer, so check your own agreement.

Is this connected to the PHP2Shell vulnerabilities?
TechCrunch says the Railway attack appears separate. If you run a PHP-based store, patch regardless, and see my report on the PHP emergency patch.

Should I stop self-hosting my store automations?
Not necessarily. At 10 orders a month, a self-hosted workflow is fine if you rotate keys and limit scopes. If you are earlier in the journey and still choosing tools, my free beginner guide walks through a safer starting stack. Outages count as infrastructure risk too, as a Google Cloud London outage that disrupted Revolut cards showed this week.

How long should I watch my logs?
My pick is through Cyber Monday. Railway has not given an intrusion window, so a longer lookback and a longer watch period cost you very little.

Want other store owners comparing notes on locking down their stack, with me in the thread? Join the Skool community →

I will keep watching Railway’s status page and flag anything that changes the picture, including the affected-user count if they publish one. Subscribe to the YouTube channel for daily breakdowns. More breaking news coming through the day.

Related Articles

If this was useful, these go deeper: