オープンソースのアイデンティティ管理基盤「OpenAM」の開発を担う Open Identity Platform は、2026年6月17日にセキュリティアップデートとなる「16.1.1」を公開しました。今回のリリースでは計62件の脆弱性に対処しており、中にはCVSS9.3（緊急）の反射型クロスサイトスクリプティング（XSS）も含まれます。OpenAMをSSO（シングルサインオン）やOAuth/OpenID Connectの認証基盤として使っている組織は、影響範囲を確認のうえ早期のバージョン更新を検討すべきです。
本記事では、情シスが「自社は影響を受けるか」「何を優先すべきか」を短時間で判断できるよう、主要な脆弱性と現場での勘所を整理します。
この記事でわかること
- OpenAM 16.1.1で修正された主要な脆弱性（CVE番号・深刻度・影響範囲）
- 「ID基盤の脆弱性」がなぜ優先度が高いのか
- 情シスが今すぐ確認すべきこと、運用上の落とし穴
何が起きたのか
OpenAMは、ForgeRock社が商用化する前のオープンソース版を引き継いで開発が続けられているID管理基盤です。SAML・OAuth 2.0・OpenID Connect（OIDC）といった認証連携を担い、社内外システムのSSO基盤として利用されています。今回の16.1.1は、この基盤に潜んでいた多数の脆弱性をまとめて修正するリリースです。
とくに注目すべきは、認証・認可の入口そのものに存在する2件の脆弱性です。
CVE-2026-44203：OAuth2/OIDC認可エンドポイントの反射型XSS（CVSS 9.3・緊急）
OAuth 2.0／OpenID Connectの認可エンドポイントが、form_postレスポンスモード用に生成するHTMLへ、利用者が渡したパラメータを十分にサニタイズせず埋め込んでしまう問題です。攻撃者がOpenAMのオリジン（信頼された認証ドメイン）上でスクリプトを実行させられる可能性があり、CWE-79（クロスサイトスクリプティング）に分類されます。影響を受けるのは13.0.0〜16.1.0で、16.1.1で修正されました。
認証基盤のドメインでXSSが成立する点が厄介です。利用者が「正規のログイン画面」と信じている画面でスクリプトが動くため、セッションや認可コード、トークンの窃取につながりやすく、フィッシングよりも気づかれにくい攻撃に発展しかねません。
CVE-2026-41573：REST APIのLDAPインジェクション（CVSS 8.7・高）
CREST（REST）APIのユーザー／グループ検索エンドポイントで、_queryIdパラメータがエスケープされないままLDAPフィルタに連結される問題です。認証済みの攻撃者が任意のLDAPメタ文字を注入することで、ユーザー列挙やブラインドLDAPインジェクションが可能になります（CWE-74）。影響を受けるのは16.0.6以前で、16.1.1で修正されています。
「認証が必要」とはいえ、一般利用者の認証情報が手に入れば悪用できるため、内部不正や侵害済みアカウントからの横展開を考えると軽視できません。
主要な脆弱性の一覧
| CVE | 種類 | CVSS／深刻度 | 影響バージョン | 備考 |
|---|---|---|---|---|
| CVE-2026-44203 | 反射型XSS（OAuth2/OIDC） | 9.3／緊急 | 13.0.0〜16.1.0 | 認可エンドポイント |
| CVE-2026-41573 | LDAPインジェクション（REST API） | 8.7／高 | 16.0.6以前 | 要認証・ユーザー列挙 |
| CVE-2026-44202 ほか | SSRF・XSS等を含む多数 | — | 16.1.0以前ほか | 計62件をまとめて修正 |
このほか、Netty・Apache Cassandra・lodash・React Router・Viteなど依存ライブラリ側の脆弱性にも対応しています。個別CVEを一つずつ追うより、最新版へ更新することでまとめて手当てするのが現実的です。
なぜ「ID基盤の脆弱性」は優先度が高いのか
結論から言えば、ID基盤は侵害された際の被害範囲が全社に及ぶからです。SSOやIdP（IDプロバイダー）は、その性質上ネット境界に面して公開されることが多く、攻撃者にとっては「ここを抜けば連携先すべてに手が届く」関所です。
OpenAMはこれまでにも、認証前に悪用可能なリモートコード実行（RCE）が報告されてきた経緯があります（例: jato.clientSessionのデシリアライズによるCVE-2026-33439、CVSS9.3、16.0.6で修正）。ID基盤は「動いているから触りたくない」と更新が後回しになりがちですが、放置が最も危険な領域でもあります。
現場目線の課題
正直なところ、ID基盤のパッチ適用は「やるべきと分かっていても手を出しにくい」典型例です。停止すれば全社のログインが止まるため、メンテナンス時間の確保や、認証連携先（SAML/OIDCクライアント）での回帰テストが避けられません。検証環境を持っていない、あるいは構築当時の担当者が異動して内部構成がブラックボックス化している、という現場も珍しくないでしょう。
もう一つの落とし穴がバージョンの取り違えです。OpenAMは「ForgeRock社の商用AM」と「Open Identity PlatformのオープンソースOpenAM」が混在して語られがちで、自社が動かしているのがどちらの系譜のどのバージョンなのかを正確に把握できていないと、適切なパッチにたどり着けません。まずは現行バージョンと提供元を棚卸しすることが出発点になります。
情シスはどうすべきか
個別の対策手順を長々と並べるより、一次情報と公的指針に沿って動くのが堅実です。
- 現行バージョンと提供元を確認し、影響範囲（13.0.0〜16.1.0など）に該当するか棚卸しする。
- 検証環境で16.1.1への更新を計画し、認証連携先での回帰テストとメンテナンス時間を確保する。
- すぐに更新できない場合は、認可エンドポイントやREST APIの公開範囲・アクセス制御を見直し、不要な外部公開を絞る。
脆弱性管理やインシデント対応の体制づくりについては、IPAの公的資料が参考になります。たとえば中小企業の情報セキュリティ対策ガイドラインや、セキュリティインシデント対応 机上演習教材は、平時の備えと有事の動き方を整理するうえで使いどころがあります。日々の運用では、利用者への啓発を含む地道な対策の積み重ねが効いてきます。
まとめ
- OpenAM 16.1.1（2026年6月17日公開）は計62件の脆弱性を修正。CVSS9.3の反射型XSS（CVE-2026-44203）やLDAPインジェクション（CVE-2026-41573）を含む。
- ID基盤は侵害時の被害が全社に及ぶため、更新が後回しになりやすい一方で優先度は高い。
- まずは現行バージョンと提供元を棚卸しし、検証環境で16.1.1への更新を計画する。すぐ更新できなければ公開範囲とアクセス制御を見直す。
