情報取得日: 2026/08/27／最終確認: 2026/09/18・本ページは公開情報の非公式まとめです
| CVE ID | CVE-2026-59270 |
|---|---|
| 製品 | VMware (Spring) / Spring Security の組み込み UnboundID LDAP サーバ（UnboundIdContainer）。該当は 7.1.0 / 7.0.0〜7.0.6 / 6.5.0〜6.5.11 / 6.4.0〜6.4.18 / 5.8.0〜5.8.27 / 5.7.0〜5.7.25。修正版は 7.1.1・7.0.7（OSS）、6.5.12・6.4.19・5.8.28・5.7.26（Enterprise Support） |
| CVSS | 9.4（Critical） CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L |
| 種別 (CWE) | CWE-863 不適切な認可 |
| 登録／公開日 | 2026/08/27 |
| 出典 | https://nvd.nist.gov/vuln/detail/CVE-2026-59270 |
**Spring Security に同梱されている UnboundID の LDAP サーバ（`UnboundIdContainer`）が、管理者資格情報を無条件で登録し、待ち受けを全ネットワークインターフェースにバインドする。** NVD の記述は「unconditionally registers an administrative credential and binds its listener to all available network interfaces」である。 **何が起きるか。** Spring のアドバイザリによれば、**LDAP のリスナーポートに到達できる攻撃者は、既知の管理者資格情報を使ってディレクトリ内のエントリを読み書きできる**。資格情報が「既知」なのは、それがアプリケーション側の設定ではなくライブラリ側で無条件に登録されるものだからである。**推測する必要も総当たりする必要もない。** **「全インターフェースにバインドする」という部分が、影響範囲を決めている。** 組み込みの LDAP サーバは本来ローカルの試験・開発用で、localhost だけに出ていれば外からは触れない。ところが実際には 0.0.0.0 相当で待ち受けるため、**コンテナや VM の外へそのまま露出する**。Kubernetes の Pod でポートが Service 経由で出ていれば、クラスタ内の他の Pod からも届く。 **評価値は2つ出ている。** VMware（security@vmware.com）の CVSS 3.1 が **9.4**（AV:N/AC:L/PR:N/UI:N/S:U/**C:H/I:H/A:L**）、NVD（nvd@nist.gov）が **9.1**（同ベクタで **A:N**）である。可用性への影響をどう見るかだけの差で、**未認証・ネットワーク越し・機密性と完全性がともに High** という核心は一致している。CISA KEV には収載されていない（悪用の確認は公表されていない）。 **このサイトの掲載枠としては (A)（High/Critical かつ CVSS>=7.0）に該当する。**
各ベンダー公式アドバイザリで確認できた事実に基づき整理しています。確認できていない項目は「情報確認中」と明記し、存在しないパッチ番号・バージョンは記載しません。
| 環境 | 対応状況 | 対応方法・備考 |
|---|---|---|
| AWS (ECS/EC2) | パッチあり（アプリ更新） |
AWS 側の対処では直らない。**Spring Security を 7.1.1 / 7.0.7 以降（OSS）へ更新するか、組み込み LDAP サーバの利用をやめる。**
更新までのあいだは、EC2 のセキュリティグループ・ECS/EKS のセキュリティグループ・NetworkPolicy で LDAP の待ち受けポートへの到達元を絞る。ALB/NLB のターゲットグループに LDAP ポートが登録されていないかも確認する（検証時に足したまま残っていることがある）。VPC フローログで該当ポートへの外部からの接続を数えると、露出していたかどうかを事後に確認できる。
参照リンク
|
| GCP | パッチあり（アプリ更新） |
GCP 側の対処では直らない。**Spring Security を 7.1.1 / 7.0.7 以降（OSS）へ更新するか、組み込み LDAP サーバの利用をやめる。**
Compute Engine では VPC ファイアウォール規則、GKE では NetworkPolicy で LDAP ポートを絞る。Cloud Run で動かしている場合、公開されるのはコンテナの $PORT だけなので組み込み LDAP ポートは外から到達しないが、VPC 直接接続を使っていれば内部からは届く。VPC フローログで該当ポートへの接続を確認する。
参照リンク
|
| Azure | パッチあり（アプリ更新） |
Azure 側の対処では直らない。**Spring Security を 7.1.1 / 7.0.7 以降（OSS）へ更新するか、組み込み LDAP サーバの利用をやめる。**
ネットワークセキュリティグループ（NSG）または AKS の NetworkPolicy で LDAP ポートを絞る。Azure Spring Apps で動かしている場合も、アプリの依存に含まれていれば同じ問題が起きる。NSG フローログで該当ポートへの接続を確認する。
参照リンク
|
| Linux | パッチあり（アプリ更新） |
**OS のパッケージ更新では直らない。** これはアプリケーションが持ち込む Java ライブラリの問題である。ビルド設定側で Spring Security のバージョンを上げる。
該当しているかの確認は `mvn dependency:tree | grep -E 'spring-security|unboundid'` または `./gradlew dependencies | grep -E 'spring-security|unboundid'` で行う。稼働中のプロセスは `ss -lntp | grep java` で待ち受けポートを見る。緩和として `iptables` / `nftables` / `firewalld` で LDAP の待ち受けポートへの到達元を localhost に限定できるが、**資格情報が既知である以上、内部からの到達は塞げない**ことを前提に置く。
参照リンク
|
**まず「自分のアプリに組み込み LDAP が入っているか」を確かめる。** これが本件の分かれ目で、`UnboundIdContainer` は Spring Security の LDAP テスト支援機能であり、**本番構成では通常使われない**。つまり多くの環境では該当しない。一方で、次のような形で意図せず本番に残っていることがある。 - テスト用の LDAP 設定をプロファイルで切り替えているつもりが、既定プロファイルにも残っている - `spring-security-ldap` の依存が入っており、XML/Java 設定で `ldapServer`（embedded）を宣言している - デモ・検証用に立てた環境を、そのままインターネットから見える場所に置いている **確認方法は依存とポートの2方向から行う。** 依存は `./gradlew dependencies` または `mvn dependency:tree` で `unboundid-ldapsdk` が入っているかを見る。実行中のプロセスは、待ち受けポートを見るのが確実である。 ```bash ss -lntp | grep -E ':(389|33389|8389)\b' # あるいはプロセス単位で ss -lntp | grep java ``` **恒久対応は更新である。** Spring のアドバイザリは「該当バージョンの利用者は対応する修正版へアップグレードする。その他の追加対応は不要」としている。OSS で入手できるのは **7.1.1** と **7.0.7** で、**6.5.12 / 6.4.19 / 5.8.28 / 5.7.26 は Enterprise Support 向け**である。 **ここが実務上いちばん引っかかる点になる。** 5.7 系・5.8 系・6.4 系・6.5 系を使っていて商用サポート契約が無い場合、**修正版の入手経路が無い**。その場合は次のどちらかになる。 1. OSS で修正が入っている 7.0.7 / 7.1.1 系へ上げる（Spring Boot 側のバージョンも連動するので影響は小さくない） 2. 組み込み LDAP サーバを使うのをやめる（本番で使っていないなら設定ごと外す） **2 のほうが現実的なことが多い。** 本件は組み込みサーバそのものの問題であり、それを起動しなければ成立しない。外部の LDAP / Active Directory を向いている構成には影響しない。 **更新までの緩和は、到達経路を塞ぐことである。** LDAP の待ち受けポートへ外部から届かないように、ホストのファイアウォール・セキュリティグループ・NetworkPolicy のいずれかで絞る。**ただしこれは緩和であって修正ではない。** 資格情報が既知である以上、内部から到達できる相手には依然として読み書きされる。 **侵害の確認。** LDAP サーバのログを取っていれば、想定していないバインド（管理者 DN でのバインド）が記録されていないかを見る。組み込みサーバはログを残さない構成のことも多いので、その場合は**ネットワーク側の記録**（フローログ・ファイアウォールログ）で該当ポートへの外部からの接続があったかを確認する。ディレクトリの内容が書き換えられていないかは、アプリケーションの認証・認可の挙動と突き合わせて確かめる。
Critical（CVSS 9.4）に分類されるVMware (Spring) Spring Security の組み込み UnboundID LDAP サーバ（UnboundIdContainer）。該当は 7.1.0 / 7.0.0〜7.0.6 / 6.5.0〜6.5.11 / 6.4.0〜6.4.18 / 5.8.0〜5.8.27 / 5.7.0〜5.7.25。修正版は 7.1.1・7.0.7（OSS）、6.5.12・6.4.19・5.8.28・5.7.26（Enterprise Support）の脆弱性です。**Spring Security に同梱されている UnboundID の LDAP サーバ（`UnboundIdContainer`）が、管理者資格情報を無条件で登録し、待ち受けを全ネットワークインターフェースにバインドする。** NVD の記述は「unconditionally registers an administrative credential and binds its listener to all available network interfaces」である。 **何が起きるか。** Spring のアドバイザリによれば、**LDAP のリスナーポートに到達できる攻撃者は、既知の管理者資格情報を使ってディレクトリ内のエントリを読み書きできる**。資格情報が「既知」なのは、それがアプリケーション側の設定ではなくライブラリ側で無条件に登録されるものだからである。**推測する必要も総当たりする必要もない。** **「全インターフェースにバインドする」という部分が、影響範囲を決めている。** 組み込みの LDAP サーバは本来ローカルの試験・開発用で、localhost だけに出ていれば外からは触れない。ところが実際には 0.0.0.0 相当で待ち受けるため、**コンテナや VM の外へそのまま露出する**。Kubernetes の Pod でポートが Service 経由で出ていれば、クラスタ内の他の Pod からも届く。 **評価値は2つ出ている。** VMware（security@vmware.com）の CVSS 3.1 が **9.4**（AV:N/AC:L/PR:N/UI:N/S:U/**C:H/I:H/A:L**）、NVD（nvd@nist.gov）が **9.1**（同ベクタで **A:N**）である。可用性への影響をどう見るかだけの差で、**未認証・ネットワーク越し・機密性と完全性がともに High** という核心は一致している。CISA KEV には収載されていない（悪用の確認は公表されていない）。 **このサイトの掲載枠としては (A)（High/Critical かつ CVSS>=7.0）に該当する。**
**まず「自分のアプリに組み込み LDAP が入っているか」を確かめる。** これが本件の分かれ目で、`UnboundIdContainer` は Spring Security の LDAP テスト支援機能であり、**本番構成では通常使われない**。つまり多くの環境では該当しない。一方で、次のような形で意図せず本番に残っていることがある。 - テスト用の LDAP 設定をプロファイルで切り替えているつもりが、既定プロファイルにも残っている - `spring-security-ldap` の依存が入っており、XML/Java 設定で `ldapServer`（embedded）を宣言している - デモ・検証用に立てた環境を、そのままインターネットから見える場所に置いている **確認方法は依存とポートの2方向から行う。** 依存は `./gradlew dependencies` または `mvn dependency:tree` で `unboundid-ldapsdk` が入っているかを見る。実行中のプロセスは、待ち受けポートを見るのが確実である。 ```bash ss -lntp | grep -E ':(389|33389|8389)\b' # あるいはプロセス単位で ss -lntp | grep java ``` **恒久対応は更新である。** Spring のアドバイザリは「該当バージョンの利用者は対応する修正版へアップグレードする。その他の追加対応は不要」としている。OSS で入手できるのは **7.1.1** と **7.0.7** で、**6.5.12 / 6.4.19 / 5.8.28 / 5.7.26 は Enterprise Support 向け**である。 **ここが実務上いちばん引っかかる点になる。** 5.7 系・5.8 系・6.4 系・6.5 系を使っていて商用サポート契約が無い場合、**修正版の入手経路が無い**。その場合は次のどちらかになる。 1. OSS で修正が入っている 7.0.7 / 7.1.1 系へ上げる（Spring Boot 側のバージョンも連動するので影響は小さくない） 2. 組み込み LDAP サーバを使うのをやめる（本番で使っていないなら設定ごと外す） **2 のほうが現実的なことが多い。** 本件は組み込みサーバそのものの問題であり、それを起動しなければ成立しない。外部の LDAP / Active Directory を向いている構成には影響しない。 **更新までの緩和は、到達経路を塞ぐことである。** LDAP の待ち受けポートへ外部から届かないように、ホストのファイアウォール・セキュリティグループ・NetworkPolicy のいずれかで絞る。**ただしこれは緩和であって修正ではない。** 資格情報が既知である以上、内部から到達できる相手には依然として読み書きされる。 **侵害の確認。** LDAP サーバのログを取っていれば、想定していないバインド（管理者 DN でのバインド）が記録されていないかを見る。組み込みサーバはログを残さない構成のことも多いので、その場合は**ネットワーク側の記録**（フローログ・ファイアウォールログ）で該当ポートへの外部からの接続があったかを確認する。ディレクトリの内容が書き換えられていないかは、アプリケーションの認証・認可の挙動と突き合わせて確かめる。
VMware (Spring) Spring Security の組み込み UnboundID LDAP サーバ（UnboundIdContainer）。該当は 7.1.0 / 7.0.0〜7.0.6 / 6.5.0〜6.5.11 / 6.4.0〜6.4.18 / 5.8.0〜5.8.27 / 5.7.0〜5.7.25。修正版は 7.1.1・7.0.7（OSS）、6.5.12・6.4.19・5.8.28・5.7.26（Enterprise Support） を利用している場合、稼働バージョンが影響範囲に含まれるかを一次情報（https://nvd.nist.gov/vuln/detail/CVE-2026-59270）で確認してください。AWS・GCP・Azure・Linux それぞれの対応状況は本ページの「クラウド／OS 別の対応状況」表にまとめています。確認できていない項目は「情報確認中」と明記しており、存在しないパッチ番号・バージョンは記載していません。
本ページの記載は下記の一次情報に基づく非公式まとめです。数値・対応状況は各出典元で最終確認してください（最終確認: 2026/09/18）。