---
title: "Atlassian 脆弱性CVE-2026-21589：Jira・Confluenceの修正版と侵害確認の手順"
url: "https://www.issoh.co.jp/tech/details/18839/"
published: 2026-10-24
updated: 2026-10-24
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# Atlassian 脆弱性CVE-2026-21589：Jira・Confluenceの修正版と侵害確認の手順

Atlassianは2026年10月5日、Jira・Confluence・Bitbucketなど8製品のData Center版にまたがる脆弱性CVE-2026-21589を、月例とは別の臨時アドバイザリで公表しました。ログインせずにWebアプリケーション内のファイルを読み出せる欠陥で、CVSS v4.0の値は9.3です。10月15日には米CISAが「悪用が確認された脆弱性（KEV）」に加えました。この記事では、製品ごとの修正版、全サーバーの版をまとめて判定するスクリプト、更新までの暫定策、アクセスログの調べ方、Crowdと連携している環境で追加で要る作業を順に整理します。内容は2026年10月24日時点の公開情報にもとづきます。

## まとめ：修正版へ更新し、外部公開とCrowd連携の環境は追加対応

対象はJira Software、Jira Service Management、Confluence、Bitbucket、Bamboo、Crowd、Crucible、FisheyeのData Center版です。アドバイザリは「修正版より前の全バージョン」が影響を受けるとしており、版が古いから無関係という逃げ道はありません。Atlassian Cloudは修正済みで、利用者側の作業は不要です。

やることは3つに絞れます。修正版（Confluenceなら10.2.19か9.2.26、Jiraなら11.3.12・10.3.26・9.12.40など）へ上げること。すぐ上げられないならインターネットから切り離し、WAFかTomcatの設定で暫定的に止めること。そして10月5日以降のアクセスログを調べ、Crowdとの連携用パスワードを入れ替えるかを決めることです。社内のどのサーバーが外から見えているかの棚卸しから始めたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で外部公開面を洗い出すと抜けが減ります。

## CVE-2026-21589の中身：認証なしでWEB-INF配下を読める仕組みと影響範囲

まずアドバイザリと解析記事に書かれている事実を、書かれていないことと分けて押さえます。

### CVSS v4.0で9.3、ファイル名を知っていれば認証なしで読める欠陥

