情報取得日: 2026/07/14／最終確認: 2026/08/10・本ページは公開情報の非公式まとめです
| CVE ID | CVE-2026-58319 |
|---|---|
| 製品 | Apache Software Foundation / Apache Doris 3.1.0 未満 |
| CVSS | 9.1（Critical） CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H |
| 種別 (CWE) | CWE-306（重要な機能に対する認証の欠如） |
| 登録／公開日 | 2026/07/14 |
| 出典 | https://nvd.nist.gov/vuln/detail/CVE-2026-58319 |
分析用データベース Apache Doris のフロントエンド（FE）が持つ HTTP の REST 管理 API の一部に、認証が掛かっていないものがある。 NVD の記述によれば、影響を受けるのは 3.1.0 より前のすべてのバージョンで、修正版は 3.1.0 である。FE の HTTP サービスにネットワーク到達できる未認証の攻撃者が、管理操作を無断で実行できる。結果としてクラスタの完全性と可用性が損なわれ、クラスタの不安定化やサービス停止に至り得るとされている。 前提を補足する。Apache Doris は MPP（超並列処理）型の分析データベースで、構成は FE（フロントエンド）と BE（バックエンド）に分かれる。**FE はメタデータの管理、SQL の解析と実行計画の作成、クラスタ全体の制御を担う頭脳にあたる部分**である。既定では 8030 番ポートで HTTP サービスを提供し、Web UI と REST API がここに載る。つまり今回の欠陥は、クラスタの制御面がそのまま露出するという話である。 CWE は CWE-306（重要な機能に対する認証の欠如）に分類されている。これは実装の細かなバグではなく、**認証を通すべき経路にそもそも認証チェックが置かれていない**という設計・実装上の欠落を指す分類である。攻撃に特殊な技術は要らず、該当するエンドポイントを知っていて到達できれば済む。 CVSS の内訳を読む。NVD の Primary（nvd@nist.gov）と Apache 側（134c704f-9b21-4f2e-91b3-4a467353bcc0）がともに CVSS 3.1 で 9.1（AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H）と評価しており、**両者の評価が一致している**。注目すべきは **C:N（機密性への影響なし）でありながら I:H / A:H（完全性・可用性への影響が高い）** という内訳で、これは「データを読み出される」よりも「**クラスタを壊される・止められる**」ほうが問題だという評価である。分析基盤が止まればレポートや ETL の下流がまとめて止まるので、業務影響は素直に大きい。 実務上の懸念は、Doris の FE がしばしば**社内ネットワークに置かれ、認証前提でない構成のまま運用されている**ことである。VPN の内側だから安全という運用は、内部からの到達（開発端末、踏み台、コンテナ間通信、別テナントのワークロード）を想定していないことが多い。 2026-08-09 時点で CISA KEV には収載されていない（KEV カタログ 2026.08.07 版で確認）。
各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。
| 環境 | 対応状況 | 対応方法・備考 |
|---|---|---|
| AWS (ECS/EC2) | パッチあり（アプリ更新） |
EC2 / EKS 上の Apache Doris を 3.1.0 以上へ更新する。あわせて FE の 8030 番ポートをセキュリティグループで管理元と BE に限定する
AWS のマネージド修正は無い。ALB / NLB を経由して FE を公開している場合は、公開を止めるか、前段で認証を掛ける。EKS では NetworkPolicy と Security Group for Pods を併用する。
参照リンク
|
| GCP | パッチあり（アプリ更新） |
GCE / GKE 上の Apache Doris を 3.1.0 以上へ更新し、FE の 8030 番ポートを VPC ファイアウォール規則で絞る
GCP 固有のパッチは無い。GKE では NetworkPolicy で FE Pod への ingress を BE と管理者の経路に限定する。外部 LB からの公開があれば外す。
参照リンク
|
| Azure | パッチあり（アプリ更新） |
VM / AKS 上の Apache Doris を 3.1.0 以上へ更新し、FE の 8030 番ポートを NSG で制限する
Azure 固有のパッチは無い。AKS では NetworkPolicy を有効にしたうえで FE への ingress を絞る。Application Gateway 経由で公開している場合は認証を前段に置く。
参照リンク
|
| Linux | パッチあり（アプリ更新） |
Apache Doris の配布物を 3.1.0 以上へ入れ替える。FE を先に更新してから BE を更新する
ディストリのパッケージ提供は無く、提供元の配布物での運用が通常。更新までは firewalld / nft / iptables で 8030 番への到達を管理元と BE に限定する。
参照リンク
|
**Apache Doris を 3.1.0 以上へ更新するのが恒久対応である。** 3.1.0 より前はすべて影響を受けるため、2.x 系を使っている場合は系列をまたぐアップグレードになる。FE と BE の互換性があるので、提供元のアップグレード手順（FE を先に上げる）に従うこと。 **更新までの緩和は、FE の HTTP ポートへの到達を絞ることに尽きる。** 認証が無い以上、アプリ側で止める手段が無いので、ネットワーク層で塞ぐのが唯一の実効的な策になる。具体的には、FE の HTTP ポート（既定 8030）を、BE と管理者が使う送信元アドレスだけに限定する。ファイアウォール、セキュリティグループ、Kubernetes の NetworkPolicy のいずれでもよい。**インターネットに直接出ている構成があれば最優先で塞ぐ。** もう一段の緩和として、FE の前段にリバースプロキシを置き、そこで Basic 認証や mTLS を掛ける方法がある。Doris 自身に認証を足せない以上、前段で通す/通さないを決めるしかない。ただしプロキシを迂回して 8030 に直接届く経路が残っていれば意味が無いので、**プロキシの導入とポートの遮断は必ずセットで行う**こと。 **事後の確認は FE の HTTP アクセスログで行う。** 管理系のエンドポイントに対する、想定外の送信元アドレスからのリクエストが無いかを見る。加えて、クラスタの状態そのものを確認する必要がある。バックエンドノードの追加・削除の履歴、テーブルやパーティションの削除、レプリカ数の変更、ロードジョブの異常終了を点検する。**完全性への影響が高いと評価されている以上、「止まっていないから被害は無い」とは言えない。** メタデータの変更履歴と、直近のバックアップとの突き合わせまで行うのが安全である。
Critical（CVSS 9.1）に分類されるApache Software Foundation Apache Doris 3.1.0 未満の脆弱性です。分析用データベース Apache Doris のフロントエンド（FE）が持つ HTTP の REST 管理 API の一部に、認証が掛かっていないものがある。 NVD の記述によれば、影響を受けるのは 3.1.0 より前のすべてのバージョンで、修正版は 3.1.0 である。FE の HTTP サービスにネットワーク到達できる未認証の攻撃者が、管理操作を無断で実行できる。結果としてクラスタの完全性と可用性が損なわれ、クラスタの不安定化やサービス停止に至り得るとされている。 前提を補足する。Apache Doris は MPP（超並列処理）型の分析データベースで、構成は FE（フロントエンド）と BE（バックエンド）に分かれる。**FE はメタデータの管理、SQL の解析と実行計画の作成、クラスタ全体の制御を担う頭脳にあたる部分**である。既定では 8030 番ポートで HTTP サービスを提供し、Web UI と REST API がここに載る。つまり今回の欠陥は、クラスタの制御面がそのまま露出するという話である。 CWE は CWE-306（重要な機能に対する認証の欠如）に分類されている。これは実装の細かなバグではなく、**認証を通すべき経路にそもそも認証チェックが置かれていない**という設計・実装上の欠落を指す分類である。攻撃に特殊な技術は要らず、該当するエンドポイントを知っていて到達できれば済む。 CVSS の内訳を読む。NVD の Primary（nvd@nist.gov）と Apache 側（134c704f-9b21-4f2e-91b3-4a467353bcc0）がともに CVSS 3.1 で 9.1（AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H）と評価しており、**両者の評価が一致している**。注目すべきは **C:N（機密性への影響なし）でありながら I:H / A:H（完全性・可用性への影響が高い）** という内訳で、これは「データを読み出される」よりも「**クラスタを壊される・止められる**」ほうが問題だという評価である。分析基盤が止まればレポートや ETL の下流がまとめて止まるので、業務影響は素直に大きい。 実務上の懸念は、Doris の FE がしばしば**社内ネットワークに置かれ、認証前提でない構成のまま運用されている**ことである。VPN の内側だから安全という運用は、内部からの到達（開発端末、踏み台、コンテナ間通信、別テナントのワークロード）を想定していないことが多い。 2026-08-09 時点で CISA KEV には収載されていない（KEV カタログ 2026.08.07 版で確認）。
**Apache Doris を 3.1.0 以上へ更新するのが恒久対応である。** 3.1.0 より前はすべて影響を受けるため、2.x 系を使っている場合は系列をまたぐアップグレードになる。FE と BE の互換性があるので、提供元のアップグレード手順（FE を先に上げる）に従うこと。 **更新までの緩和は、FE の HTTP ポートへの到達を絞ることに尽きる。** 認証が無い以上、アプリ側で止める手段が無いので、ネットワーク層で塞ぐのが唯一の実効的な策になる。具体的には、FE の HTTP ポート（既定 8030）を、BE と管理者が使う送信元アドレスだけに限定する。ファイアウォール、セキュリティグループ、Kubernetes の NetworkPolicy のいずれでもよい。**インターネットに直接出ている構成があれば最優先で塞ぐ。** もう一段の緩和として、FE の前段にリバースプロキシを置き、そこで Basic 認証や mTLS を掛ける方法がある。Doris 自身に認証を足せない以上、前段で通す/通さないを決めるしかない。ただしプロキシを迂回して 8030 に直接届く経路が残っていれば意味が無いので、**プロキシの導入とポートの遮断は必ずセットで行う**こと。 **事後の確認は FE の HTTP アクセスログで行う。** 管理系のエンドポイントに対する、想定外の送信元アドレスからのリクエストが無いかを見る。加えて、クラスタの状態そのものを確認する必要がある。バックエンドノードの追加・削除の履歴、テーブルやパーティションの削除、レプリカ数の変更、ロードジョブの異常終了を点検する。**完全性への影響が高いと評価されている以上、「止まっていないから被害は無い」とは言えない。** メタデータの変更履歴と、直近のバックアップとの突き合わせまで行うのが安全である。
Apache Software Foundation Apache Doris 3.1.0 未満 を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-58319）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。
本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください（最終確認: 2026/08/10）。