Atlassian、JiraとConfluenceの重大度の高い脆弱性を修正

Atlassianは、JiraやConfluenceをはじめとする企業向け製品のセキュリティ修正をリリースしました。対象は、同社ソフトウェア全体で176件の脆弱性エントリに及びます。

10月20日に公開されたセキュリティ情報は、直近1か月間に複数のセルフマネージド製品向けにリリースされた修正をまとめたものです。影響を受けるサードパーティ製コンポーネントの一部には「クリティカル」の深刻度が付けられていますが、Atlassianは自社アプリケーション内でのリスクを「クリティカルではない」と評価しています。対象バージョンを運用している組織は、更新が必要な環境がどれかを確認してください。

最も深刻な問題の一部は、企業システムへの不正な接続を防ぐソフトウェアコンポーネントに影響します。

サーバーアクセスと証明書検証に影響する脆弱性

評価の高い問題のいくつかは、安全な接続の管理に使われているサードパーティ製ソフトウェアライブラリに関わるものです。Atlassianのセキュリティ情報では、注目すべき3件の脆弱性が挙げられています。スコアは同情報に記載されたものです。

• Apache Tomcatの脆弱性CVE-2026-65637（9.8）。ConfluenceとCrowdに影響し、特定のHTTP/2リクエストに対するServer Name Indication（SNI）の厳格な検証を回避される恐れがあります。
• Bouncy Castleの脆弱性CVE-2026-58062（9.3）。このコンポーネントが一致しない証明書ステータス応答を受け取ると、証明書の検証不備により、失効した証明書が有効と判断されることがあります。Atlassianは、影響を受ける製品としてJira Software、Jira Service Management、Confluence、Crowdを挙げています。
• Nettyの脆弱性CVE-2026-75595（9.1）。認証がSNIベースの設定のみに依存し、フォールバック設定が証明書なしの接続を許可していて、アプリケーション側で追加の証明書検証も行っていない場合、このネットワークコンポーネントでは 攻撃者がクライアント証明書認証を回避できる可能性があります。

そのほかには、リモートコード実行やサービス拒否（DoS）に関わる脆弱性も含まれます。全体のうち162件は重大度が「高」で、14件はクリティカルと評価されたサードパーティ製コンポーネントに関するものです。一部のCVEは複数の製品にまたがって記載されています。 

Atlassianは、これらコンポーネント自体のスコアは高いものの、自社アプリケーション内での影響はクリティカルではないと判断しています。

サポート対象のData Center製品向けに修正版を提供

推奨される更新バージョンは、製品やリリースブランチによって異なります。10月20日付のセキュリティ情報では次のバージョンが推奨されています。管理者は、展開前に最新のリリースノートとアップグレード要件を確認してください。

それ以外のリリースブランチを使用している環境については、Atlassianの 脆弱性情報開示ポータルに、影響を受けるバージョンと利用可能な修正が掲載されています。

古いServer版には、別の問題があります。JiraやConfluenceをはじめ、ほとんどのServer製品は2024年2月にセキュリティ修正の提供が終了しており、これらの環境にはサポート対象のパッチがありません。FisheyeとCrucibleは2028年5月までサポートが続きます。

1つの更新漏れが脆弱性を残す恐れ

Jiraには、セキュリティ対応の割り当てや完了に使うチケットが集まっていることが多く、Jira Service ManagementはITインシデント対応を支え、Confluenceは社内の対応手順を保管しています。 

これらのアプリケーションは、同じ脆弱なソフトウェアコンポーネントを含んでいても、別々のチームが管理していることがあります。そのため、Jiraのセキュリティチケットが完了していても、影響を受けるConfluenceやCrowdが古いバージョンのまま稼働していれば、管理者は状況を正確に把握できません。

セキュリティ責任者は、影響を受ける環境ごとに 脆弱性管理の記録で個別に追跡する必要があります。共通のCVEは、脆弱なバージョンが実際に稼働しているサーバーと突き合わせ、担当の製品オーナーが各更新を確認します。適切な パッチ適用の検証とは、展開後に稼働しているソフトウェアのバージョンを確認してから、問題が解決したと判断することです。クラスター構成の場合は、すべてのノードを確認し、その結果を対象環境ごとに記録してください。

サポート対象外のServer環境については、サポート対象のプラットフォームへ移行するための担当者と期限を決めてください。移行までの間はアクセスを制限し、その対策は完全な修正ではなく、一時的なリスク低減策として記録します。

IT業務に欠かせない古い環境が脆弱なまま、通常のセキュリティサポートの対象外に残っていれば、パッチ適用完了の報告があっても、安全性の裏付けにはほとんどなりません。

サイバーセキュリティのその他のニュース：GitLabは今月2件目となる深刻度10.0のリモートコード実行の脆弱性を公表し、管理者は再び緊急のセキュリティ更新への対応を迫られています。