OpenAMの脆弱性CVE-2026-123551：16.1.4への更新と遮断の手順

OpenAM 14.0.0以上16.1.4未満では、認証していない攻撃者が通知用のWebSocketから利用者のセッショントークンを読み取れます。CVE-2026-123551として登録され、CVSSは10.0です。奪われるのは管理者を含むログイン状態そのもので、OpenAMにつないだ業務システムすべてに影響が及びます。この記事では2026年11月10日時点の一次情報をもとに、対象の見分け方、更新までの暫定遮断、セッション失効とログ調査、16.1.4で壊れやすい設定を実装者向けに整理します。

まとめ：OpenAM 14.0以降は16.1.4へ更新、通知WebSocketは当日遮断

Open Identity Platform版の14.0.0以降を使っているなら、更新の日程が決まる前に、通知WebSocketと旧Liberty ID-FFのURLをリバースプロキシで閉じてください。既定の設定のままで条件を満たすため、「該当機能を使っていない」という逃げ道はありません。

次に、発行済みのセッションは漏れた前提で扱います。受動的に集める攻撃なのでログイン失敗の記録が残らず、被害がないことを証明できないからです。OpenAMを外部へ公開していた環境では、更新と同じ作業枠で管理者の認証情報も交換します。

16.1.4では同じ日に18件のアドバイザリが公開されました。今回のCVEだけを個別に塞ぐ手段はないので、更新先は16.1.4以上の一択です。公開範囲の確認から手が回らない場合は、脆弱性診断・セキュリティ診断で外から届くURLの棚卸しを先に済ませると、遮断の漏れを防げます。

CVE-2026-123551で漏れるセッショントークンと攻撃の成立条件

公式のアドバイザリは技術的な詳細と検証コードを意図的に伏せています。確定している範囲で、影響の大きさを見積もります。

NVDとGHSAで確定している対象版・CVSS 10.0・修正版の一覧

NVDの登録とGitHubのアドバイザリGHSA-5c3q-hp86-xjr8は同じ問題を指しています。

CVSSの値はCNAであるVulnCheckの評価で、NVD自身の分析はまだ付いていません。注意したいのは日付の差です。アドバイザリと修正版は10月22日に出ましたが、CVEの公開は11月8日でした。CVE番号を基準に動く脆弱性管理では、約17日遅れて初めて検知します。

通知WebSocketと旧Liberty ID-FFの内部転送が組み合わさる仕組み

原因は2つの弱点の組み合わせです。1つ目として、OpenAMはエージェント通知の話題に、セッションの作成やログアウトのたびにiPlanetDirectoryProの値を丸ごと流していました。エージェント通知は既定で有効です。

2つ目は入口の問題です。WebSocketはポリシーエージェント専用のはずが、旧Liberty ID-FFのエンドポイントにある検証不足の内部転送を経由すると、そのチェックを通らずに接続できました。接続後は内部用を含む任意の話題を購読できたとされています。

16.1.4の修正は3点です。セキュリティフィルターを内部転送にも適用し、ID-FFから内部エンドポイントへの転送をやめ、WebSocketの購読先を/agent/配下に限定しました。

ログイン失敗が残らない受動収集で被害の有無を断定できない理由

攻撃者は接続を張ったまま待つだけで足ります。接続中にセッションが作られた、変わった、終わった利用者のトークンが届きます。アドバイザリによれば、認証の試行もログイン失敗もアカウントロックも発生せず、奪ったトークンでの操作は本人の操作と区別できません。

管理者のセッションが取られると、設定の乗っ取りを経てOpenAMの実行アカウントでのコマンド実行に至る可能性があります。さらにシングルサインオンの性質上、トークンは連携先のアプリケーションでもそのまま通用します。

悪用報告とPoCの公開状況、2026年11月10日時点の未確認事項

CISAのKEVカタログの2026年11月6日版に、Open Identity Platform版OpenAMの掲載はありません。

