Railway セキュリティ開示：環境変数が侵害され、全デプロイが一時停止

Railway は10月21日、不正な第三者が顧客の環境変数にアクセスした可能性があり、その一部については復号された内容を取得した可能性があることを開示し、同時にすべてのデプロイを一時停止して、すべての顧客にすべてのシークレットをローテーションするよう通知しました。この開示に関する Hacker News のスレッド（547ポイント、318コメント）では、盗まれたキーがすでに使用されたと報告する開発者と、1つの運用上の矛盾が支配的です。ユーザーは認証情報をローテーションするよう指示されたが、ビルドが無効になっている間は新しい値を反映するために再デプロイできないというものです。

Railway が実際に開示した内容

Railway は、10月21日の朝に顧客の環境変数を保存するシステムで異常なアクティビティを検出し、これまでの調査では、不正な第三者が暗号化された環境変数にアクセスし、その一部については復号された内容を取得した可能性があると述べました。

開示内容より：

今朝早く、Railway は顧客の環境変数を保存するシステムに関わる異常なアクティビティを検出しました。さらなる調査の結果、これまでの調査では、不正な第三者が暗号化された環境変数にアクセスし、その一部については復号された内容を取得した可能性があることが示されています。環境変数には、API キーやデータベース・レジストリの認証情報などのシークレットが含まれる場合があります。

Railway が述べた主要なポイント：

Railway 上の環境変数には、API キー、データベース認証情報、プライベートレジストリの認証情報などのシークレットが含まれる可能性があります。
Railway は、この侵入は「AI 推論プロバイダーを侵害することを目的とした、最近プラットフォーム企業を標的にした一連の攻撃」の一部であると考えています。
Railway は、これらの上流プロバイダーに通知し、キーを事前に失効させられるようにしたと述べています。
Railway の初期分析では、影響は一部のユーザーに限定される可能性がありますが、すべてのユーザーが予防措置として行動することを推奨しています。
推奨されるアクション：「Railway に保存されているすべての環境変数（API キーを含む）と、プライベートレジストリの認証情報を直ちにローテーションし、それらのサービスのログで異常なアクティビティを確認してください。」
Railway が調査している間、すべてのデプロイが一時停止されたため、ユーザーはビルドが復旧するまで新しいバージョンを展開できません。
Railway は、確認された影響を受けるアカウントにはメールで直接連絡し、ブログのお知らせと status.railway.com で更新情報を投稿すると述べており、インシデント QH8L8B3E を参照しています。

中心的な矛盾：シークレットをローテーションするが、再デプロイできない

スレッドで最も繰り返された不満は、Railway の2つの指示が多くのユーザーにとって相互排他的であるということです。Railway 内でシークレットをローテーションしても、そのサービスが再デプロイされるまで実行中のサービスには効果がなく、デプロイは一時停止されていました。

「デプロイを無効にした状態でキーをローテーションするなんてどうやって可能なんだ？実質的にサービスをオフラインにしろと言っているようなものだ...」 — fyzix

「ダウンせずにシークレットをローテーションする方法を説明してくれませんか？」 — fmvilas

「OpenRouter がこのインシデントに基づいて以前のキーを失効させたので、env var の API キーを変更しました。しかし、私の地域では再デプロイができないため、env を更新できず、現在製品を使用できません。」 — averrous

複数のコメント投稿者は、アドバイスに従う前よりも状況が悪化したと述べました。現地時間の午前5時20分にキーをローテーションしたある開発者は、ログに不正使用の兆候は見られず、行動しなければサービスは「少なくともオンラインのままであっただろう」と書きました。別の開発者は、キーを失効させた後、アプリがダウンし、再デプロイできなかったと述べました。rdm_blackhole は、バケットの認証情報が Railway によって再生成されたが、デプロイは停止したままで、サービスがバケットに接続できず、その順序を「完全に愚か」と呼びました。

rdm_blackhole はまた、スレッドの後半で、ビルドがまだ CET 11:43 の時点でキューに詰まっており、再デプロイなしではキーを効果的にローテーションできず、Discord の検証が不可能で、ダッシュボードのサポートリンクが 404 ページにつながったと報告しました。

