【緊急】Atlassian Data Center製品 CVE-2026-21589：全バージョンが影響 — 修正版へ更新し、できなければWAFで「..」を遮断

Atlassian の Data Center 製品に、認証なしの攻撃者がWebルート内のファイルを読める脆弱性（CVE-2026-21589）が公表されました。対象は Confluence・Jira Software・Jira Service Management・Bitbucket・Bamboo・Crowd・Crucible・Fisheye の各 Data Center で、Atlassianは2026年10月5日（米国時間）のアドバイザリで、修正版が出るより前の全バージョンが影響を受けると書いています。
Atlassian Cloud は対応済みで、利用者の作業は要りません。自社サーバーで動かしている Data Center だけが対象です。

先に、分かっていることと分からないことを分けます。Atlassianは重大度を CVSS v4.0 の 9.3（CRITICAL） と評価しています（これは Atlassian 自身の評価で、NVD〔NIST〕の評価は10月7日の確認時点でまだ付いていません）。悪用の有無について、公式アドバイザリはData Centerには触れておらず、Cloud側について「悪用の証拠は見つかっていない」と書いています。CISAのKEV（悪用が確認された脆弱性のカタログ）にも、10月7日に取得した版（更新日時は10月4日）には載っていません。
ただし、攻撃には「対象ファイルの正確な名前とパス」を知っている必要があります。Atlassianは、ディレクトリの一覧を取ることはできないと書いています。一方で、「設定によっては重要なファイルがあり、リスクが高くなる」とも書いています。

今すぐ行う対策

• ✓まず、自社で動かしている Atlassian 製品のうち、Data Center の版を洗い出す。Confluence・Jira・Bitbucket だけでなく、Bamboo・Crowd・Crucible・Fisheye も対象です。Atlassian Cloud を使っているだけなら、作業は要りません
• ✓次の修正版へ更新する。Bitbucket 9.4.26／10.2.8／10.5.1、Confluence 9.2.26／10.2.19、Jira Software 9.12.40／10.3.26／11.3.12、Jira Service Management 5.12.40／10.3.26／11.3.12、Bamboo 10.2.24／12.1.12、Crowd 6.3.7／7.0.3／7.1.7／7.2.4、Crucible と Fisheye は 4.9.15。Atlassianは、修正された長期サポート版（LTS）以降へ更新するよう勧めています
• ✓すぐ更新できないなら、インターネットから切り離す。Atlassianは「パッチか緩和策を当てるまで、可能ならインスタンスをインターネットから外す」と書いています。ユーザー認証があっても、インターネットに公開されているインスタンスは外部からのアクセスを制限するよう求めています
• ✓切り離せないなら、公式が示す暫定対策を入れる。WAFやリバースプロキシで「..」を含むURLを遮断する方法と、製品ごとの設定ファイルで遮断する方法があります（下の節）。設定の文字列は、Atlassianのアドバイザリからそのままコピーしてください
• ✓アクセスログを調べる。Atlassianは、自社では影響の有無を確認できないので、各社のセキュリティ担当がログを確認するよう書いています。探し方は下の節にあります

影響を受ける製品と修正版（Atlassianのアドバイザリより）

• ▸Bitbucket Data Center：9.4.26、10.2.8、10.5.1 が修正版
• ▸Confluence Data Center：9.2.26、10.2.19 が修正版
• ▸Jira Software Data Center：9.12.40、10.3.26、11.3.12 が修正版
• ▸Jira Service Management Data Center：5.12.40、10.3.26、11.3.12 が修正版
• ▸Bamboo Data Center：10.2.24、12.1.12 が修正版
• ▸Crowd Data Center：6.3.7、7.0.3、7.1.7、7.2.4 が修正版
• ▸Crucible と Fisheye：どちらも 4.9.15 が修正版
• ▸アドバイザリは、修正版より前の版は全て影響を受けると書いています。NVDの説明文には、各製品で脆弱性が入った版（たとえば Bitbucket は 4.6.0 以上、Confluence は 5.10.0 以上、Jira Software は 7.1.0 以上）も書かれています
• ▸新しい方針として、重大なセキュリティ修正は過去の版にも移植され、バイナリのパッチは出ません。修正版の保守リリースを入れる形になります（Atlassianのアドバイザリの記述）

