Atlassian の CVSS 9.3 ファイル読み取り脆弱性が悪用段階に。アドバイザリは 8 製品の全バージョンを影響対象と記載

Atlassian は 10 月 5 日、セルフホスト版製品 8 種に存在する任意ファイルアクセスの脆弱性についてセキュリティアドバイザリを公開した。10 月 7 日、BleepingComputer はこの脆弱性が実際に悪用されていると報じた。この 2 つの日付の間隔は 2 日だが、より重要な間隔はそれよりも短い。セキュリティ企業 Previdian は、公開された概念実証（PoC）が出てから約 2 時間で、自社のハニーポット網に悪用試行が到達したと述べている。

脆弱性は CVE-2026-21589 で、CVSS v4.0 で 9.3 と評価されている。認証もユーザー操作も特別な権限も必要としない。Atlassian 自身の説明は意図的に限定的だ。

この任意ファイルアクセスの脆弱性により、認証されていない攻撃者が、影響を受けるバージョンにおいてウェブアプリケーションのルートディレクトリ内の特定のファイルにアクセスできる。

限定的な表現が隠しているもの

文字どおりに読めば、これは明確な制約を伴うファイル漏えいのバグだ。攻撃者は目的のファイルの正確なパスを知っている必要がある。この脆弱性ではディレクトリ一覧を取得して探索することはできない。CVSS ベクターが機密性を高く、完全性と可用性を「なし」と評価しているのはこの制約があるためだ。何も書き込まれず、何も停止させられない。

同時に、スコアが中程度ではなく 9.3 のままである理由もそこにある。セルフホスト版の Atlassian 環境では、狙う価値のあるファイルパスは秘密ではない。どのインストールでも同じパスであり、ベンダー自身の資料に記載され、ソフトウェアのコピーを見れば分かる。Atlassian のアドバイザリと同時に技術分析を公開した watchTowr の研究者らは、アプリケーションルート内の既知の設定ファイルのパスを読み取るだけで、Atlassian の ID 管理製品と統合された環境では資格情報を取得して管理者権限に昇格できることを実証した。管理者アカウントを確実に手に入れられる「読み取り専用」のバグは、実務上は読み取り専用のバグではない。

CVSS ベクターの下流システムへの影響指標 — 下流システムの機密性・完全性・可用性がいずれも高 — は、採点側が同じことを言い換えたものだ。Jira と Confluence は、組織がチケットのコメントに資格情報を書き、Wiki ページにアーキテクチャを置き、ホスト名付きのインシデント時系列を残している場所である。Bitbucket はソースコードを置いている場所だ。ファイル読み取りは入口であり、目的であることはまれだ。

影響を受けるバージョンと修正バージョン

Atlassian は 8 製品すべてについて、リリース済みの全バージョンを影響対象として挙げている。据え置いたままで安全な旧ブランチは存在しない。

Atlassian Cloud の利用者は影響を受けない。ベンダーが自社のホスティング環境にパッチを適用済みで、顧客側の対応は不要だとしている。露出しているのはすべてセルフホストの環境、つまり Atlassian が Server ライセンスを終了して以降は Data Center の環境であり、それはまさに Cloud へ移行しないことを選んだ組織に集中している。規制産業、防衛関連企業、政府機関、そして Jira を自社のハードウェア上に置き続けるコンプライアンス上の理由を自ら抱える大企業だ。

2 時間という数字

Previdian のハニーポットのタイミングは、この一件で最も有用な事実であり、しかも Atlassian についての事実ではない。広く導入されたエンタープライズソフトウェアの認証不要な脆弱性に対する PoC が公開されると、それはいまや、たいていの変更管理プロセスが保守ウィンドウを設定できるよりも速くスキャントラフィックに変わる。2 時間では緊急パッチを変更審査会に通す時間はない。アドバイザリを読み終えるのがやっとだ。

これが、Atlassian がアドバイザリ本体より先に公開した補助的な緩和策の根拠である。緩和用のファイルは 10 月 2 日に公開されていた。ベンダーが挙げているのは、ネットワークレベルでの外部アクセス制限、トラバーサル形式のリクエストパスを拒否する WAF またはプロキシのルール、そして製品ごとの URL 書き換え — Confluence、Jira、Jira Service Management、Bamboo、Crowd には Tomcat の RewriteValve 設定、Bitbucket には urlrewrite.xml の変更だ。いずれもパッチ適用の代替にはならない。しかしいずれもパッチ適用より短い時間で展開できる。それが要点である。

取るべき対応

上記のバージョンへパッチを適用する。保守ウィンドウが数日先なら、その間は自社製品向けのベンダー緩和策を適用し、公開の必要がないインスタンスはインターネットから切り離す。そのうえでアクセスログを確認し、プラグインのリソースエンドポイントに対するトラバーサル形式のリクエストパスを探す。遡る起点は 10 月 7 日ではなく 10 月 2 日にすべきだ。PoC の公開は大規模スキャンが始まった時点であって、最初の誰かが気づき得た時点ではない。パッチ未適用でインターネットに面したインスタンスでは、アプリケーションルートから到達できる資格情報はすべて漏えいしたものとして扱い、ローテーションする。

この脆弱性は 10 月 6 日時点では CISA の Known Exploited Vulnerabilities カタログに登録されていなかった。ハニーポットのデータを踏まえれば、それは書類手続きが追いつくかどうかの問題にすぎない。

Sources: Atlassian security advisory: CVE-2026-21589 · BleepingComputer: Hackers exploit critical Atlassian flaw after public PoC release · BleepingComputer: Atlassian warns of critical file-access flaw in Jira, Confluence · watchTowr: Atlassian arbitrary file access vulnerability FAQ