【ITニュース解説】Eight Atlassian Data Center Products Share One File-Read Flaw and One Patch Clock

最近、IT業界で広く使われているAtlassianのデータセンター製品群において、非常に深刻なセキュリティ上の問題が明らかになった。これは、企業が自社のサーバーで運用するAtlassian製品、具体的にはBitbucket、Confluence、Jira Service Management、Jira Software、Bamboo、Crowd、Crucible、Fisheyeといった8つの重要なコラボレーションソフトウェア全てに影響を与える「ファイル読み取りの脆弱性」である。

この脆弱性は「CVE-2026-21589」と識別され、その深刻度は国際的な評価基準であるCVSS 4.0で9.3という非常に高いスコアが付けられ、「クリティカル」と評価された。これは、攻撃者がインターネット経由で認証情報なしに、かつユーザーの操作を一切必要とせずに攻撃を実行できることを意味する。つまり、誰もがアクセスできる状態で、特別な権限がなくても攻撃が可能だということだ。

この脆弱性の本質は、攻撃者がWebアプリケーションのルートディレクトリ内にある特定のファイルを読み取れる点にある。単にファイルの中身が見えるだけでなく、そのファイルにシステム設定や認証情報などの機密情報が含まれていれば、それが盗み取られる危険性がある。この問題の根源は、Atlassian製品群で共通して利用されている「atlassian-plugins-webresource」というウェブライブラリの古いバージョン（6.0.7以前）にある不具合だ。

具体的には、このライブラリ内のルーティングを処理する部分に欠陥があり、リクエストに含まれる「::」（二重コロン）という文字列が、システム内部で「/」（スラッシュ）に誤って変換されてしまう。これを利用して、攻撃者はWebサイトのアドレス（URL）に「::」を巧妙に含めることで、本来アクセスできないはずのディレクトリ（フォルダ）にあるファイルにアクセスできてしまう。このような攻撃は「ディレクトリトラバーサル攻撃」と呼ばれ、システム内の機密ファイルに到達する手段となる。この共通ライブラリの利用が原因で、前述の8つの製品全てが同じ脆弱性を持ってしまったのだ。

このファイル読み取りの脆弱性は、単なる情報漏洩以上の深刻な結果を招く可能性がある。特に、Atlassianの集中型ユーザー管理システムである「Crowd」と連携している環境では、読み取られたファイルの中にCrowdの認証情報（ユーザー名やパスワード）が含まれているケースがある。セキュリティ研究機関が実際にこの脆弱性を検証したところ、Confluence、Jira、BitbucketのシステムからCrowdの認証情報を入手し、それを使って管理者権限を持つユーザーをシステム内に作成できることを実証した。これは、攻撃者が企業の重要なコラボレーションシステムを完全に制御できる状態に到達することを意味する。ソースコードリポジトリ、社内ドキュメント、プロジェクト管理情報、さらには社員のID情報など、企業の中核をなす情報が保管されているシステムが乗っ取られることは、組織にとって極めて大きなリスクとなる。

ただし、この攻撃にはいくつかの条件があることも理解しておくべきだ。攻撃者は読み取りたいファイルの正確な名前とパスを事前に知っている必要がある。この脆弱性だけでは、ディレクトリの内容を一覧表示する（ファイルリストを見る）ことはできない。また、Tomcatアプリケーションコンテキストという、Webアプリケーションが動作する範囲内でのみディレクトリトラバーサルが可能で、それより上位のシステム領域にはアクセスできない。さらに、Crowdのインストール自体がIPアドレスでアクセスを制限している場合、最終的な管理者権限奪取はより難しくなる。しかし、これらの制約があったとしても、認証情報が漏洩し、管理者権限が奪われる可能性は依然として極めて高い。

この脆弱性に関する情報が公になった後の展開は非常に迅速だった。Atlassianが脆弱性に関するアドバイザリ（警告）を2026年10月5日に公開した時点では、「現時点では攻撃の証拠は見つかっていない」と発表されていた。しかし、そのわずか2日後の10月7日には、脆弱性の詳細な技術解説と、実際に攻撃を実行できる「概念実証コード（PoC）」が一般に公開された。驚くべきことに、PoCが公開されてからわずか2時間以内に、インターネット上のハニーポットネットワーク（攻撃を誘い込み監視するおとりシステム）が、この脆弱性を悪用しようとする試みを記録した。