今回のCVEが実際に悪用されたという公表は、確認できていません。ただし同時に公開されたGHSA-hvfc-4v4r-8p9wには、既知の初期パスワードを持つ内蔵アカウントが古い版の実環境への侵入の入口になった、という報告が記されています。OpenAMを狙う攻撃者は実在します。KEV未掲載を、待ってよい理由にはしないでください。検証コードの公開が優先度をどう変えるかはexploitとPoCの違いと悪用状況の確認手順が参考になります。

自社のOpenAMが対象か判定する配布系統と稼働版の確認手順

「OpenAM」と呼ばれる製品は複数の系統に分かれており、版番号だけでは判定できません。以下のコマンドは公式の配布物と記載をもとに書いたもので、検証環境での実行結果ではありません。

Open Identity Platform版・Consortium版・商用AMの判別表

NVDの影響範囲に記載されたパッケージは、いずれもorg.openidentityplatform.openamのものです。

紛らわしいのはConsortium版です。版番号は14.0系で、数字だけなら対象範囲に入って見えます。2026年11月5日公開の14.0.6のソースを確認したところ、openam-notifications-websocketモジュールもNotificationsWebSocketFilterの定義もありませんでした。リリースノートに修正内容の記載はなく、同じコード系統の別の問題まで無関係とは断定できません。公式の見解は提供元に確かめてください。

WAR内のjar名とDockerイメージから稼働版を特定する確認コマンド

16.1.4のOpenAM-ServerOnly-16.1.4.warには、openam-core-16.1.4.jarとopenam-notifications-websocket-16.1.4.jarが同梱されています。配備先のjar名を見れば、系統と版を同時に判別できます。

# Tomcatに展開済みの環境（配備名がopenam以外なら置き換える）
ls "$CATALINA_HOME/webapps/openam/WEB-INF/lib" \
  | grep -E '^openam-(core|notifications-websocket)-'

# WARファイルのまま確認する場合
unzip -l openam.war | grep 'WEB-INF/lib/openam-notifications-websocket-'

# 公式Dockerイメージ（コンテナ名は環境に合わせる）
docker exec openam-01 ls /usr/local/tomcat/webapps/openam/WEB-INF/lib \
  | grep '^openam-core-'

openam-notifications-websocketのjarがあり、版が16.1.4より小さければ対象です。配備先のパスは公式のDockerfileにあるCATALINA_HOMEとOPENAM_PATHの既定値です。

16.1.4を当てるまでの暫定遮断：nginxとサーバープロパティの設定

更新には検証の時間がかかります。アドバイザリが示す回避策のうち、当日に入れられるものから順に適用します。

通知WebSocketをエージェントのIPに絞りID-FFを閉じるnginx設定

