Dokployで組織をまたぐ認可不備｜最新版でも修正取り込みを確認

Dokployを複数組織で共有している運用者は、管理画面へのアクセス制限と、実行中の版への修正取り込みを優先して確認してください。CVE-2026-116068は、ある組織のowner/adminが別組織のアプリへ操作できる認可の不備です。対象は0.30.10までとされ、環境変数やビルド設定の書き換え、配備や停止などに影響します。

2026年10月25日公開のVulnCheckの告知はCVSS 4.0で8.7、深刻度Highと評価しています。一方、公開Issueは10月9日、開発元の修正コミットは10月22日です。CVE公開日と問題の初回公開日を混同せず、本稿は10月26日（日本時間）に確認した資料から、自己管理環境の防御判断を整理します。本サイトでは攻撃の再現実験を行っていません。

まず確認するのは組織の分け方と管理権限

DokployはDockerとTraefikを使うアプリ配備基盤です。公式のMulti-Tenancy資料では、Organizationの下にProject、Environment、Serviceを置き、所属と権限を階層で管理します。顧客ごと、チームごとに分けた組織は、画面の整理だけでなくアクセス制御の境界でもあります。

今回の攻撃条件は、認証済みの利用者がいずれかの組織でownerまたはadminであり、別組織の対象リソースIDを指定することです。ログイン不要で誰でも使える経路とは異なりますが、「管理者でなければ攻撃できないので問題は小さい」とも判断できません。自分の組織だけを管理する顧客へadminを渡している場合、その権限が共有インスタンス全体の信頼を意味していないからです。

• 複数の顧客・委託先を同じDokployへ収容し、それぞれへowner/adminを与えている環境は優先して点検する。
• 社内限定でも、組織ごとに運用者やデータの信頼範囲が異なるなら対象として扱う。
• 単一組織で信頼できる少人数だけが操作する環境は、今回の組織横断という条件を分けて評価する。
• 組織数だけで安全と決めず、利用者、招待、権限、管理APIへの到達経路を一覧にする。

認証が通ることと対象を操作できることは別

開発元リポジトリのIssue #5635によると、共通の権限チェックは呼び出し元のアクティブな組織でメンバー情報を取得していました。owner/adminではリソースごとのアクセス一覧の検査を省略し、操作対象が同じ組織に属するかを確認していなかったと報告されています。読み取りなど一部処理には個別の組織チェックがありましたが、同じルーターの更新処理すべてには及んでいませんでした。

このため、画面上で別組織のアプリが見えないことや、詳細取得が拒否されることだけでは防御を確認できません。表示と更新で別の認可経路を使うと、通常の画面操作では気付かないまま、更新APIだけが組織境界を越える可能性があります。運用者が確認すべきなのは、一覧の見え方よりも、実際の対象に対する操作の許可範囲です。

一般にIDを推測しにくくすることは探索を難しくしますが、認可の代わりにはなりません。ログや連携設定などからIDを知った場合にも拒否される必要があります。本件でも、IDの入手方法を一つに決めつけず、他組織のIDを知った利用者が操作できないことを安全性の条件にします。

最新安定版という表示だけで修正済みにしない

確認時点の公式リリースv0.30.10は、10月22日18時25分UTC、日本時間10月23日3時25分の公開です。VulnCheckはこの版を含めて影響対象としています。最新のリリースを使っているという理由だけで、今回の対応を完了にしないでください。

修正コミットb3cd3c5では、対象サービスから所属組織を調べ、呼び出し元のアクティブな組織と照合する処理が追加されています。owner/adminの分岐より前に照合し、存在しない対象と他組織の対象を拒否する構造です。プロジェクト作成に関係する検査も追加されており、単に特定の更新ボタンを隠す修正ではありません。

修正コードが存在することと、そのコードを含む安定版イメージが配布されていることは別です。本稿の確認範囲では、影響対象外と案内できる新しい安定版番号を確定できませんでした。運用者は修正版の配布告知を追い、実際のイメージタグ・ダイジェストや独自ビルドのコミットを照合してください。「0.30.11なら直っている」など未確認の番号は使いません。

独自ビルドを検討する場合も、コミット一つを本番へ機械的に適用するのは避けます。同コミットには認可以外の修正も含まれるため、依存関係、DBとの互換性、起動・配備の基本動作を検証する責任が生じます。緊急性と検証能力を比較し、準備が整うまでは管理面の利用範囲を狭める方針を併せて持つのが現実的です。

修正版を待つ間に狭める境界