更新できないときの暫定対策（公式の3通り）

Atlassianは、3つの方法を示しています。どれも、「..」が「/」「\」「::」のすぐ隣にあるURLを止めるという考え方です。URLエンコードされた形（%2e%2e など）も対象にしています。正規表現などの設定値は長く、1文字の違いで効かなくなるので、この記事には載せません。アドバイザリのコードをそのままコピーしてください。

• ▸方法1（全製品）：WAFやプロキシ（リバースプロキシ、AWS WAF、Cloudflare など）に、アドバイザリの正規表現に一致するURLを遮断するルールを入れる
• ▸方法2（Confluence・Jira・Jira Service Management・Bamboo・Crowd）：Tomcat の RewriteValve を有効にし、WEB-INF の rewrite.config に遮断ルールを足す。作業の前にバックアップを取り、クラスタの各ノードを1台ずつ停止して設定し、再起動します
• ▸方法3（Bitbucket のみ）：インストール先の app/WEB-INF/urlrewrite.xml の先頭に遮断ルールを足し、再起動する。ミラーとミラーファームのノードにも同じ設定が必要です
• ▸どの方法でも、入れたあとに「..」が隣り合うURLが実際に止まるか、エンコードされたパターンも含めて試してください（Atlassianが「テストする」よう書いています）

侵害の痕跡の探し方（公式の案内）

Atlassianは、アクセスログを2つの方法で調べるよう書いています。
① リクエスト行をURLデコード（最大2回）してから、「..」が「/」「\」「::」の隣にあるものを探す。
② デコードしていない生のログ行を、アドバイザリの正規表現で直接検索する。
この脆弱性による侵害の痕跡（IoC）として、ファイル名の一覧などは、Atlassianも公開していません。ログに該当が出たら、どのファイルが読まれた可能性があるかを、各社のセキュリティ担当と確認してください。設定ファイルや認証情報が同じWebルートにあるかどうかを点検することも有効です

悪用について、分かっていることと分からないこと

分かっていること。Atlassianのアドバイザリは、脆弱性の内容と修正版、暫定対策を示しています。Cloud については「悪用の証拠は見つかっていない」と書いています。KEVには、10月7日に取得した版では載っていません。
分からないこと。Data Center に対する悪用の有無について、アドバイザリには記述がありません。報道（BleepingComputer）では、Atlassianが「現時点で悪用の証拠は持っていない」と説明したと伝えられていますが、私はAtlassianの発言そのものを一次資料で確認できていません。公開されたばかりで、他社による検証や攻撃コードの有無も、確認できる資料がありません。「悪用は確認されていない」と「安全」は別です。認証なしでネットワーク越しに届き、修正版が出ているので、公開されているサーバーは早めに更新してください。

確認できなかったこと

• ▸NVDの評価。10月7日の確認時点で NVD は「評価待ち（Awaiting Analysis）」で、NIST の CVSS は付いていません。この記事の 9.3（v4.0・CRITICAL）は、Atlassian が CNA として登録した値です。 NIST の評価が付くと、数字が変わることがあります
• ▸どのファイルが読まれ得るか。Atlassianは「設定によっては重要なファイルがある」と書くのみで、具体的なファイルや製品ごとの影響は書いていません
• ▸悪用の有無と、検知用の痕跡（IoC）。上の節のとおり、公式資料には記述がありません
• ▸日本のJVNの掲載。この記事を書いた時点では、JVNでこのCVEを確認していません。公式の修正版と暫定対策は Atlassian のアドバイザリが正本です

共有するならこの3行

• ▸Atlassianの Data Center 製品（Confluence・Jira・Bitbucket・Bamboo・Crowd・Crucible・Fisheye）に、認証なしでファイルを読まれる脆弱性（CVE-2026-21589）。Atlassianの評価は 9.3（CRITICAL）。Cloud は対応済みで作業不要
• ▸★自社サーバーで動かしているなら、修正版へ更新する。更新できないなら、インターネットから外すか、公式のWAFなどの暫定対策で「..」を含むURLを止める
• ▸悪用は公式資料に記述がないが、「安全」ではない。アクセスログを、公式の方法で確認する

根拠にしたページ