PaaSのRailwayに侵入 環境変数の秘密が読まれた恐れ 全部の更新を

アプリをコンテナで動かす実行基盤(PaaS)のRailwayは、米国時間2026年10月21日(日本時間22日6時59分ごろ)、顧客の環境変数を保存する仕組みで不審な動きを見つけたと公表しました。これまでの調べでは、許可のない第三者が暗号化された環境変数に触れ、その一部は復号した中身まで得た可能性があるとしています。

環境変数には、APIキー、データベースやレジストリの認証情報などの秘密の情報が入ります。Railwayは、影響は一部の利用者に限られる見込みとしつつ、念のため全員に、Railwayに置いた環境変数をすべて更新し、つないだサービスのログで不審な動きを確かめるよう強く勧めています。

発表で分かっていること

The Hacker Newsは、研究者の指摘として、Railwayに秘密鍵を置いていた暗号資産のウォレットから資金が抜かれたと報じています。Railwayの告知には、この点は書かれていません。

経過

状況ページの「Railway Platform Outage」の更新を、日本時間で並べます。この障害のページに、セキュリティの告知も載りました。

Railwayが代わりに無効にしたもの

Railwayは、さらされた認証情報をできるだけ早く使えなくするため、一部を自社で無効にしました。その分、利用者の側で再デプロイやつなぎ直しが要ります。

• バケットの認証情報: すべての環境のすべてのバケットのACCESS_KEY_IDとSECRET_ACCESS_KEYを無効にし、作り直した。バケットの名前や中身は変わらない。新しい値は、それを読むサービスを再デプロイすると入る
• GitHubのトークン: Railwayが預かっていたGitHubのアカウントの連携のトークンを無効にし、サービスにレジストリ用に置かれていたGitHubのトークンをRailwayから消した。消されたトークンは、GitHubの側で取り消すまで使える
• RailwayのAPIトークン: すべて無効にした。公開APIで連携している仕組みは、新しいトークンを作るまで動かない

これらの操作は、ワークスペースの監査ログに、Railwayの社員による操作として記録されます。監査ログを残す期間は契約の種類で違うため、Railwayは、自社の記録に要る分を書き出しておくよう勧めています。

利用者が自分で更新するもの

Railwayのガイドで、とくに大事な点は次のとおりです。

• コンテナは起動のときにだけ環境変数を読む。 値を変えても、使うサービスを再デプロイするまで古い値で動く
• データベースのパスワードは「Regenerate」で作り直す。 PostgreSQLのガイドでは、漏れた疑いがあるなら、止まる時間より古い認証情報を断つことを優先するとしている。パスワードを手で書き換えると、データベースと変数がずれる
• 外から届くデータベースは閉じる。 公開のアクセス(Public Access)が有効だと、作り直すまで、その認証情報はインターネットのどこからでも使える。外から要らなければ止める
• 接続の文字列を貼り付けた場所も直す。 参照の変数で書いたサービスは再デプロイで新しい値が入るが、値を貼り付けたサービスや、手元の開発環境、CI、BIのツールなどは手で直す

影響する会社・しない会社

• 影響する: Railwayでアプリやデータベースを動かしている会社。影響が一部の利用者に限られるかは調べている途中で、Railwayは全員に環境変数の更新を求めています
• 影響する: Railwayに置いた環境変数で、外部のサービス(AIのAPI、決済、AWS・GCP、GitHub、データベースなど)につないでいる会社。鍵が読まれていれば、外部のサービスの側で使われるおそれがあります
• 確かめる: 自社では使っていなくても、開発を任せた会社や、社内のチームの試作がRailwayで動いていないか。外部に任せた開発では、契約の窓口から確かめます
• 影響しない: Railwayを使っておらず、Railwayに鍵を置いていない会社

情シスが今日やること

1. Railwayを使っているかを洗い出します。 開発の部門、外部の制作会社、試作の環境も含め、Railwayのワークスペースと、そこに置いた環境変数の一覧を作ります。
2. 外部のサービスの鍵を、提供元の側で止めて作り直します。 決済、クラウド、AIのAPI、GitHubなどの鍵は、Railwayの再開を待たずに、提供元の管理画面で取り消せます。動いているアプリが止まる影響と、鍵が使われ続ける危険を比べ、決済やクラウドの管理者の鍵など重いものから順に進めます。
3. 監査ログを先に書き出します。 Railwayのワークスペースの監査ログ、GitHubの個人の安全のログ(90日分)と組織の監査ログ(180日分)、AIのAPIの利用量、Stripe、AWS・GCPのログを、鍵を消す前に書き出して残します。GitHubでは、見覚えのないOAuthアプリ、SSHの鍵、個人用のアクセストークン、デプロイの鍵、Webhookを確かめます。
4. データベースのパスワードを作り直し、外からの接続を閉じます。 RailwayのデータベースはRegenerateで作り直し、要らない公開のアクセスを止めます。
5. ビルドが戻ったら再デプロイします。 22日20時の時点で、Hobby・Free・Trialではビルドが戻っていません。戻ったら、新しい値を読ませるため、関係するサービスを再デプロイします。同じデプロイを何度も起こさないようにします。
6. Railwayからのメールを確かめます。 影響を受けたアカウントには、Railwayからメールで詳しい連絡が来ます。管理者のアドレスに届くメールを見落とさないようにします。

AIのAPIの鍵が盗まれ、請求だけが利用者に回る手口は、ほかのクラウドでも報告されています(Wiz、クラウド請求を狙う攻撃を分析 Gemini無断利用の確認点)。