Railwayのセキュリティ事故（2026年10月21日）｜作り直す鍵の一覧、バケットの再デプロイとGitHubのつなぎ直し

Railwayで動かしているアプリは、メールが来ていなくても、環境変数に入れているAPIキー・データベースのパスワード・レジストリの認証情報をすべて作り直してください。Railwayは2026年10月21日付の公式ブログで、顧客の環境変数を置いている仕組みに第三者がアクセスしたおそれがあり、一部は中身を読まれたおそれがあると公表し、全員に作り直しを勧めています。

結論：全員が鍵を作り直す。バケットとGitHubは再デプロイとつなぎ直しが要る

• 何が起きたか：顧客の環境変数を置いている仕組みで、Railwayが不審な動きを見つけました。暗号化された環境変数にアクセスされ、その一部は復号された中身まで取られたおそれがあります
• だれが対象か：Railwayは「影響は一部の利用者にとどまる可能性がある」としながら、念のため全員に対応を勧めています。影響を受けたと分かったアカウントには、Railwayからメールで連絡が来ます
• やること：Railwayに置いている環境変数（APIキーを含む）と、プライベートレジストリの認証情報をすべて作り直し、それらのサービスのログに不審な動きがないかを見ます
• いつまでに：Railwayは、すぐに作り直すよう強く勧めています
• Railwayが先に無効にしたもの：ストレージバケットのS3の鍵、RailwayがあずかっていたGitHubのトークン、Railway APIのトークン。Railwayの中では古い値はもう使えません。ただし、ghcr.io用に登録していたGitHubの個人用アクセストークンは、Railwayから消されただけでGitHub側ではまだ使えるので、自分で消します
• ビルド：一時止まっていましたが、日本時間10月23日8時22分の時点で、Enterprise・Pro・Hobby・Trial・Freeのすべてのプランでビルドとデプロイが引き続きほぼふだんの速さで動いています。新規の登録は一時止まったままです

何が起きたか（Railwayの公式発表）

Railwayの公式ブログ「Security Disclosure: Wednesday October 21st」によると、Railwayは顧客の環境変数を置いている仕組みで不審な動きを見つけました。調べた結果、権限のない第三者が暗号化された環境変数にアクセスし、その一部では復号された中身を手に入れたおそれがある、としています。環境変数にはAPIキーやデータベース・レジストリの認証情報が入っていることがあります。

Railwayは、これを「AI推論のサービスを提供する会社をねらって、プラットフォームの会社を最近つづけて攻撃している一連の攻撃の一部」と見ています。そのため、その攻撃の先にいるAI推論の会社に連絡し、すべての鍵を先回りして無効にするよう伝えた、と書いています。

状況はRailwayのステータスページ（status.railway.com）で更新されています。おもな流れは次のとおりです（時刻は日本時間に直したもの）。

Railwayは、この件が解決したら詳しい報告をブログに出し、ステータスページからリンクするとしています。

自分のアプリで作り直すものの一覧

Railwayは全員に、Railwayに置いている環境変数をすべて作り直すよう勧めています。自分のプロジェクトに当てはまるものを、次の表で確かめてください。

データベースのガイドは、Railwayのテンプレートで作ったデータベース向けです。テンプレートを使わずに立てたデータベースも、Railwayの変数に入れたパスワードは作り直しの対象です。そのデータベースのやり方でパスワードを変え、Railwayの変数を書き換えて再デプロイします。

コンテナが変数を読むのは起動したときだけなので、変数を変えたサービスは再デプロイして初めて新しい値を使います。

外部サービスの鍵を作り直す（AWSの例）

Railwayは、AWSのアクセスキーについて次の手順を出しています。古い鍵は無効にするまで使えます。新しい鍵を作ったら、古い鍵は消すのではなく、まず無効にします。

1. IAMコンソールで漏れたおそれのあるアクセスキーIDを探し、そのユーザーの「Security credentials」で新しいアクセスキーを作る
2. 古いキーを「Deactivate」（無効）にする。消すのではなく無効にしておくと、忘れていたサービスが止まったときに一時的に戻せる
3. Railwayでそのキーを使うサービスの「Variables」を開き、AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY を新しい値に変えてデプロイする。共有の変数ならProject Settingsで1回変えればよい
4. 新しいデプロイのログで、InvalidClientTokenId や SignatureDoesNotMatch のエラーが出ていないことを確かめる
5. 手元の開発環境やCIなど、Railwayの外で古いキーを使っている場所も新しい値に変える

使われていないかは、CloudTrailのEvent historyでそのキーのIDを入れて調べます。イベントの履歴はリージョンごとなので、すべてのリージョンで探すよう書かれています。Cost Explorerで前の月と比べ、覚えのない請求がないかも見ます。