これは、セキュリティコミュニティや悪意のある攻撃者が、公開された脆弱性情報にどれほど迅速に反応するかを示す典型的な例である。詳細な説明とPoCが公開されると、それを基に簡単に攻撃を試すツールが作成され、広範囲なインターネットスキャンが行われるようになる。Atlassian自身も、個々の顧客のシステムが実際に攻撃を受けたかどうかを特定することはできないため、この脆弱性の検出と対処の責任はシステムを運用する各企業に委ねられている。

企業が取るべき対策として、まず重要なのは自社システムが影響を受けているかどうかを「検出」することだ。具体的には、システムのアクセスログを定期的に確認し、特定の攻撃パターンを探す必要がある。例えば、URLエンコードされた「../」（親ディレクトリへの移動）や「::」（二重コロン）のような文字列が含まれるリクエストがないかを調べる。もしそのようなパターンが見つかった場合は、それはファイルが読み取られた可能性が高いと考え、実際の被害があったものとして対処する必要がある。

すぐにシステムをアップグレードできない場合の「一時的な緩和策」もいくつか存在する。一つはWAF（Web Application Firewall）やプロキシサーバーと呼ばれるセキュリティ機器やソフトウェアを使って、ディレクトリトラバーサル攻撃に使われる特定のパターンをネットワークの入り口でブロックする方法だ。これは影響を受ける全ての8製品に有効である。また、5つの製品（Bitbucket, Confluence, Jira Service Management, Jira Software, Bamboo）については、TomcatというWebサーバーの機能であるRewriteValveを使って、不正なリクエストをブロックするルールを設定することもできる。Bitbucketにはurlrewrite.xmlという設定ファイルで同様のルールを適用する方法がある。これらのルールを適用した場合は、クラスタ内の全てのノードやミラーノードといった関連するサーバーに適用し、システムを再起動する必要がある。CrucibleとFisheyeはWAFやプロキシによる対応が主な手段となる。

この脆弱性に対する最も確実な解決策は、脆弱性が修正された新しいバージョンへの「アップグレード」である。しかし、Atlassianはセキュリティ上の修正を個別の「バイナリパッチ」として提供するのではなく、新しい「メンテナンスリリース」という形で提供している。これは、パッチの適用が実質的にシステム全体をアップグレードするプロジェクトになることを意味する。そのため、企業はシステムのテスト期間を設け、万が一問題が発生した場合に元に戻せるようロールバック計画を立て、責任者を割り当てるなど、単なるソフトウェア更新以上の労力を要する。

また、システムがログインページで保護されている場合でも、今回の脆弱性は認証不要で攻撃可能であるため、対策が必須だ。さらに、すでにサポートが終了している（EOL）製品バージョンもこの脆弱性の影響を受けるため、そのようなシステムを運用している企業は、修正パッチが提供されないことから、システムの移行を真剣に検討する必要がある。

自己ホスト型ソフトウェアを運用することには、データや設定を自社で完全にコントロールできるという大きな利点がある。しかし、今回の件のように、セキュリティパッチの適用スケジュールやリスク管理の責任も全て自社で負うことになる。クラウドサービスであればベンダーが迅速に修正を適用してくれるが、自社サーバーの場合は、アドバイザリ公開から実際に修正を適用するまでの期間が、攻撃者にとっての「窓」となる。この脆弱性において、その窓がわずか2日間であったという事実は、現代のサイバーセキュリティ環境の厳しさを物語っている。

システムエンジニアを目指す上では、このような脅威からシステムを守るための知識と対応力が不可欠となる。日頃から、自社のシステムでどのサービスが外部からアクセス可能になっているか、どのような情報資産が管理されているかを正確に把握し、セキュリティに関する情報（アドバイザリなど）を常にチェックすることが重要である。そして、脆弱性が公開された際には、迅速に影響度を評価し、適切な対策を実行に移す計画と体制を整えておく必要がある。