Two Platforms That Run Your Code Disclosed Access to Customers' Environment Variables in Eleven Days. Neither Has Said How, and Neither Has Published an Indicator.
If you deploy through Railway or Trigger.dev, assume the secrets you stored there as environment variables are exposed until the vendor tells you otherwise, and rotate the ones that can cost you money or data first. That includes AI provider keys, database credentials and registry logins.
Railway disclosed on Wednesday, October 21 that an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Trigger.dev disclosed on Sunday, November 1 that an attacker gained unauthorized access to environment variables for a subset of its customer organizations. That is eleven days between the two notices.
What each vendor said
Railway's notice, as BleepingComputer reported it on October 22, says environment variables on the platform may contain secrets such as API keys or database and registry credentials. Railway told customers to rotate environment variables and secrets stored there, including private registry credentials, and to check service logs for unusual activity. It also said it notified AI inference providers and advised them to revoke all keys, and that it paused deployments.
Trigger.dev's own notice, titled Security Disclosure: Sunday November 1st, says it blocked the exploit used in the attack, but that its investigation found exposure across a subset of organizations, and that the attacker gained unauthorized access to environment variables for them. It says it emailed all impacted account owners with steps to mitigate and will follow up with more details. The status entry was marked resolved at 22:50 UTC on November 1.
What neither has said
This is the useful part, because it is the part that decides what you do.
How the attacker got in. Neither notice says. Trigger.dev says only that the exploit is blocked.
Which customers. Both say a subset. Trigger.dev says affected owners were emailed. If you did not get an email, that is the only signal you have, and it is not a guarantee.
When. We found no intrusion dates in either notice.
Which secrets. Both say environment variables. Neither says which values were taken, so you cannot narrow it from their side.
Indicators. We found no addresses, domains or hashes in either notice, and no attacker name.
What to do
The first two are the vendors' advice in substance. The rest is our recommendation, not theirs.
Follow the vendor's email if you received one. Do it first.
Rotate what is stored on the platform. Railway said so outright, and Trigger.dev has not said otherwise.
Check logs on the other side of each secret, not on the platform. Look at your AI provider's usage, your database's connection log and your registry's pull log for use from addresses you do not recognize. Because the intrusion dates are not public, start the search at the earliest disclosure date, October 21, and treat anything earlier as unknown.
Rotate in order of what an attacker can spend or read. AI provider keys come first because they cost money immediately and Railway itself told inference providers to revoke. Then database and registry credentials, then cloud credentials, then tokens for third-party services.
Use one key per platform. A key you created for Railway and revoke can be replaced in a minute. A key shared across three platforms is an incident across three platforms.
Where a platform supports short-lived credentials for a secret, prefer that to a long-lived value pasted into a settings page.
What the two have in common
Both platforms hold secrets on behalf of people who deploy code, which makes them an attractive place to look for keys. Nothing we read says the two incidents are connected, and the notices do not say they are not. We are not claiming a link. We are noting that the same kind of data was the target twice in eleven days and that the advice, rotate and check the other side, was the same both times.
What we hold, and what we don't
We hold no indicators for either incident because none were published, so there was nothing to add to our feed, and we added none. We have no sighting of our own and no way to see activity inside someone's hosting account. We are citing the vendors' notices and the reporting on them.
Limits
This rests on Trigger.dev's blog and status notice, BleepingComputer's report of Railway's notice, and The Register's report on Trigger.dev, which we did not read directly. We read the three sentences of Trigger.dev's notice that are public and not any follow-up report. We did not read Railway's own post, only BleepingComputer's account of it. The order of the rotation list is our judgment.
Five percent of this is wrong somewhere. It always is. The numbers will move again before you finish reading.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments