Atlassian製品のファイルアクセス対策は認証画面の確認だけで大丈夫？

Atlassianは2026年10月5日、複数の製品へ影響する任意ファイルアクセスの脆弱性CVE-2026-21589を公表しました。影響するWebアプリケーションのルートディレクトリ内にある特定のファイルへ、認証されていない攻撃者がアクセスできる問題です。提供元の評価はCritical、CVSS v4.0で9.3です。

本稿は10月18日に公式勧告を確認した更新解説です。公表日と確認日は異なり、18日の新たな被害を伝える速報ではありません。対象の製品・構成、ファイルの範囲、修正と暫定措置を分けて整理します。日本国内の被害やAIを使った攻撃を確認したものではありません。

出典：Atlassian：CVE-2026-21589のセキュリティ勧告。

すべてのファイルを自由に探せる問題とは違う

公式説明では、取得対象の正確なファイル名とパスを事前に知る必要があり、ディレクトリの中身を一覧にすることはできないとされています。また、対象はWebアプリケーションのルート内です。「サーバー上の全ファイルを無条件に読める」と表現すると、実際の説明を超えてしまいます。

一方、正確な名前が必要という条件は、問題が無視できることを意味しません。運用で使う分かりやすい名前、外部へ共有した配置情報などが、対象の特定に関わる場合があります。これは一般的なリスクの考え方で、今回どの情報が攻撃に使われたかを断定するものではありません。

本サイトでは、影響範囲を考える際に、公開領域のどこへ何を置いていたかを調べることを勧めます。資格情報、設定の複製、保守用の退避物などがあるなら、閲覧経路と保存目的を確認します。ただし、本脆弱性でそれらすべてが読めると決め付けず、構成に即して判断してください。

対象製品とCloudの対応を区別する

公式の対象製品にはBitbucket Data Center、Confluence Data Center、Jira Service Management Data Center、Jira Software Data Center、Bamboo Data Center、Crowd Data Center、Crucible、Fisheyeが含まれます。製品ごとに修正版が示されているため、一製品の更新をもってほかも対応済みとしないでください。

Atlassian Cloudについては、影響する製品は修正済みで、調査で悪用の証拠を見つけておらず、Cloud利用者の操作は不要と説明しています。これはCloudについての説明です。自社運用のData Center環境の悪用状況まで同じだと読み替えてはいけません。

台帳では、サービス名だけでなく提供形態、稼働版、URL、担当を確認します。利用者が「Jiraを使っている」と答えただけでは、どの提供形態か、誰が更新するのかは分かりません。委託先の運用なら、その責任範囲と作業結果を具体的に確認します。

系列に応じた修正版を製品ごとに照合する

勧告の修正版の例として、Bitbucketには9.4.26、10.2.8、10.5.1、Confluenceには9.2.26、10.2.19が示されています。これは全製品へ使える共通の番号ではありません。現在の系列に適合する公式の表を確認してください。

本記事では長い修正版一覧を独自に再編して固定しません。勧告にはJira、Bamboo、Crowd、Crucible、Fisheyeの更新先も掲載されているため、実際に使う製品ごとに参照します。作業時に追加更新がないかも確認し、記事の一例だけで最終的な移行先を決めないようにします。

作業票には「対象製品」「現在の版」「選んだ修正版」「導入形態」「完了確認」を残す方法を提案します。複数ノードの構成では、各ノードの更新と、負荷分散後に古い実体へ戻らないことも確認します。インストーラーの取得と本番稼働の確認は別です。

ログイン必須の画面があるだけで境界は閉じない

本脆弱性は認証されていない攻撃者による特定ファイルへのアクセスとして説明されています。通常のアプリ画面へログインが必要なことを、すべてのHTTP経路へ同じ認証が適用されている証拠と考えないでください。

本サイトの提案は、アプリの認証、リバースプロキシの制限、ネットワークからの到達範囲を分けて把握することです。管理者だけが使う想定でも、公開ホスト名や別の接続経路があるなら、その経路を含めます。正規の利用者が認証される仕組みと、公開されるファイルの扱いは別の確認項目です。

暫定的に接続元を制限する場合は、業務連携や自動ジョブの到達先も調べます。すべてを止めるか、すべてを開けるかの二択にせず、必要な経路と責任者を絞ります。ただし、接続制限が設定できたことをソフトウェアの修正と同じ意味で報告しないでください。

公開領域の退避物は別の保管先へ整理する

