Jira・ConfluenceなどAtlassianのData Center版にログインなしでファイルを読まれる脆弱性(CVE-2026-21589)、悪用確認でCISA KEVに追加 — まず自社がクラウド版かを確かめる

Jira・ConfluenceなどAtlassianのData Center版にログインなしでファイルを読まれる脆弱性(CVE-2026-21589)、悪用確認でCISA KEVに追加 — まず自社がクラウド版かを確かめる
Photo: Pexels (Pexels) / Omamori AI brand overlay

Atlassianは2026年10月5日、Jira・Confluence・Bitbucketなどを自社のサーバーで動かすData Center版に、ログインしていない攻撃者がサーバー上のファイルを読み取れる脆弱性(CVE-2026-21589)があると公表した。深刻度はCVSS v4で9.3である。米国のサイバーセキュリティ・インフラストラクチャ安全保障庁(CISA)は10月15日、実際に悪用された脆弱性の一覧(KEV)に追加した。Atlassianのクラウド版は修正済みで、利用者の対応は不要である。自社のJiraやConfluenceがどちらで動いているかを確かめることが最初の一手になる。

背景

対象は、Bitbucket、Confluence、Jira Software、Jira Service Management、Bamboo、Crowd の各Data Center版と、Crucible、Fisheyeである。修正版より前のすべてのバージョンが影響を受ける。攻撃者はWebアプリケーションの公開ディレクトリ配下にある特定のファイルを、ログインせずに読み取れる。

読み取るには、ファイルの正確な名前と置き場所を知っている必要があり、ファイルの一覧を取ることはできないとAtlassianは説明している。ただし、製品の標準的な構成で置かれるファイルの場所は広く知られている。構成によっては、そこに機密情報を含むファイルがある。

CISAは10月15日にKEVへ追加し、米国の連邦機関に10月18日までの対応を求めた。この期限はすでに過ぎている。CISAはあわせて、侵害の有無を調べる対象としても扱っている。

修正版は次のとおりである。

  • 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
  • Confluence Data Center:9.2.26、10.2.19
  • Bitbucket Data Center:9.4.26、10.2.8、10.5.1
  • 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

リスクの全体像

ファイルを読まれるだけなら被害は小さいと考えがちだが、読まれるファイルによっては社内への侵入口になる。設定ファイルにデータベースの接続情報や外部サービスの鍵が書かれていれば、攻撃者はそれを使って別のシステムに入れる。CISAが悪用確認だけでなく侵害調査の対象としているのは、このような二次被害を想定しているためである。

JiraやConfluenceには、設計書、顧客との打ち合わせ記録、障害対応の手順、パスワードの保管場所のメモなどが集まりやすい。開発会社やSIerでは、取引先から預かった情報も載っている。Data Center版を社外から接続できる状態で動かしている会社ほど、狙われる可能性が高い。

国内では、自社のサーバーでJiraやConfluenceを動かす開発会社や中堅企業が今も多い。2024年2月に旧来の自社設置版(Server版)のサポートが終わった際、クラウド版へ移らずData Center版に切り替えた会社もある。更新を制作会社や保守会社に任せている場合、修正版の適用が遅れやすい。

チェックリスト

  • 自社のJira・Confluence・BitbucketがAtlassianのクラウド版か、自社サーバーのData Center版かを把握しているか
  • Data Center版なら、バージョンが上記の修正版以上になっているか
  • Data Center版がインターネットから直接接続できる状態になっていないか
  • 保守を外部に任せている場合、今回の脆弱性への対応予定を確認したか
  • アクセスログを、10月以前までさかのぼって確認できる状態で保存しているか
  • サーバーの設定ファイルに書かれたパスワードや鍵の一覧を把握しているか

打ち手

最初に、利用している製品がクラウド版かData Center版かを確かめる。ブラウザで開くアドレスが「〇〇.atlassian.net」ならクラウド版で、今回の対応は不要である。自社のドメインやIPアドレスで開いている場合はData Center版の可能性が高い。

Data Center版であれば、修正版への更新を最優先にする。すぐに更新できない場合、Atlassianは更新までのあいだインターネットから切り離すことを勧めている。切り離せない場合は、WAFやリバースプロキシで、URLの中に「..」がパスの区切り文字と並んで現れるリクエストを、URLエンコードされた形も含めて止める。Atlassianの公表ページには、製品ごとのサーバー設定による遮断手順も載っている。

あわせて、侵害されていないかをアクセスログで確かめる。Atlassianは侵害の有無を自社では判断できないとしており、利用者自身での確認を求めている。ログの各行をURLデコードしてから、「..」が「/」「\」「::」と隣り合うリクエストを探す。該当する記録があり、応答が成功していれば、読まれた可能性のあるファイルに書かれていたパスワードや鍵を変更する。

KEVに載った脆弱性は、対応期限を過ぎてから攻撃が広がることが多い。悪用が確認された脆弱性の一覧(KEV)に自社の製品が載ったときに、誰が確認し、何日以内に更新するかを決めておくと、次の同種の件で慌てずに済む。

あわせて読みたい

Omamori AI の結論

CVE-2026-21589は、JiraやConfluenceなどのData Center版で、ログインしていない攻撃者にサーバー上のファイルを読まれる脆弱性で、すでに悪用が確認されている。クラウド版の利用者は対応不要だが、自社サーバーで動かしている会社は修正版への更新と、アクセスログでの侵害確認を急ぐべきである。読まれた可能性がある場合は、設定ファイル内のパスワードと鍵の変更までを1つの対応として進めたい。

経営者視点で考えるべきこと

JiraやConfluenceは、社内の知識と取引先の情報が最も集まる場所の1つである。自社のサーバーで動かす理由がデータの置き場所や取引先との契約にあるなら、その分の更新と監視の手間を誰が負うかを決めておく必要がある。保守会社に任せている場合は、悪用が確認された脆弱性について何日以内に更新するかを契約に書いておく。クラウド版に移れば今回のような更新作業はAtlassian側で済むので、移行の費用と自社で守り続ける費用を一度比べておきたい。

SHARE 𝕏 in f

あわせて読みたい