開発者は、漏洩したキーがすでに使用されたと報告

スレッドには、盗まれた認証情報が開示の前または直後に第三者によって使用されたという複数の直接の報告があります。特に LLM API キーです。

「一晩中本番のシークレットをローテーションしている... 最悪だ。彼らがすでに私のシークレットキーの多くを実際に使用していることを確認した。」 — dylanz

「Railway Discord で、Railway に保存されたシークレットが第三者によって使用されたことを確認した複数の人を見た。攻撃者が復号された環境変数を読むことができたのは間違いないようだ。」 — MattIPv4

スレッドからの具体的な報告：

あるコメント投稿者は、Railway のデプロイで使用されていた Anthropic API キーが、Railway の通知を受けてから約3時間後に不正使用の証拠により無効化され、不正使用が検出されるまでに約20ドルのトークン消費があったと述べました。
別の投稿者は、OpenRouter キーが盗まれ、約2ドルの請求が発生したと述べました。
3人目は、OpenRouter ダッシュボードに、自分が行っていない Anthropic モデルへの API 呼び出しが表示され、ログには Go HTTP クライアントとプロバイダーとして Anthropic のみが使用されていたと述べました。彼らは「主な標的は LLM API キーだったとかなり確信している...」と書きました。
cowlby は、10月21日午後5時54分13秒 CDT に Railway スタッフによって BucketInstanceCredential.regenerated が3回実行された監査ログエントリを投稿し、データベースとバケットの認証情報が環境変数にある場合、攻撃者はデータベースとバケットの内容にもアクセスできた可能性が高いと推論しました。

別のコメント投稿者は、盗まれた LLM キーがどのように現金化されるのかを尋ね、侵害されたキーで安価な推論を再販する怪しげな AI マルチプレクサーを推測しましたが、スレッドではこの質問に答えていません。

「AI 推論プロバイダーを標的にした攻撃」という枠組みは懐疑的に受け止められた

Railway の、このキャンペーンは AI 推論プロバイダーを侵害することを目的としているという声明は、文脈として普遍的に受け入れられたわけではなく、一部のコメント投稿者はその枠組み自体を責任転嫁と読みました。

「すべてのセキュリティ侵害の開示に、『攻撃者は AI を使った！』というお決まりの文が付くのは面白い。まるで安全なシステムを維持する責任から逃れられるかのように。むしろ状況をより悪くしている。AI を使ってエクスプロイトを見つけることが可能なら、自社のレッドチームが攻撃者より先に見つけるべきだったはずだ。」 — paxy

他の人々は、開示が答えていない基本的なアーキテクチャ上の疑問を尋ねました。暗号化されたシークレットがどのようにして復号されたのかという点です。

「シークレットはどのように復号されるのか、ここで理解するために何か説明が欲しい... 環境シークレットはどのようにして全員に漏れるのか...」 — minraws

「誰かが環境変数とその暗号化キーの両方を手に入れたのか？今そこにいるセキュリティオペレーションズエンジニアの気持ちがわかる。ひどい」 — ksajadi

開示では、復号がどのように発生したか、または影響を受けたアカウントの数については述べられていません。

コミュニケーションとタイミングに関する苦情

繰り返し出てくるテーマは、ユーザーがメールが届くずっと前に Discord サーバーまたはステータスページからインシデントを知ったということです。

「人々は3時間前、インシデント開始から10時間後に、Railway 専用に作成されたキーが使用量を消費していると Discord に書いていた。一方、ビルドは12時間以上ダウンしている。今になってようやく全顧客にメールを送った。」 — alpineman

あるコメント投稿者は23時36分にメールを受け取ったと述べ、あるヨーロッパの開発者は、目が覚めた時にはデプロイがすでに24時間ダウンしており、「これを午前2時まで待って言うのは非常識に感じる」と付け加えました。別の投稿者は、開示がブログのサブドメインにある一方で、マーケティングのホームページはまだ「ソフトウェアを平和的に出荷する」と読め、インシデントについて言及がないと指摘しました。