説明用の仮想例として、管理者が障害調査のため、設定ファイルのコピーをWebアプリの配置先へ一時的に保存した場合を考えます。名前を変えただけでアクセス制御が追加されたわけではなく、後から保存の目的が分からなくなることもあります。

今回の対策に限らず、本サイトは、公開に不要なデータを公開領域へ残さない方針を勧めます。残す必要がある調査資料は、アクセス権と保持期限を設定できる保管先へ置きます。ファイル名を長い乱数へ変えるだけを恒久対策にしないでください。

ただし、不審な配置物がある場合は、ただ削除して終わらず、その作成者、作成時刻、用途を確認します。侵害の疑いがあるときは、必要な記録を保全して対応担当へつなぎます。正常な保守の残骸と不正なファイルを、名前だけで断定しないことが重要です。

暫定措置は公式の条件と戻す手順まで確認する

公式は、更新や緩和策を実施するまで可能なら外部ネットワークからのアクセスを制限することや、製品に応じた一時的な対処を案内しています。WAFの正規表現フィルターなども記載されていますが、実際の適用は公式の最新手順と環境に沿って行ってください。

記事の中で簡略化した正規表現を示すと、必要な条件が落ちるおそれがあります。そのため本稿では、公式の手順を勝手に短縮した遮断ルールを掲載しません。導入する場合は、正規の要求が通ること、拒否すべき経路が拒否されることを許可された試験で確認します。

暫定措置には、適用先、設定を配信する場所、更新の予定、解除を判断する人を残します。修正後も不要な外部公開を再開する必要はありませんが、必要な機能への一時制限を放置しないよう、更新作業と復旧確認を対応付けます。

開発の資料と認証情報を同居させない構成の見直し

説明用に、障害対応のメモ、設定の複製、アプリの配信物を同じWeb配置先へ保管していたケースを考えます。担当者にとって便利でも、何が公開対象で何が保守用かを権限で分けにくくなります。今回の脆弱性でその環境の情報が読まれたと断定する例ではありません。

見直しは、ファイルの必要性、保管先、読む担当、保持期間から始めます。保守用の資料を移動するときは、移動後のアクセス権を確認し、旧パスに複製やアーカイブが残っていないかを調べます。機微な情報が含まれていた場合は、移動だけで過去の露出が解消したとは扱いません。

資格情報の更新が必要かは、実際の保存内容、公開された可能性、接続先の用途を基に判断します。機械的な全交換で業務を止めるのでも、記録が見つからないから交換不要と即断するのでもなく、対応担当と影響範囲を決めます。秘密そのものを調査票へ並べず、管理元と失効方法を記録します。

この整理は、修正版の適用後にも価値があります。将来別のファイル配信の問題が起きた際、公開領域にあるデータをすぐ把握できるからです。ただし、配置の整理を終えるまで修正を延期する計画にはせず、入口の制限と製品の更新を先に進められるよう並行して担当を決めます。

対応票に残す確認項目

以下は本サイトが提案する対応票の例です。すべてを同じ担当へ任せる必要はありませんが、対象環境と結果を対応付け、未完了の行には責任者と次の実施予定を残します。確認できなかった項目を、正常という結果で埋めないことが大切です。

確認箇所	残す内容	完了の判断
提供形態	製品名とCloudか自社運用か	製品ごとの責任者と更新対象を確定
修正版	系列と公式表で選んだ更新先	異なる製品の版を取り違えない
配置内容	公開領域にある保守用のファイル	不要な退避物とその保管権限を整理
到達範囲	外部・保守・プロキシ経由の接続	ログイン画面だけで制限済みとしない
事後調査	対象期間と利用できるアクセス記録	更新成功と過去の露出の判断を分ける

更新後の動作と過去のアクセスを分ける

更新後は、通常利用、認証、必要なアプリ連携、ファイル配信の代表経路を確かめます。ログイン済みの管理者のブラウザーだけでなく、許可されない接続の扱いも確認します。攻撃の再現に使う要求を本番で無計画に送信する必要はありません。

過去の影響を調べる場合は、対象のファイルが存在した期間と、公開・接続制限の履歴を対応付けます。アクセスログの有無、保存期間、プロキシを通る経路も確認します。記録がない期間を問題なしとして扱わず、分からないことを明示します。

今回の修正は、業務アプリのログイン画面だけを見て安全性を判断しないための機会です。製品ごとの公式更新を反映し、公開ディレクトリと到達経路を整理することで、修正後の状態と今後の保守の責任を具体的に説明できます。