an hour ago
Hi all, one of our services, a background worker on the Hobby plan, was restricted on Oct 24 with the reason "Compromised service detected". Our appeal was denied, which I accept. What I'm trying to find out now is the cause, and if it is even possible to ever run this on railway again? If not, we will move to a different provider.
Since your recent incident notice, we've rotated every secret. In what we can see (deploy history, app logs and sampled network flows), there were no unexpected deploys, no unknown processes in the logs and no unusual outbound traffic. One thing that might be relevant: the worker fetches link-preview images (og:image) from URLs in public social media posts, so it regularly connects to arbitrary third-party websites.
A few questions, for the team or anyone who's been through this:
- Is there a way to find out what signal triggered the detection? For example, outbound connections to flagged hosts, something running in the container, or exposure in the incident.
- Can automated detection flag a service just for fetching URLs from user-generated content?
- Once the cause is fixed, are we allowed to run a replacement service in the same project, or would that count as getting around the restriction?
1 Replies
an hour ago
We don't share the specific signals or methods behind automated compromise detection, so we can't say what triggered it or confirm whether a particular behaviour like fetching URLs from user-generated content would be flagged on its own. The denied appeal is final for that service, and its restriction stays in place.
The restriction applies to that one service. It is not a restriction on your workspace or account, so it does not block other services. Any replacement should come from a remediated setup, not a copy of the flagged one: lock down or remove any public entry points the worker doesn't need, rotate every credential the service could reach (which you've already done), deploy from a clean image or rebuilt source, and treat data that service wrote as untrusted. A replacement that runs the same compromised setup is likely to be flagged and removed again.
Status changed to Awaiting User Response Railway • about 1 hour ago