アドバイザリの回避策の1番目は/openam/notificationsと/openam/ws/*の接続元制限で、3番目が旧ID-FFのURLの遮断です。ここは両方を入れてください。内部転送の入口はID-FF側のURLにあるので、通知のパスだけに掛けた制限では入口を閉じられない可能性があります。これはアドバイザリの記述からの推論で、詳細が伏せられている以上、片方で足りるとは判断できません。

# serverブロックの中に置く。10.0.2.11はエージェントのアドレスの例
if ($request_uri ~ ";") { return 400; }

location ^~ /openam/notifications {
    allow 10.0.2.11;
    deny  all;
    proxy_pass http://openam_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}
location ^~ /openam/ws/ {
    allow 10.0.2.11;
    deny  all;
    proxy_pass http://openam_backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

# Liberty ID-FFを使っていない場合のみ
location = /openam/preLogin        { return 403; }
location ^~ /openam/postLogin      { return 403; }
location ^~ /openam/SOAPReceiver   { return 403; }
location ^~ /openam/ProcessLogout  { return 403; }
location ^~ /openam/ProcessRegistration { return 403; }
location ^~ /openam/ProcessTermination  { return 403; }

ID-FFのパスは16.1.4のweb.xmlと公式のアップグレードガイドの記載から拾いました。セミコロンの拒否は、Javaのサーブレットコンテナがパスパラメータを解釈して、プロキシと見え方がずれるのを防ぐためです。;jsessionidをURLに載せる古いエージェントがある場合は、先にログで確かめてください。nginxのallowとdenyは上から順に評価され、最初の一致で止まります。

プロキシの設定だけでは、Tomcatの8080番へ直接届く経路は塞げません。セキュリティグループやファイアウォールで、待ち受けポートをプロキシからの接続に限定します。

エージェント通知を止めるプロパティの副作用とID-FF遮断の可否

エージェントが通知に依存していない環境では、サーバーの詳細設定（Advanced）でorg.forgerock.openam.notifications.agents.enabledをfalseにすると、セッションIDの配信自体が止まります。

代償は反映の遅れで、エージェントはセッションやポリシーの変更をキャッシュの期限切れまで知りません。ログアウトした利用者が、しばらく連携先のアプリケーションに残ります。キャッシュの期限を短くできない業務では採用せず、接続元の制限で対応してください。反映に再起動が必要かはアドバイザリに記載がないため、変更後の再起動を作業に含めておくと確実です。

社外回線のcurlで遮断の効果と直接接続の可否を実測する確認手順

社内のアドレスから試すと、許可設定に隠れて結果を読み違えます。テザリングなど社外の回線から、自社が管理するホストだけを対象に実行してください。

HOST=sso.example.jp
for p in notifications ws/ preLogin postLogin/ SOAPReceiver ProcessLogout/; do
  curl -s -o /dev/null -m 10 -w "%{http_code} ${p}\n" "https://${HOST}/openam/${p}"
done

# Tomcatのポートが直接開いていないことも確かめる
curl -s -o /dev/null -m 5 -w "%{http_code}\n" "http://${HOST}:8080/openam/"

すべて403、404、または接続失敗（000）なら遮断できています。これは入口の到達性だけを見る確認で、脆弱性の有無を判定するものではありません。

侵害を前提に進めるセッション失効とログ調査、連携先への波及確認

公開環境で動いていたなら、遮断が済んだ時点ですでに読み取られていた前提で動きます。アドバイザリも、現行のセッションは漏えいの可能性があるものとして扱うよう勧めています。

再起動だけに頼らないセッション破棄と管理者認証情報の交換順序

再起動すれば全員ログアウトされる、とは限りません。セッション状態の公式ドキュメントによると、ステートフルセッションはフェイルオーバーが有効ならCTSにも保存され、ほかのサーバーから復元できます。ステートレスセッションはCookieに状態を持つので、管理者が監視も終了もできません。

交換は次の順で進めます。遮断より先に交換すると、新しい値がまた読み取られる恐れがあります。

1. 外部からの到達を遮断する
2. 管理者のセッションを破棄し、amadminのパスワードを変更する
3. エージェントのプロファイルとOAuth2クライアントの認証情報を交換する
4. 一般利用者のセッションを破棄するか、最大セッション時間の経過を待つ
5. 管理者や権限グループ、スクリプト設定に不審な変更がないか照合する

手順の2から5はアドバイザリの勧告をもとに、管理者権限が取られた場合の影響範囲から組み立てたものです。

プロキシのログから通知エンドポイントへの不審な接続を抽出する集計

受動収集そのものは記録に残りませんが、接続の成立はログに出ます。WebSocketのハンドシェイクが成功すると、ステータスは101です。既知のエージェント以外からのアクセスを抽出します。

# agent_hosts.txtに許可済みエージェントのIPを1行ずつ書いておく（combined形式のログ）
awk 'NR==FNR { ok[$1]; next }
     !($1 in ok) && $7 ~ /^\/openam\/(notifications|ws\/|preLogin|postLogin)/ {
       print $1, $4, $7, $9
     }' agent_hosts.txt access.log | sort | uniq -c | sort -rn | head -100

内部転送を使われた場合、記録されるのは通知のパスではなくID-FF側のURLになると考えられるため、抽出の対象にpreLoginとpostLoginを含めています。Tomcat側のアクセスログも同じ形で確認してください。プロキシを通らない接続は、そちらにしか残りません。ヒットがゼロでも、ログの保持期間より前の接続は判断できない点は報告に明記します。

奪われたトークンは連携先でも本人として通るため、調査はOpenAMの中で終わりません。不審な接続が見つかった期間は、連携先の操作ログも個人データの一括出力と権限変更を中心に確認します。漏えいのおそれがあると判断した時点で報告の期限が動き出すので、個人情報保護委員会への報告義務で4類型と期限を確認してください。

16.1.4への更新で壊れやすい設定とUpgrade Wizardの実施手順

WARを差し替えて再起動するだけでは、更新は完了しません。古い版から上げるほど既定値の変更を多く踏みます。

独自改修したweb.xmlに追記が必要な4つのフィルターのdispatcher要素

アドバイザリの更新時の注意事項では、web.xmlをカスタマイズしている場合、16.1.4でAuthNFilter、AuthZFilter、JAXRPCRequestFilter、NotificationsWebSocketFilterに追加されたdispatcher要素を自分で引き継ぐ必要があります。

<filter-mapping>
    <filter-name>NotificationsWebSocketFilter</filter-name>
    <url-pattern>/notifications</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
    <dispatcher>INCLUDE</dispatcher>
    <dispatcher>ASYNC</dispatcher>
    <dispatcher>ERROR</dispatcher>
</filter-mapping>

これは16.1.4のweb.xmlからの抜粋で、残り3つのフィルターにも同じ5行が付きます。FORWARDが抜けると、版番号は16.1.4でも内部転送への検査が働かない状態になり得ます。

試験環境での検証を前提にしたUpgrade Wizardの実行順序

公式のアップグレードガイドによると、マイナーな更新でもUpgrade Wizardの実行が必須です。本番の前に試験環境で通すよう指示されています。

1. カスタマイズ済みのWARを用意する
2. デプロイメント全体をバックアップする
3. クライアントの通信を別のサイトへ切り替える
4. サイト内の全サーバーでOpenAMを停止する
5. WARを配備し、古い展開先と作業ファイルを削除する
6. 再起動し、1台でUpgrade Wizardか更新ツールを実行する
7. OpenAMかコンテナを再起動する

ガイドはssoadm import-svc-configで古い設定を取り込む方法を禁じており、構成が壊れる恐れがあると説明しています。Tomcatではwebapps/openam/とwork/Catalina/localhost/openam/の削除も必要です。公式のDockerイメージを使う場合は、イメージを16.1.4のタグに固定し、設定ディレクトリ/usr/openam/configを引き継いだうえで、同じWizardを実行します。

16.1.4未満から上げると既定で無効になるLiberty系エンドポイント

Liberty系の機能を使う環境は、更新の前に次の既定値を確認します。公式のガイドとアドバイザリに個別の注意書きがある項目です。

つまずきやすいのは署名です。com.sun.identity.federation.services.requireSignatureの既定はtrueですが、XMLSigningOnの初期値はfalseなので、そのままではOpenAM自身が送るシングルログアウトのメッセージまで拒否されます。複数台の環境ではcom.sun.identity.federation.services.soap.enabledを全サーバーに設定してください。一部だけだと転送されたログアウトが404になります。

同時修正18件から判断するOpenAM継続利用と移行の採用条件

今回の修正を単発の事故として扱うと、次回も同じ緊急対応になります。ここからは運用を続けるかどうかの判断です。

16.1.4の重大3件と自社の設定で該当するかを切り分ける条件

公開済みアドバイザリの一覧では、2026年10月22日付がCriticalで3件、Highで2件、Mediumで12件、Lowで1件の計18件です。

GHSA-jv8f-m88g-h6mmは匿名の利用者が管理者グループに入れる問題で、自己登録が既定で無効なのが救いです。GHSA-3j2f-qhrc-rjfjは生成された既定のメタデータが条件に絡むため、SAMLのSPとして使う環境では放置できません。demoやwscなどの内蔵アカウントも、更新を機に無効化か変更の状態を棚卸ししてください。

2026年に5回続いたセキュリティ更新から逆算する運用体制の条件

3月の16.0.6には認証前のリモートコード実行（CVE-2026-33439）の修正が入りました。6月の16.1.1、7月の16.1.2（CVE-2026-62379など）、9月の16.1.3、10月の16.1.4と、1〜3か月おきにセキュリティ修正が続いています。

月1回の頻度でWizardを含む更新を回せない体制では、次の公開から適用までの空白が必ず生まれます。パッチ管理の手順を踏まえて、GHSAの通知を購読し、試験環境での更新を定例の作業に組み込んでください。

OpenAMを使い続ける条件とKeycloak・IDaaSへ移行すべき環境

結論を条件で言い切ります。次の3つをすべて満たすなら、OpenAMの継続で問題ありません。

• 月次で更新を試験し、本番へ反映できる担当者がいる
• 管理系とエージェント向けのURLがインターネットから届かない
• ポリシーエージェントなど、他製品に置き換えにくい機能を実際に使っている

1つでも欠けるなら移行を計画します。とくに14.0未満で止まっている環境、ID-FFを使っていないのに公開し続けている環境、構築した委託先が既に保守を離れている環境では、更新を繰り返す判断は取りません。アプリケーション側がSAMLかOIDCで連携できているなら、KeycloakとIDaaSの選び方とIdPの構築手順を起点に切り替えの工数を見積もれます。ただし移行中の旧環境も攻撃面として残るので、先に16.1.4へ上げる作業は省略できません。

OpenAMの脆弱性についてよくある質問と対象版・暫定対策の判断

2026年11月10日時点の一次情報で答えられる範囲をまとめました。

OpenAM 13系は今回の脆弱性の対象ですか？

アドバイザリには、14.0.0より前の版には通知WebSocketが存在しないと書かれており、このCVEの対象外です。ただし安全という意味ではありません。自己登録の問題など、同時に公開された多くのアドバイザリは16.1.3以下の全版を対象としています。公式のガイドは、サポート外の版からはまずサポート対象の版を経由するよう求めているため、段階的な更新か移行の計画が必要です。

ポリシーエージェントも一緒に更新する必要はありますか？

アドバイザリの影響パッケージはサーバー側の3つで、エージェントは挙げられていません。修正後もエージェント用の話題には従来どおりセッションイベントが配信されます。独自に作った通知クライアントが/agent/以外の話題を購読している場合は拒否されるようになるので、改修が必要です。

WAFを入れれば16.1.4に更新しなくても大丈夫ですか？

更新の代わりにはなりません。攻撃の詳細が伏せられているため、シグネチャが今回の経路を捕捉できるかを確かめる手段がないからです。WAFを使うならURL単位の拒否と接続元の制限に用途を絞り、暫定策として期限を切ります。16.1.4には他に17件の修正が含まれており、それらはURLの遮断だけでは対処できません。

Dockerの公式イメージはlatestのままで修正されますか？

2026年10月22日にlatestと16.1.4のタグが更新されています。ただしイメージを取り直すだけでは、設定ストアの更新が行われません。公式のガイドは保守リリースでもUpgrade Wizardの実行を必須としているので、タグを16.1.4に固定し、バックアップのうえでWizardまで実施します。latestのままだと意図しない版に上がるため、本番では使わないでください。

CVE-2026-123551とGHSA-5c3q-hp86-xjr8は別の脆弱性ですか？

同じものです。NVDの参照先にこのGHSAが記載されています。別々に見えるのは採番の時期が違うためで、GHSAが10月22日、CVEの公開が11月8日でした。16.1.4のリリースノートにはGHSAの番号で載っているので、CVE番号で検索しても修正の記載に行き当たりません。

関連記事

• API不正アクセス対策の実装手順：JPCERT注意喚起に沿うレート制限・認可・トークン失効とアプリ解析・SSRF対策：トークン失効の実装を見直すときの手順です。
• OIDC（OpenID Connect）とは？仕組み・IDトークンの検証手順とOAuth 2.0との違い：OpenAMをOIDCのプロバイダーとして使う場合の前提です。
• シングルサインオン（SSO）とは？4つの実現方式とIDトークン検証・IdP選定を実装手順で解説：SSO全体の方式とIdPの選び方を確認できます。
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順：更新を定例作業にするときの組み方です。
• シングルサインオンのデメリット：単一障害点とID漏えいの被害拡大、費用と打ち消し方：認証基盤が破られた場合の被害の広がりを整理しています。