[Atlassianのアドバイザリ](https://confluence.atlassian.com/security/cve-2026-21589-arbitrary-file-access-vulnerability-impacts-multiple-products-1870495748.html)は、この欠陥を「Arbitrary File Access」と呼んでいます。認証の無い攻撃者が、Webアプリケーションのルートディレクトリ内にある特定のファイルを読めるという内容です。読むにはファイルの正確な名前とパスを知っている必要があり、ディレクトリの一覧は取れません。

評価のベクトルは「AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H」です。製品そのものへの影響は機密性だけ（VC:H）ですが、後続のシステムには機密性・完全性・可用性のすべてで高い影響（SC/SI/SA:H）があるという付け方になっています。読まれたファイルの中身が、別のシステムへの入口になるという評価です。v4.0のSC・SIの読み方は[nginxの脆弱性で見たCVSS v4.0 9.2の読み方](https://www.issoh.co.jp/tech/details/12647/)でも整理しています。

### atlassian-plugins-webresourceの「::」変換が原因とする解析

発見の経緯は公表されていませんが、10月6日に[watchTowr Labsが修正前後の差分を解析](https://labs.watchtowr.com/you-wont-hear-about-these-even-in-myths-atlassian-jira-confluence-and-more-pre-auth-arbitrary-file-read-cve-2026-21589/)しています。8製品が同時に当たる理由は、共通の部品atlassian-plugins-webresourceにありました。脆弱な6.0.7と修正後の6.0.8を比べると、静的リソースを返す経路で「::」を「/」に戻す処理があり、パス中の「..」の検査をすり抜けて上位のディレクトリへ戻れたとしています。

読めるのはTomcatのコンテキスト（アプリケーションの配置ディレクトリ）の中までで、OS全体のファイルではありません。ただし通常は外から見えないWEB-INF配下も含まれ、解析ではJiraとConfluenceのweb.xml、Bitbucketのurlrewrite.xmlを読み出せたと報告されています。アドバイザリの「構成によっては機密性の高いファイルがある」という一文は、この範囲に設定ファイルを置いている環境を指します。

### KEV追加は10月15日、対応期限の10月18日はすでに経過

2026年10月24日に取得した[CISAのKEVカタログ](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)では、追加日が10月15日、米連邦機関の対応期限が3日後の10月18日です。[CVE.orgのレコード](https://www.cve.org/CVERecord?id=CVE-2026-21589)にはCISAが同日付で付けたSSVC（対応の優先度の判定）があり、値は「Exploitation: active」「Technical Impact: total」でした。悪用が実際に起きているという判定です。

watchTowrは悪用の再現コードを公開せず、対象が脆弱かどうかを確かめる[検出スクリプト](https://github.com/watchtowrlabs/watchTowr-vs-Atlassian-CVE-2026-21589)をJira・Confluence・Bitbucket向けに公開しています。とはいえ解析記事に経路の考え方が書かれている以上、攻撃側が同じものを作るのは難しくありません。公表から3週間がたった今、外から届くサーバーを未更新のまま置く理由は残っていません。

## 影響版の確認：8製品の修正版表とmanifestで版を判定するPython

判定に要るのは、各サーバーの製品・版と、その版が属する系列の修正版です。

### Jira・Confluence・Bitbucketなど8製品の修正版とLTS以外の扱い

アドバイザリの修正版は次のとおりです。製品ごとの公開チケット（[ConfluenceはCONFSERVER-104488](https://jira.atlassian.com/browse/CONFSERVER-104488)、[JiraはJRASERVER-79546](https://jira.atlassian.com/browse/JRASERVER-79546)など）の修正版欄も同じ値です。

| 製品（Data Center）         | 修正版1    | 修正版2    | 修正版3    | 修正版4  |
| ----------------------- | ------- | ------- | ------- | ----- |
| Jira Software           | 9.12.40 | 10.3.26 | 11.3.12 | －     |
| Jira Service Management | 5.12.40 | 10.3.26 | 11.3.12 | －     |
| Confluence              | 9.2.26  | 10.2.19 | －       | －     |
| Bitbucket               | 9.4.26  | 10.2.8  | 10.5.1  | －     |
| 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  | －       | －       | －     |

表に無い系列は修正版が出ていません。たとえばConfluence 9.5系や10.1系の環境は、10.2.19などLTS（長期サポート版）の修正版か、最新版へ移る必要があります。Confluence 11.0系は、10月24日時点でアドバイザリにもチケットの修正版欄にも載っていないので、11.0系を使っているならリリースノートで修正を確かめてください。なお10月20日の[月例Security Bulletin](https://confluence.atlassian.com/security/security-bulletin-october-20-2026-1874690162.html)は、同梱ライブラリ由来の別の脆弱性176件をまとめたもので、CVE-2026-21589は含みません。修正版は同じ値なので、上の版へ上げれば両方が片付きます。

### applinksのmanifestから製品と版を取り出す判定スクリプト

Atlassian製品は、製品間連携（Application Links）のために「/rest/applinks/1.0/manifest」で自分の製品種別と版をXMLで返します。応答の形は[AtlassianのKB](https://support.atlassian.com/atlassian-knowledge-base/kb/creating-an-application-link-between-atlassian-products-results-in-a-warning-about/)に例があり、typeIdとversionの要素を持ちます。これを使い、複数サーバーの版を上の表と突き合わせる例です。

```
import re
import sys
import urllib.request
import xml.etree.ElementTree as ET

# CVE-2026-21589 の修正版（manifest の typeId : 修正版）
FIXED = {
    "jira":       ["9.12.40", "10.3.26", "11.3.12"],
    "confluence": ["9.2.26", "10.2.19"],
    "stash":      ["9.4.26", "10.2.8", "10.5.1"],   # Bitbucket
    "bamboo":     ["10.2.24", "12.1.12"],
    "crowd":      ["6.3.7", "7.0.3", "7.1.7", "7.2.4"],
    "fecru":      ["4.9.15"],                       # Fisheye / Crucible
}

def ver(s):
    return tuple(int(x) for x in re.findall(r"\d+", s)[:3])

def judge(type_id, version):
    fixes = FIXED.get(type_id)
    if fixes is None:
        return "表に無い製品（typeId を確認）"
    v = ver(version)
    for f in fixes:
        if v[:2] == ver(f)[:2]:
            return "修正済み" if v >= ver(f) else "要更新 -> " + f
    return "系列に修正版なし -> LTSの修正版か最新版へ"

# 使い方: python check_21589.py https://jira.example.local https://wiki.example.local
for base in sys.argv[1:]:
    url = base.rstrip("/") + "/rest/applinks/1.0/manifest"
    with urllib.request.urlopen(url, timeout=15) as r:
        m = ET.fromstring(r.read())
    t, v = m.findtext("typeId"), m.findtext("version")
    print(base, t, v, judge(t, v))
```

判定の関数は2026年10月24日に手元で実行し、Confluence 10.2.18で「要更新 -> 10.2.19」、10.2.19で「修正済み」、9.5.4と11.0.0で「系列に修正版なし」を返すことを確かめました。typeIdはKBの例ではconfluenceです。他の製品は1台分の出力を見て、表のキーを実際の値に合わせてください。Jira Service ManagementはJira本体の上に入るアプリなので、manifestにはJira本体の版が出ます。JSM 5.12系はJira 9.12系に当たり、修正版の末尾はいずれも同じ（.40）です。manifestが取れない構成なら、管理画面のフッターに出る版で同じ判定ができます。REST APIを呼ぶ処理の書き方は[Confluence REST APIのv1とv2の違いと移行手順](https://www.issoh.co.jp/tech/details/17390/)も参考になります。

## すぐ更新できないとき：WAFとTomcat RewriteValveで止める暫定手順

アドバイザリが最初に挙げる暫定策は、更新か緩和策の適用までインスタンスをインターネットから外すことです。ログイン画面を挟んでいても外部公開なら対象だとしています。そのうえで、3つの設定方法が示されています。

### WAFに入れる正規表現と、エンコード済みの「..」を落とす条件

1つ目は、全製品に共通で、WAFかリバースプロキシで次の正規表現に当たるURLを止める方法です。意図は「..」の直前直後に「/」「\\」「::」が付いたものを止めることで、%2e や %3a のようなURLエンコード、さらに %25 を重ねた2重エンコードにも当たるように書かれています。

```
(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*
```

注意したいのは、WAFがURLをどこまでデコードしてから照合するかが製品ごとに違う点です。AWS WAFやCloudflareに入れたら、「..::」とそのエンコード違いを実際に送って403になるかを確かめてから運用に乗せてください。WAFの置き場所や他の防御との役割分担は[WAFの仕組みとファイアウォール・IPSとの違い](https://www.issoh.co.jp/tech/details/13275/)で整理しています。

### Tomcatのserver.xmlとrewrite.configによる遮断設定

2つ目は、Jira・JSM・Confluence・Bamboo・Crowdに同梱のTomcatで止める方法です。クラスタ構成なら全ノードで、ノードを止めてから次の順に作業します。

1. conf/server.xml（Crowdはcrowd.xmlの場合あり）を複製して控え、アプリケーションのContext要素の中に「Valve className=”org.apache.catalina.valves.rewrite.RewriteValve”」の行を足す
2. WEB-INF（Confluenceならconfluence/WEB-INF、Jiraならatlassian-jira/WEB-INF）にrewrite.configを作るか、既存の末尾に下の内容を足す
3. ノードを再起動し、正規の画面と添付ファイルのダウンロードが開けることを確かめる

```
# Tomcat がデコード・正規化したパスで判定する
RewriteCond %{REQUEST_PATH} (?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*
RewriteRule (?s)^.*$ /?denied [F,L]
# デコード前の生の URI でも判定する
RewriteCond %{REQUEST_URI} (?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*
RewriteRule (?s)^.*$ /?denied [F,L]
```

REQUEST\_PATHは、[Tomcatのrewrite docs](https://tomcat.apache.org/tomcat-9.0-doc/rewrite.html)によれば、デコードと正規化を済ませたマッピング用のパスです。正規化後と生のURIの両方で見るので、WAFより取りこぼしが少ない設定になります。Bitbucketはこの方法の対象外で、3つ目の方法としてapp/WEB-INF/urlrewrite.xmlの先頭に同じ正規表現のruleを足し、404を返させます。ミラーやミラーファームのノードも対象です。同梱Tomcat自体の脆弱性も更新で追随する必要があるので、[Apache Tomcatの脆弱性一覧と修正版](https://www.issoh.co.jp/tech/details/15405/)も合わせて確認してください。

## 侵害の確認：アクセスログを2回デコードして探す手順とCrowdの入れ替え

アドバイザリは、自社のインスタンスが攻撃を受けたかどうかをAtlassian側では判断できないと明記しています。調べるのは利用者側の仕事です。

### アクセスログのリクエスト行を最大2回デコードして照合するスクリプト

示されている手順は、アクセスログの各リクエスト行を最大2回URLデコードしてから「..」と「/」「\\」「::」の隣接を探すか、デコードせずに上の正規表現で生の行を探すかのどちらかです。両方を1本で行う例です。

```
import re
import sys
import urllib.parse

# アドバイザリの正規表現（Python でもそのまま使える）
PAT = re.compile(
    r"(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}"
    r"(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*"
)

# 使い方: python hunt_21589.py access_log.2026-10-05.txt access_log.2026-10-06.txt ...
for path in sys.argv[1:]:
    with open(path, encoding="utf-8", errors="replace") as f:
        for no, line in enumerate(f, 1):
            s = line
            for _ in range(3):              # 生の行 → 1回デコード → 2回デコード
                if PAT.search(s):
                    print(path, no, line.rstrip()[:300])
                    break
                s = urllib.parse.unquote(s)
```

この照合部分は手元で実行し、「%252e%252e%253a%253a」のような2重エンコードも検出し、「file..txt」のような通常のファイル名には反応しないことを確かめました。調べる範囲は、Tomcatのアクセスログに加えて、前段のリバースプロキシやロードバランサのログです。WAFで止めた後でも、止める前の期間のログは別に見る必要があります。少なくともアドバイザリが出た10月5日以降は必ず含めてください。

### Crowd連携のcrowd.propertiesで入れ替える認証情報

ヒットがあった場合に一番重いのは、Crowdとの連携設定です。[JiraとCrowdを連携させる公式手順](https://confluence.atlassian.com/crowd/integrating-crowd-with-atlassian-jira-192625.html)では、シングルサインオン用の設定ファイルをatlassian-jira/WEB-INF/classes/crowd.propertiesに置き、そこにapplication.nameとapplication.passwordを書きます。まさに今回読める範囲です。

watchTowrは、このファイルのパスワードが平文で入っていること、それを使ってCrowdのREST APIから利用者を作り、jira-administratorsグループに入れられることを示しました。この構成で不審なリクエストが1件でもあれば、更新とは別にCrowd側でアプリケーションのパスワードを変えてcrowd.propertiesを書き直し、Crowdの利用者一覧と管理者グループに見覚えのない追加が無いかを、併せて確かめてください。Crowdの設定でアプリケーションの接続元アドレスを絞っておけば、パスワードが漏れても外部から使われにくくなります。SSOの方式そのものを見直す場合は[シングルサインオンの4つの実現方式とIdP選定](https://www.issoh.co.jp/tech/details/15821/)が出発点になります。

## 対応の優先順位：外部公開の有無とCrowd連携で決める3段階の判断基準

複数のAtlassianサーバーを抱えている場合の順番を、条件ごとに言い切ります。

### インターネットから届くサーバーは当日中に更新か通信遮断を選ぶ判断基準

最優先は、社外から直接アクセスできるJira・Confluence・Bitbucketです。認証も操作も要らず、KEVで悪用が確認済みなので、当日中に修正版へ上げるか、それができなければ外部からの通信を止めます。WAFやrewrite.configの暫定策は、更新の日程を数日確保するための手段にとどめます。正規表現がWAF側のデコードと食い違えば素通しになり、その確認にかける時間で更新が済むことも多いからです。

2番目は、社外公開はしていないもののVPN経由で取引先や委託先がつなぐサーバーで、週内に更新します。社内LANからしか届かないサーバーも後回しにしてよい理由はありません。中の端末が乗っ取られれば同じ経路で読まれます。逆に、Server版（Data Centerでない旧ライセンス）を使い続けている環境は修正版の表にそもそも載っていません。この場合はData Center版かCloudへの移行計画が先で、暫定策は延命にしかなりません。

### Crowd連携と古い系列が残る環境で、更新後に見直す判断基準

更新を終えても作業が残るのが、crowd.propertiesを置いてCrowdとつないでいる環境です。ログで不審なリクエストが見つかった場合、更新だけで済ませる判断は誤りです。読まれたパスワードは更新後も有効なまま残るため、前の章の入れ替えまでを1つの作業として扱ってください。

もう1つは、修正版の無い系列（Confluence 9.5系など）を使い続けている環境です。今回はLTSへの移行で穴をふさげても、次の臨時アドバイザリでも同じ判断を迫られます。LTSの系列にそろえて、月例のSecurity Bulletinの日程に合わせて上げる運用に切り替えるのが筋です。外部公開面の洗い出しや更新後の確認を社外の目で行いたい場合は、[脆弱性診断の進め方と外注時の判断基準](https://www.issoh.co.jp/column/details/13101/)から始めると範囲を決めやすくなります。

## Atlassian CVE-2026-21589の対応でよくある質問と回答

CVE-2026-21589の対応で出てきやすい疑問に、公開されている一次情報の範囲で答えます。

### Atlassian CloudのJiraやConfluenceを使っていても対応は必要ですか？

不要です。アドバイザリは、影響を受けるCloud製品は修正済みで、調査の範囲で悪用の証拠は見つかっていないとし、Cloudの利用者の作業は要らないと明記しています。対象は自社のサーバーやクラウド基盤で動かしているData Center版だけです。Cloudへ移行中で、旧環境のData Center版をまだ止めていない場合は、そちらが対象に残ります。

### Confluenceの脆弱性CVE-2026-21589の修正版はどれですか？

Confluence Data Centerの修正版は9.2.26と10.2.19です。どちらもLTSの系列で、9.5系や10.1系のように修正版が出ていない系列からは、このどちらか、または最新版へ上げます。11.0系は2026年10月24日時点でアドバイザリにも公開チケットにも記載が無いため、リリースノートで修正を確かめてください。

### Jiraの脆弱性はJira Service Managementにも影響しますか？

Jira Service Managementも影響を受ける対象です。アドバイザリはJira SoftwareとJira Service Managementを別々に挙げ、JSMの修正版を5.12.40・10.3.26・11.3.12としています。JSMはJira本体の上で動くアプリなので、実際に必要な作業は、Jira本体を修正版の系列へ上げることです。JSM 5.12系はJira 9.12系に当たり、どちらも修正版の末尾が.40でそろっています。更新後は、JSMの版も表の値以上になっているかを管理画面で確かめてください。

### WAFのルールを入れれば更新を延期してもよいですか？

延期の理由にはなりません。アドバイザリ自身がWAFやTomcatの設定を「更新できない場合の暫定策」と位置づけています。正規表現はエンコードの重ね掛けまで想定していますが、WAFがURLをどこまでデコードしてから照合するかは製品ごとに違い、すり抜けが無いと言い切れるのは自社で実際に試した場合だけです。暫定策を入れた日に、更新の日程も決めてください。

### 読まれたかどうかはサーバーの痕跡から判断できますか？

アクセスログから判断します。アドバイザリは、Atlassian側では各環境が攻撃を受けたかを確かめられないとし、アクセスログのリクエスト行を最大2回デコードして「..」と区切り文字の隣接を探すよう求めています。ファイルを読むだけの攻撃で書き込みを伴わないため、改ざんの跡のようなサーバー上の痕跡は期待できません。ログの保存期間が短い環境は、まず消える前に退避してください。

## 関連記事

- [Confluenceの検索方法｜完全一致・AND検索・ラベル絞り込みとアンカーリンクの作り方](https://www.issoh.co.jp/column/details/3679/)：Confluenceを日常の情報共有に使う場面の基本操作です。
- [Jiraの使い方｜スペース作成・エピックの使い分けと「使いにくい」の解決法](https://www.issoh.co.jp/tech/details/7859/)：今回の対象製品であるJiraの構成要素を確認できます。
- [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：公表から修正までの流れの基礎です。
- [CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化](https://www.issoh.co.jp/tech/details/5092/)：CVEとNVD・KEVの関係を整理しています。
- [CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説](https://www.issoh.co.jp/tech/details/13277/)：臨時アドバイザリが続く製品を管理する回し方です。

---

出典: [Atlassian 脆弱性CVE-2026-21589：Jira・Confluenceの修正版と侵害確認の手順](<https://www.issoh.co.jp/tech/details/18839/>)（株式会社一創）