対象：Trigger.devでタスクやジョブを動かし、APIキー、データベースの接続情報、クラウドの認証情報などを環境に置いている開発者・チーム。本記事はTrigger.devのブログ、報告、ステータスページにもとづく解説で、攻撃手順は扱いません。
続報が出ました：本記事は新しい発表に合わせて更新します
- 対象者
Trigger.devでタスクやジョブを動かし、APIキー、データベースの接続情報、クラウドの認証情報などを環境に置いている開発者・チーム。
- 影響が確認された範囲表で見る ↓
- 影響を受けた顧客の割合
- ルートAPIキー
- 環境変数
さらに1件
- 実行・デプロイ・スケジュールの一覧とメタデータ
- 未確認事項
- 攻撃の経路（同社は調査と顧客保護のため非公表）
- 不正アクセスの開始時期と期間
- 影響を受けた顧客の実数
さらに1件
- 取得された情報が実際に悪用されたか
- 今やること手順を見る ↓
- 通知を確認する。メールとダッシュボードのバナーの両方を見る
- 対象なら、Trigger.devのAPIキーを再発行する
- 対象なら、環境にあった認証情報を差し替える
さらに3件
- 発行元の利用状況、ログ、請求を確認する
- 新しい値で再デプロイし、タスクが動くか確かめる
- 支出上限を設定し、キーを小さく分ける
- 確認先（出典）出典の一覧 ↓
- Trigger.dev, ブログ「インシデント報告」（2026年11月6日）— trigger.dev/blog/security-incident-report-nov-2026
- 最終確認日時
- 2026年11月7日（日本時間）時点
発表の続報予定と確認の記録
同社は11月6日に報告を公表しました。攻撃者の遮断、影響の割合、取得された情報、顧客がやることが書かれています。攻撃の経路は、責任をもって公表できる段階になれば共有するとしています。2026年11月7日（日本時間）に確認した時点で、これ以上の続報は見当たりませんでした。
Trigger.devの利用者が今日やること
通知を確認する。メールとダッシュボードのバナーの両方を見る
同社の説明では、対象の顧客には11月1日（約21:36 UTC）と11月2日（20:27 UTC）にメールが送られ、ダッシュボードに通知のバナーが出ています。まず、自分の組織の所有者が受け取っているか、受信箱と迷惑メールのフォルダを含めて確認し、ダッシュボードにバナーが出ていないかも見てください。
同社は、通知を受けていない顧客は影響を受けていないと説明しています。確信が持てない場合は、アカウントのメールアドレスから同社のサポート（help@trigger.dev）に問い合わせるよう案内されています。この件のサポートは優先して対応されるとのことです。
対象なら、Trigger.devのAPIキーを再発行する
同社は、攻撃者がルートAPIキーを入手したため、影響した可能性のある、対象環境のAPIキーを失効させたと書いています。再発行の手順は、対象の顧客にメールで送られています。CIやアプリで古いキーを使っている場合は、新しいキーに置き換えてください。
同社は、スコープ付きAPIキーのIPアドレス制限とOIDCのサポートを公開しています。再発行の際に、使えるなら取り入れてください。
対象なら、環境にあった認証情報を差し替える
影響を受けた環境にある、データベースのパスワード、サードパーティのAPIキー、アクセストークンなどが対象です。手順は、先に発行元（AI事業者、クラウド、データベース、決済、メールなど）で古い認証情報を失効させ、新しい値を作ってTrigger.devに設定し、再デプロイします。Trigger.dev上で変数を書き換えたり消したりしても、すでに誰かが持っている写しは止まりません。
同社の説明では、環境変数は保存時に暗号化され、実行時に（just-in-timeで）復号されます。ただし、ルートAPIキーは環境変数を含む環境の設定への完全なアクセスを与えるため、対象の環境のものは取られたものとして扱うのが安全です。
発行元の利用状況、ログ、請求を確認する
同社は不正アクセスの開始時期を、確認した範囲では書いていません。そのため、当サイトの目安として、少なくとも10月下旬以降まで期間を広めにとってください。発行元ごとに、利用状況、アクセスログ、キーの一覧、請求画面で、身に覚えのないリクエスト、普段と違うモデルやリージョン、急な費用増を探します。
データベースは、見慣れない接続元や、普段動かさない処理がないかも確認します。不審な利用が見つかったら、発行元に報告し、その環境のほかの秘密も差し替えます。
新しい値で再デプロイし、タスクが動くか確かめる
差し替えた値を設定したら再デプロイし、実行中・スケジュールされたタスクが新しい値で動くかを確認します。古いキーを失効させているため、設定漏れがあるとタスクが失敗します。失敗したタスクは、どの変数が古いままかを手がかりに直します。
支出上限を設定し、キーを小さく分ける
AI事業者やクラウドで、月の予算上限とアラートを設定します。キーは用途を1つに絞って最小の権限にし、アプリごと・環境ごとに分けます。小さいキーほど、漏れたときの被害も小さく済みます。キーをコードやログに出さない基本は.envとAPIキーの本当に危ないところにあります。
何が起きたのか（Trigger.devの発表より）
以下は、同社の11月6日の報告と、11月1日のブログ、ステータスページにもとづきます。11月6日の報告は、最初の発表の続報として出されました。
11月1日
同社がインシデントを認知。インフラのアラートが異常な動きを検知し、悪意あるものと判断して攻撃者を遮断し、攻撃の経路を緩和した。ブログで最初の発表。11月1日 約21:36 UTC
対象の顧客への最初のメール。11月1日 22:50 UTC
ステータスページに同名の記録が作成される。11月2日 20:27 UTC
対象の顧客への2回目のメール。11月6日 12:27 UTC
ステータスページの記録が「Resolved（解決済み）」になり、11月6日の報告へのリンクが載る。11月6日
同社が詳しい報告を公表。影響は全顧客の0.66%、ルートAPIキーの入手、取得された情報、顧客がやることを説明。11月7日
当サイトが確認。これ以上の続報は見当たらない。
同社が書いていること
全顧客の0.66%。ルートAPIキーの入手、環境変数への不正アクセス、実行・デプロイ・スケジュールの情報の取得
書かれていないこと
攻撃の経路（非公表）、開始時期、顧客の実数、悪用の有無
対象なら、APIキーを再発行し、環境の認証情報を発行元で失効させて差し替えます。
- 影響
- 全顧客の0.66%。攻撃者が一部の顧客環境のルートAPIキーを入手し、環境変数に不正アクセス
- 取得された情報
- 一部の環境で、直近の実行・デプロイ・スケジュールの一覧。ID、タスク名、実行の冪等性キー、状態、タグ、デプロイのメタデータとエラー、スケジュールの外部ID、実行のメタデータ
- 確認されなかったこと
- ほかの顧客データ、他のサービス、同社の本番データベース、ダッシュボードのアカウントにアクセスされた証拠は見つかっていない（同社）
- 同社の対応
- 攻撃者の遮断と経路の緩和、内部の認証情報の予防的な差し替え、ログの確認、対象の顧客への通知、影響した可能性のあるAPIキーの失効、リスクに応じたアカウントの自動制限、インシデント対応の専門家の起用、法執行機関への通報
- 未公表
- 攻撃の経路（調査と顧客保護のため）、開始時期、顧客の実数、悪用の有無
分かっていること・分かっていないこと
2026年11月7日（日本時間）時点の状態です。「記載なし」は、確認した同社の報告に書かれていない項目で、安全と確認されたという意味ではありません。
| 項目 | 同社の発表の内容 | 状態 |
|---|---|---|
| 影響を受けた顧客の割合 | 全顧客の0.66% | 確定（同社） |
| ルートAPIキー | 一部の顧客環境のものを攻撃者が入手 | 漏えいを確認（同社） |
| 環境変数 | 攻撃者が不正アクセス | 影響対象（同社） |
| 実行・デプロイ・スケジュールの一覧とメタデータ | 一部の環境で取得された | 漏えいを確認（同社） |
| ほかの顧客データ、他のサービス、同社の本番データベース、ダッシュボードのアカウント | アクセスされた証拠は見つかっていない | 確認されていない（同社） |
| Webhookの署名用の秘密 | 露出していない | 含まれない（同社） |
| セルフホストの利用者 | 影響を受けていない | 含まれない（同社） |
| 通知を受けていない顧客 | 影響を受けていない | 同社の説明 |
| 攻撃の経路 | 調査と顧客保護のため非公表。責任をもって公表できる段階で共有するとする | 調査中（同社が非公表） |
| 不正アクセスの開始時期と期間 | 確認した範囲では書かれていない | 記載なし |
| 影響を受けた顧客の実数 | 割合のみ（0.66%） | 記載なし |
| 取得された情報の悪用 | 書かれていない | 記載なし |
読み方：「環境変数の中身が使われたか」はまだ分からない
同社は、取られた情報と、アクセスされた証拠のない範囲を分けて書いています。一方で、環境変数に置いていた認証情報が実際に使われたかは書かれていません。対象の顧客は、使われていないことが確認できるまで待たず、先に発行元で失効させてください。
環境変数が漏れると何が起きうるか
一般に、環境変数から取られた秘密は次のように悪用されえます。今回これらが起きたという意味ではありません。
- AIサービスのAPIキー：他人があなたのアカウントでリクエストを送り、請求があなたに届く。キーが転売されることもある
- データベースのパスワードと接続文字列：アプリのデータ（自分の利用者の情報を含む）の読み取りや書き換え
- クラウドや決済のキー：費用のかかるリソース作成や、外部サービスの呼び出し
- 署名鍵：偽のリクエストの受け入れや、セッションの偽造
また、今回取得された実行やデプロイのメタデータ（タスク名、タグ、エラーなど）は、そのものが秘密ではなくても、どのサービスをどう使っているかの手がかりになります。そこから、狙いを絞った偽の連絡が作られることがあります。
バックグラウンドジョブの基盤は、処理に必要な外部サービスの認証情報をまとめて預かる性質があります。そのため、1つの基盤の環境変数が見られると、複数のサービスの鍵が同時に危うくなります。同様に環境変数・秘密が関わる事例はNorthflank、Zeabur、Railwayを参照してください。それぞれ別の事案で、同じ原因と確認されたわけではありません。
運営者が見直すこと：同社が公表した経緯から
同社が公表した事実から言えることです。Trigger.devへのさらなる評価ではありません。
- ルートに近いキーは、環境の設定全体に届く。 今回、ルートAPIキーの入手が、環境変数への到達につながったと同社は説明している。基盤のキーは用途ごとに分け、IPアドレス制限やOIDCなど、同社が公開した絞り込みの手段を使えるなら使う。
- 通知はメールとダッシュボードの両方に出る。 組織の所有者のメールアドレスを、個人が退職しても届く共有の窓口にし、迷惑メールに振り分けられないようにしておく。ダッシュボードのバナーも定期的に見る。
- 基盤に預けた秘密は、すぐに差し替えられる形にしておく。 発行元ごとに失効と再発行の手順を決め、環境ごと・用途ごとにキーを分けておくと、知らせの当日に動ける。
- 環境変数に置く秘密は、必要最小限の権限にする。 基盤側で変数が見られたとき、被害の大きさは、そのキーが何をできるかで決まる。
出典（公開情報）
本記事の事実は以下の公開情報にもとづきます。同社が公表していない攻撃の経路や原因は推測せず、載せていません。
- Trigger.dev, ブログ「インシデント報告」（2026年11月6日）— trigger.dev/blog/security-incident-report-nov-2026
- Trigger.dev, ブログ "Security Disclosure: Sunday November 1st"（2026年11月1日）— trigger.dev/blog/security-incident-nov-2026
- Trigger.dev, ステータスページ "Security Disclosure: Sunday November 1st"（2026年11月1日22:50 UTC作成、11月6日12:27 UTCに解決済み。11月6日の報告へのリンクあり）— status.trigger.dev/incident/1110434
更新履歴
2026-11-07：Trigger.devの11月6日の報告を反映し、影響は全顧客の0.66%、攻撃者がルートAPIキーと環境変数を取得、実行・デプロイ・スケジュールの情報も取得、攻撃の経路は非公表であることを追記した。対象かどうかの確認方法（メールとダッシュボードのバナー）と、APIキーの再発行・環境の認証情報の差し替えを手順の中心に改め、Webhook署名の秘密は露出なし、セルフホストは影響なしを加えた。 2026-11-05：初版。2026年11月5日時点のTrigger.devのブログとステータスページにもとづく。
次に読む
- 同様に環境変数・秘密が関わる事案：Northflankのセキュリティインシデント／Railwayの環境変数が漏れた可能性／Zeaburのセキュリティインシデント
- 開発者向け基盤の新しい事案：Chainstackの本番環境への不正アクセス／OpenCode Consoleの漏えい
- 鍵を守る基本：.envとAPIキーの本当に危ないところ／APIキー盗難とアカウント停止
- 2026年のほかの事件：2026年の情報漏えい・サイバー攻撃