RailwayはAWSのほかにも、OpenAI・Anthropic・Grok・OpenRouter・Stripe・GCP・GitHubの使われ方の確かめ方や、PostgreSQL・MySQL・MongoDB・Redisのパスワードの作り直し方のガイドを、エンジニアリングブログ（blog.railway.com/engineering）に出しています。AIのAPIキーの作り直し方と利用上限の設定は、OpenCodeでAPIキー漏えいの可能性｜OpenAI・Anthropic・Googleのキーを無効化して作り直す手順でもふれています。

RailwayのPostgreSQLのパスワードを作り直す

RailwayのPostgreSQLのテンプレートを使っている場合、データベースの画面の「Regenerate」を使います。PostgreSQLの中のパスワードと、サービスの変数がいっしょに変わります。

1. PostgreSQLのサービスを開き、「Database」タブの「Config」を開く
2. 「Connection」の欄で、パスワードの横の「Regenerate」を押す。POSTGRES_PASSWORD が変わり、それを参照している PGPASSWORD・DATABASE_URL・DATABASE_PUBLIC_URL も変わる
3. データベースが再起動し、開いていた接続はすべて切れる
4. PostgreSQLの変数を参照しているサービスを、すべて再デプロイする

Railwayは、POSTGRES_PASSWORD や PGPASSWORD を手で書き換えたり、自分で ALTER USER を実行したりしないよう書いています。片方だけが変わり、変数とデータベースの中身がずれるためです。漏れたおそれがあるときは、サービスが再デプロイまで少し止まっても、先に古いパスワードを切ることを優先するよう勧めています。

CLIから1つのサービスを再デプロイするときは次のとおりです（backendは自分のサービス名に変えます）。

railway redeploy --service backend

作り直したあとは、新しいパスワードでつなぎ、今ある接続を一覧にします。再起動で古い接続はすべて切れているので、覚えのない接続があれば、新しいパスワードがどこから使われたかを調べます。

railway connect Postgres

SELECT pid, usename, client_addr, application_name, backend_start, state
FROM pg_stat_activity
WHERE datname = current_database();

「Settings」の「Networking」でPublic Accessがオンになっていると、作り直すまで古いパスワードはインターネットのどこからでも使えます。プロジェクトの外から使っていなければ、オフにするよう書かれています。

ストレージバケットを使うサービスを再デプロイする

Railwayは、すべての環境のすべてのバケットについて、ACCESS_KEY_ID と SECRET_ACCESS_KEY を無効にして作り直しました。バケットの名前・エンドポイント・中のファイルは変わっていません。新しい鍵はバケットの側にはもう入っているので、あとはバケットを使うサービスが次のデプロイで読み込みます。

1. バケットを開き「Credentials」で新しい ACCESS_KEY_ID を見る。環境ごとに別の鍵なので、使っている環境をそれぞれ見る
2. サービスの「Variables」で、${{ my-bucket.SECRET_ACCESS_KEY }} のような参照や、AWS_SECRET_ACCESS_KEY などRailwayが入れた変数があるサービスを探す
3. そのサービスを再デプロイする。画面なら最新のデプロイのメニューから「Redeploy」
4. 古い鍵を参照ではなく値として貼り付けていたサービスは、参照に置き換えてからデプロイする。次に鍵を変えたときに手で直さなくてよくなる
5. 手元の開発環境・CI・S3のファイル管理ツールなど、Railwayの外で使っていた鍵も新しい値に変える

CLIでは、サービスの再デプロイと、新しい鍵の表示を次のように行います（uploads-apiとmy-bucketは自分の名前に変えます）。

railway redeploy --service uploads-api

railway bucket credentials --bucket my-bucket

再デプロイしたサービスがファイルの一覧や書き込みをできるか確かめます。まだ InvalidAccessKeyId や SignatureDoesNotMatch が出るなら、古いデプロイのまま動いているか、古い値を貼り付けたままです。バケットには自動のバックアップがないので、「Files」で覚えのないファイルや、消した覚えのないファイルがないかも見ておきます。

GitHubをつなぎ直す

RailwayはあずかっていたGitHubのトークンを無効にしたので、GitHubからのデプロイと、ghcr.ioのプライベートイメージの取得は、つなぎ直すまで止まります。Railwayは新しいGitHubのトークンを代わりに作れないので、自分でつなぎ直します。

GitHubのアカウントをつなぎ直す

