Railwayの環境変数が漏えいした可能性（2026年10月、最大1.85%のワークスペース）：入れ替える秘密と、利用者がやること

同社は、10月21日より前にRailwayに保存した機微な環境変数を、すべて失効させて設定し直すよう求めています。APIキーのほか、非公開のレジストリの認証情報も対象です。

入れ替えの順番は次のとおりです。

• 環境変数の一覧を作る。各サービスの「Variables」を開き、秘密の値（APIキー、トークン、パスワード、署名の鍵、接続文字列）に印を付ける
• 発行元（AIのAPI、決済、GitHub、クラウド、外部のデータベースなど）の管理画面で、新しい値を発行する
• Railwayの変数を新しい値に書き換え、サービスを再デプロイする。コンテナは起動時にしか変数を読まないため、再デプロイするまで古い値のまま動く（同社の手順）
• 新しい値で動いたことを確かめてから、発行元で古い値を無効化・削除する

Railwayの中だけで値を書き換えても、発行元で古い値を無効にしなければ、漏れた値は使えるままです（当サイトの補足）。

同社は、すべての利用者に、データベースへの公開のネットワークアクセスを外すよう勧めています。同社の手順によれば、公開アクセス（TCPプロキシ）が有効なデータベースは、パスワードを変えるまでインターネットのどこからでもその認証情報で接続できます。

• PostgreSQL・MySQL・Redis・MongoDBは、データベースの画面の「Regenerate」でパスワードを再生成する。データベース内のパスワードと変数が一度に変わり、開いている接続も切れる（同社の手順）
• パスワードの変数（POSTGRES_PASSWORD など）を手で書き換えたり、データベースで直接パスワードを変えたりしない。変数とデータベースの値がずれる（同社の手順）
• 変数を参照（${{ Postgres.DATABASE_URL }} のような書き方）しているサービスをすべて再デプロイする。接続文字列を直接貼っているサービスは、参照に置き換える
• 「Settings」の「Networking」で、外から使っていないなら「Public Access」を外す。手元のPCやCI、BIツールなど外から使っている場合は、新しい DATABASE_PUBLIC_URL を手で設定し直す

同社は、GitHubの監査ログとアプリのアクセスの見直し、Docker Hubなどのレジストリの監査ログの確認を勧めています。同社の手順で挙げられている確認先は次のとおりです。

• 個人のアカウント：GitHubのセキュリティログ（90日分）、認可したOAuthアプリとGitHub App、SSHとGPGの鍵、個人用アクセストークン。見覚えのないものは取り消し、トークンは作り直す
• 組織：組織の監査ログ（180日分）。取り消す前に記録を書き出しておく。リポジトリごとにデプロイキー、Secrets、Webhook、共同作業者を確かめる
• GitHubのコンテナレジストリ（ghcr.io）：Railwayは保存していたGitHubのトークンを削除したが、GitHub側ではそのトークンは失効するまで使える。GitHubで古いトークンを削除し、read:packages の権限で作り直して、各サービスに設定し直す

同社の手順には、攻撃者は押し込める権限があれば、パスワードを変えても残るWebhookや秘密を足せる、という注意もあります。

同社の予備報告によれば、攻撃者はAIプロバイダのAPIキーを探していたとみられます。同社はOpenAI、Anthropic、OpenRouter、Grok、Stripe、AWS、GCPについて、利用状況の確かめ方の手順を公開しています。OpenAIの手順の例は次のとおりです。

• 漏れた可能性のあるキーを削除し、同じプロジェクトで新しいキーを作る
• 利用量の画面をキーごとに分けて見て、期間中のトークン数・リクエスト数・使われたモデルを普段と比べる
• 請求の画面で、期間中の支出と、使われたクレジットを見る
• メンバーとプロジェクトに、招いていない人がいないか確かめる
• 不審な利用があれば、記録を残してプロバイダのサポートに連絡する

確かめる期間は、少なくとも攻撃の期間（10月20日夜〜22日昼、日本時間）以降、キーを入れ替えるまでです（当サイトの補足）。

同社は対応の中で、すべてのログインのセッション、Railwayのアクセストークン、GitHubとの接続、ストレージのバケットの認証情報を無効にしました。止まっていた間に押したコミットはデプロイされていません。

• 最初に登録したのと同じGmail・GitHub・メールアドレスでログインし直す。違う身元でログインすると、空の新しいアカウントができる（同社の手順）
• アカウントの設定でGitHubを接続し直し、サービスの「Settings」でリポジトリをつなぎ直してから、最新のコミットをデプロイする
• CLIは railway logout のあと railway login。CIは、プロジェクトのトークン（RAILWAY_TOKEN）またはアカウント・ワークスペースのトークン（RAILWAY_API_TOKEN）を作り直し、CIの秘密を置き換える
• バケットを使うサービスは再デプロイして、新しい認証情報を読み込ませる。バケットに見覚えのないファイルや、消えたファイルがないかも確かめる（バケットに自動のバックアップはない、と同社）
• ワークスペースの監査ログで、期間中の変数の読み取り、レジストリの認証情報の変更、デプロイのうち、自分たちとRailwayの担当者（「Railway Staff」と表示）以外の操作がないか確かめる

同社の環境変数は暗号化されていましたが、予備報告によれば、攻撃者は侵害された認証情報を組み合わせて一部を復号しました。実行基盤は、アプリを動かすときに変数を元の値に戻す必要があるため、基盤の中の権限を取られると、暗号化だけでは守り切れません（当サイトの補足）。

基盤側の暗号化とは別に、漏れても被害が小さい形で秘密を置きます。最初の1つとしては、AIのAPIと決済のキーについて、プロバイダ側で利用額の上限と通知を設定してください。キーを本番・検証・開発で分けておくと、入れ替えの範囲も小さくなります。秘密の置き方は .envとAPIキーは何が危ないのか にまとめています。

同社の手順によれば、公開アクセスが有効なデータベースは、漏れた接続文字列でインターネットのどこからでも接続できます。プロジェクトの中のプライベートネットワークだけで使うなら、接続文字列が漏れても、外から直接は使えません。

外から使う必要があるのは、手元での開発、CI、BIツールなどに限られることが多いはずです。その場合も、使う間だけ公開する、読み取り専用のユーザーを分ける、のどちらかを検討してください（当サイトの補足）。

同社の手順は、接続文字列や鍵を各サービスに直接貼るのではなく、${{ Postgres.DATABASE_URL }} のような参照の変数で配ることを勧めています。参照なら、元の値を変えて再デプロイするだけで全サービスに届き、貼り付けた値の変え忘れが起きません。

同じ考え方で、どの秘密をどのサービスが使い、どの発行元で作り直すかの一覧を、普段から持っておきます（当サイトの補足）。今回のように「すべて入れ替える」ことになったとき、一覧があるかどうかで作業の時間が大きく変わります。似た事案として Vercelのセキュリティインシデント では、値を後から表示できない区分で保存していたかどうかが分かれ目になりました。

同社は今回、Railwayが持っていたGitHubのトークンを無効にし、GitHubの監査ログとアプリのアクセスの見直しを勧めています。実行基盤に渡すGitHubの権限は、デプロイするリポジトリだけに絞り、コンテナレジストリ用のトークンは読み取り（read:packages）だけにしておくと、漏れたときの範囲が小さくなります（当サイトの補足）。漏れた認証情報が無効にされないまま残る問題は 漏れた認証情報が有効なまま残る問題 にまとめています。