さらに、あるコメント投稿者は「Railway は前回の大規模な障害の理由について正直ではなかった」と主張し、別の投稿者は、今年初めに顧客データが漏洩したインシデントの後、すでに主要な顧客を Railway から移行したと述べました。

同日のより広い文脈

コメント投稿者は、Railway のインシデントをセキュリティチームにとって最悪の24時間の一部として位置づけました。

「サイバーセキュリティにとって狂った日だ：PHP RCE、eMudhra 証明書、そして今度は Railway。そしてこれはまだ始まったばかりだと思う。」 — vldszn

このコメントは、eMudhra 証明書侵害に関する Cloudflare の投稿と、PHP RCE に関する Wiz の投稿へのリンクです。別のコメント投稿者は、Railway の出来事を週末に opencode が受けたハッキングと比較し、ある投稿者は次に「Vercel の SNAFU で目覚める」ことを期待していると冗談を言いました。

移行の話：VPS、Cloud Run、fly.io、セルフホスティング

複数のコメント投稿者は、このインシデントと数日にわたるデプロイの一時停止を合わせて、プラットフォームから離れることを検討していると述べました。

ある開発者は、Railway の前回の障害の後、Cloud Run への移行を検討し、プラットフォームにもう一度チャンスを与えたが、今は留まる可能性は低いと考えていると述べました。
別の開発者は、fly.io への緊急移行を最小限の混乱で実行し、環境変数を変更できるようにすぐに移行するよう他の人にアドバイスし、「Railway にこれ以上1セントも渡すな」と付け加えました。
別の投稿者は、Coolify を使用してデータベースをセルフホスティングに移行したと述べました。
ある投稿者は、プロジェクトを直接ホストするために、現在 Hetzner と OVH のどちらが最適な VPS か尋ねました。

別のコメント投稿者は、環境変数というパターン自体に反対し、コードと一緒に git でシークレットをバージョン管理するオープンソースの組み込みシークレットストアを宣伝しました。Rust、Go、PHP、Python、JS/TS、C#/.NET、PowerShell、bash で利用可能です。

Railway ユーザーにとっての実際の現状

スレッドで議論された時点での状況は次のとおりです。ビルドが一時停止されているため、影響を受けるアカウントではローテーションした認証情報を反映するための再デプロイは不可能です。OpenRouter を含む上流プロバイダーはキーを事前に無効化したと報告されています。Railway は確認された影響を受けるアカウントにメールを送信すると述べました。

開示とスレッドから直接導き出される手順：

Railway の環境変数に保存されているすべてのシークレットを潜在的に侵害されたものとして扱います。データベース認証情報、バケット認証情報、プライベートレジストリの認証情報、API キーを含みます。
プロバイダーのダッシュボードとサービスのログで不正使用を確認します。複数のコメント投稿者は、自社のアプリケーションログではなく、プロバイダーのダッシュボードで使用の証拠を見つけました。
ローテーション後に再デプロイする必要があるため、ビルドが一時停止されている間は継続的なダウンタイムを予想します。復旧については status.railway.com のインシデント QH8L8B3E を確認してください。
Railway の監査ログで、プロジェクトに対するスタッフ主導の認証情報再生成イベントを確認します。

未回答のままの質問

開示とスレッドはいくつかの質問を未解決のままにしており、資料内のどの情報源もそれらを解決していません：

暗号化された環境変数がどのように復号されたか、そして暗号化キー自体が取得されたかどうか。
影響を受けたアカウントの正確な数または割合。
ビルドがいつ再開されるか。
侵害された API キーが攻撃者によってどのように現金化されているか。
Railway がビルド復旧時に顧客のサービスを自動的に再デプロイするかどうか。あるコメント投稿者はそれを明確に望んでいましたが、結果をテストしていないことを心配していました。

あるコメント投稿者の実際的な計算の要約がスレッドの雰囲気を捉えています。デプロイが一時停止されている中で、「どちらが悪いか：盗まれたキーか、壊れた製品か？」