1. Account SettingsでGitHubのアカウントをつなぎ直す
2. github.com/apps/railway-app で、Railway GitHub Appがデプロイするリポジトリにアクセスできるかを確かめ、権限の更新が待っていれば承認する
3. リポジトリからデプロイしている各サービスの「Settings」の「Source」で、リポジトリとブランチがつながっているかを確かめる。切れていれば「Disconnect」のあと「Connect Repo」で選び直す
4. 「Settings」で自動デプロイがオンかを確かめ、オフなら「Enable」を押す
5. コミットをpushするか、コマンドパレットの「Deploy Latest Commit」で、デプロイが動くかを確かめる

ghcr.ioのトークンを入れ替える

RailwayはGitHubの個人用アクセストークンをRailwayから消しましたが、そのトークンはGitHubではまだ使えます。トークンそのものが漏れたおそれがあるので、GitHub側でも消します。

1. GitHubの「Personal access tokens」で古いトークンを消し、read:packages の権限で新しいトークンを作る
2. Railwayでサービスの「Settings」の「Source」にある「Registry Credentials」を開き、「GitHub Access Token」に新しいトークンを入れて保存する
3. サービスを再デプロイする。登録はサービスごとなので、ghcr.ioから取っているサービスすべてで行う

プライベートレジストリの認証情報を使えるのは、Proプランからです。

GitHubの個人のセキュリティログ（90日分）や、組織の監査ログ（180日分）で、覚えのないOAuthアプリ・SSHキー・トークン・Webhookがないかも見るよう、Railwayはガイドで勧めています。組織の監査ログは、何かを取り消す前にJSONかCSVで書き出しておくよう書かれています。

Railway APIやCLIのトークンを作り直す

Railwayは、事故より前に作られたAPIトークンとプロジェクトトークンを無効にしました。RailwayのPublic APIやCLIをトークンで使っている場合は、新しいトークンを作って入れ替えます。

止まっていたデプロイはどうなるか

ステータスページによると、たまっていたデプロイは順に処理され、待っていたデプロイについては何もしなくてよいとしています。ただし、次の場合はやり直すよう書かれています。

• ビルドが始まってすぐ失敗したときは、1回だけやり直す
• US Westで、ビルドのあとにデプロイが失敗したサービスは、再デプロイする

待ちを増やさないよう、同じデプロイを何度も始めないようにとも書かれています。

使われていないかを確かめる

• Railwayの監査ログ（Audit Logs）で、変数の閲覧、レジストリの認証情報の変更、デプロイのうち、自分のチームでもRailway Staffでもないものがないかを見る。Railwayが代わりに行った作り直しは、Railway Staffとして名前つきで残っている
• 監査ログが残る期間はプランによるので、自分の記録に必要な分は書き出しておく
• 鍵を作り直した各サービス（AWS・OpenAI・Stripeなど）の側でも、覚えのない使われ方や請求がないかを見る

設定ファイルや環境変数の秘密の鍵が抜かれたときに確かめることは、アルカディア不正アクセスに学ぶ、設定ファイルの秘密の鍵が抜かれたときに今日確かめる6つのことにもあります。開発で使う道具から鍵が抜かれた別の例は、LiteLLM 1.107.0が改ざんされていた件です。

よくある質問

メールが来ていなければ何もしなくてよい？

いいえ。Railwayは、影響を受けたと確かめたアカウントにはメールで連絡するとしたうえで、全員に念のため鍵の作り直しを勧めています。

バケットの鍵は自分で作り直す必要がある？

いいえ。Railwayがすでに作り直しています。バケットを使うサービスを再デプロイし、Railwayの外で使っている鍵を新しい値に変えれば済みます。自分でもう一度作り直したいときは、次のコマンドで今の鍵を無効にし、新しい鍵を作れます。

railway bucket credentials --reset

監査ログに知らない名前で鍵の作り直しが出ている

Railwayは、バケットの鍵の作り直しを社員のFaraz Patankar氏が行い、監査ログには「Railway Staff」として名前つきで出ると説明しています。ステータスページでも、これは予定どおりの操作だと書かれています。

問い合わせ先は？

Railwayのガイドでは、support@railway.com が案内されています。

参考（一次情報）

• Railway Blog：Security Disclosure: Wednesday October 21st
• Railway Blog：Redeploy Buckets and Reconnect GitHub After the Credential Reset
• Railway Blog：Check for Anomalous AWS Access
• Railway Blog：Rotate PostgreSQL Database Credentials
• Railway Blog：Rotate MySQL Database Credentials
• Railway Blog：Rotate MongoDB Database Credentials
• Railway Blog：Rotate Redis Database Credentials
• Railway Blog：Check for Anomalous GitHub Access
• Railway Status：Railway Platform Outage