以下は本サイトの運用上の提案です。まず、管理画面とAPIを信頼できる運用者の接続元へ絞り、外部テナントが共有管理面を自由に操作できる状態を減らします。公式の本番向け強化ガイドも、管理UIのポートを直接公開せず、VPNなどの経路を使うこと、最小権限、外部へのログ転送を基本対策として挙げています。これらは今回の欠陥自体を修復する手段ではありません。

公開Webアプリと配備管理面は分けて判断します。顧客向けサイトを動かしたまま管理面だけを制限できる構成なら、可用性を維持しつつ攻撃の入口を減らせます。ただし、自動配備、Webhook、API連携まで一律に遮断すると保守が止まるため、必要な接続と担当者を確認してから制限します。

MFAはアカウント侵害の予防に役立ちますが、正規にログインしたowner/adminが別組織へ操作できる認可不備は解消しません。また、adminをMemberへ変えるだけで全経路が安全になるとも断定できません。権限を下げる措置は影響条件を減らす補助として扱い、修正取り込みと組織横断の拒否確認を残してください。

侵害調査は停止履歴だけで終わらせない

本件の資料は実環境での悪用を示していません。脆弱性の存在を侵害済みの証拠にせず、反対に、悪用報告がないことを調査不要の理由にもしないでください。特に外部の複数組織へ管理権限を提供していた場合は、公開期間と権限付与期間を整理し、通常の変更記録と保存された設定を突き合わせます。

調査対象は、環境変数、ビルド引数、ビルド用秘密情報、取得元リポジトリ、ドメイン、Traefik設定、再配備・停止の時系列です。アプリが停止していなくても、次回ビルドや次回配備で発効する設定が書き換わっている可能性を考えます。変更のたびに即座に障害が出るとは限らないため、現在稼働しているイメージと管理画面の設定を別々に確認する必要があります。

公式Audit Logs資料はEnterprise向け機能として、時刻、利用者、操作、対象、当時のロール、追加情報を記録すると説明しています。利用できる場合は、対象組織と実行者の所属を組み合わせて追跡します。組織内の一覧だけでなく、インスタンス管理者が確認できる記録も使い、別組織からの操作を取りこぼさないようにします。

監査ログを使えない環境や保存期間が足りない環境では、配備通知、リバースプロキシのアクセス記録、Gitの履歴、外部レジストリのイメージ、運用チケットなどを時刻で照合します。必要なログが残っていなければ、変更がないとは証明できません。不審な環境変数やビルド元が見つかった場合は、そのまま再配備して状態を上書きする前に、設定と記録を保全してください。

修正後は二つの組織で拒否を確かめる

検証は、許可されたステージング環境とダミーの資源で行います。二つのテスト組織を用意し、一方のowner/adminが自組織のアプリを通常どおり操作できることと、他組織の対象を指定した操作が拒否されることを分けて確認します。拒否応答だけでなく、対象の設定や配備状態が変化していないことも見るのが重要です。

テスト対象は環境変数の保存だけに絞らず、実際に使う配備、停止・開始、ドメインや公開設定などへ広げます。自組織への正当な操作まで止めていないかも確認します。開発元の修正には組織横断の検査を行うテストが加わっていますが、それだけで独自構成や独自パッチの動作まで保証されるわけではありません。

確認記録には、実行中イメージの識別子、修正の出所、検証したロールと操作、拒否結果、対象に変更がないこと、正常操作の結果を残します。ここまで揃えば、単なる「更新済み」という記録から、今回の組織境界が保たれたという対応結果へ進められます。

設定を戻す前に秘密情報と成果物の信頼を確認

設定改変や不審な配備が確認された場合、正しい値を入れ直すだけでは終了できません。秘密情報を参照できた範囲、外部へ送る処理を含む成果物が作られていないか、変更後に配備されたサービスが残っていないかを調べます。必要な鍵の失効・再発行と、信頼できるソースからの再ビルドを検討します。これは本件で漏えいが発生したという主張ではなく、改変が見つかった場合の対応判断です。

侵害の疑いがある場合の保全と再構築は、Webサーバーの証拠保全と再構築ランブックで整理しています。本件では特に、配備基盤の管理情報と実際に動いたアプリの両方を調査対象にしてください。

今回の優先順位は、外部組織のowner/adminが到達できる管理面の制限、修正を含む配布物の確認、組織をまたぐ操作の拒否検証、設定と配備履歴の調査です。アプリ単体の依存ライブラリ更新では、配備基盤の認可は直りません。管理基盤の版と権限境界を担当者が確認し、調査の結果に応じて成果物と秘密情報まで対応範囲を広げましょう。