ManageEngineのCVE-2026-11374、悪用は難しいが更新後も注意

企業で社員のパスワード管理やActive Directory（社内の利用者アカウントを一元管理する仕組み）の運用に使われるManageEngineの製品群に、認証を経ていない第三者が利用者のアカウントを乗っ取れる欠陥が見つかりました。共通の脆弱性識別番号は CVE-2026-11374、深刻度はCVSSで10点満点中9.0（クリティカル）です。

原因は、一度のログインで複数のサービスを使えるようにする「SSO（シングルサインオン）」の仕組みにあります。ログインした利用者を識別するための合言葉（チケット）が外部から推測できてしまう状態で、これを言い当てられると、攻撃者はパスワードを知らなくても、その利用者になりすませてしまいます。開発元のZoho（ManageEngineのブランド元）は修正版を公開済みです。

影響を受けるのは、統合管理スイート「ManageEngine AD360」と連携させている場合に限られます。該当する4製品を使っている組織は、後述の修正ビルドへ早めに上げる必要があります。

【2026年8月17日追記】悪用は難しい。ただしパッチだけでは終わらない

公開から2か月が経ちました。この間にBishop Fox が技術分析（2026年7月21日）を公開し、この欠陥の実像がかなりはっきりしました。結果からいうと、CVSS 9.0 という数字に比べて、実際の悪用難度はかなり高いというのが同社の結論です。インターネット越しに手当たり次第で破られる類のものではありませんでした。

ただし、安心して終わりにできる話でもありません。修正版を当てても残るリスクがひとつあり、そこはベンダーが手を付けていません。この追記では、なぜ悪用が難しいのか、それでも何が残るのか、管理者は具体的に何を締めればいいのかを整理します。

そもそも何が起きていたのか（根本原因）

Bishop Fox の分析で、チケットの中身が判明しました。SSOのチケットIDは、String ticketId = time.toString() ― つまり System.currentTimeMillis() の戻り値、ミリ秒単位の現在時刻そのものでした。13桁の数字で、値が時刻から決まるため予測できます。攻撃者はこの値を CUSTOM_SSO_TICKET という名前のクッキーに入れて送り返すだけで、他人のセッションを乗っ取れる、という仕組みです。ランダムであるべき合言葉が、実際には時計の読み値だったことになります。

なお Bishop Fox は、完全に武器化した実証コードは公開していません。同社はラボ環境でエンドツーエンドの乗っ取りを実証したと述べていますが、その詳細は伏せられています。

CVSS 9.0 なのに悪用が難しいのはなぜか

まず、CVSSのベクトル自体がそれを示しています。CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H のうち AC:H（攻撃の複雑さ＝高）がその部分です。認証も利用者の操作も要らない（PR:N / UI:N）代わりに、成立には条件がそろう必要がある、と採番元の Zohocorp 自身が評価しています。9.0 という高い数字は、成功したときの影響の大きさ（S:C / C:H / I:H / A:H）が押し上げた結果です。

Bishop Fox は、その「複雑さ」の中身を3つの層に分解しています。時刻が読めれば当たる、という単純な話にならないのは、この3層があるためです。

Bishop Fox の言葉を借りれば、「インターネット越しのブラインド総当たりは、現実的な大量悪用の手法ではない」ということです。ブラインド総当たりとは、手応えが返らないまま片っ端から値を試す攻め方を指します。(a) で手応えが得られず、(b) で試せる場所が限られ、(c) で速度も出ないため、この欠陥で無差別に被害が広がる筋書きは考えにくい、という評価になります。

では脅威がないのかというと、そうではありません。同社が現実的な脅威として挙げているのは、すでに社内ネットワークの中にいる標的型の攻撃者です。(b) の「被害者ネットワーク発の要求しか通らない」という条件は、内部に足場を持つ相手にとっては障害になりません。つまりこの欠陥は、外から入るための穴ではなく、すでに入っている相手が権限を広げるための道具として読むのが実態に近いといえます。

パッチを当てても残るリスクがあります

ここが今回いちばん伝えたい点です。Zoho の修正は、チケットの値を時刻からランダムなUUID（重複しない長いランダムな識別子）に置き換えただけでした。予測はできなくなりましたが、そのチケットの性質は変わっていません。依然として、

• non-HttpOnly ― HttpOnly はクッキーをJavaScriptから読み取れなくする設定で、これが付いていないため、ブラウザ側で動くスクリプトから中身を読めます
• 長寿命 ― 有効期間が長く、一度手に入れた値が長く使えます
• ベアラトークン ― 持っているだけで本人とみなされる引換券で、誰が持っているかは問われません

この3つが重なる結果、何らかの経路で盗まれたチケットは、修正版を当てたホストでもそのまま通ります。パッチが塞いだのは「値を言い当てる」経路だけで、「値を盗んで使い回す」経路は開いたままです。そしてこの点についてベンダー側の対応は確認されていません。ADSelfService Plus のリリースノートを追うと、6529（2026年6月3日）の次は build 7000（2026年6月13日）ですが、CVE-2026-11374 に関する追加修正や是正の告知は見当たりません。残りは利用者側で締めるしかない、というのが現在地です。

管理者が追加で締めておくこと（ハーデニング手順）

修正ビルドを当てたうえで、Bishop Fox が推奨している追加のハーデニング（設定を締めて攻撃の余地を減らす作業）は次の4点です。いずれも製品の管理画面から手が届く範囲の設定です。

① セッションタイムアウトを短くする。 チケットが長寿命であることが残存リスクの中心なので、有効期間そのものを短くします。盗まれた値が使える窓を狭めるのが狙いで、パッチでは手が付いていない部分を利用者側で埋める作業にあたります。

② リバースプロキシの信頼設定を厳格にする。 リバースプロキシとは、利用者と製品の間に立って通信を中継する仕組みです。ここで送信元IPを名乗る HTTP ヘッダを無条件に信じる設定になっていると、前掲の防壁 (b)（被害者ネットワーク発の要求しか通らない）を攻撃者が自称で迂回できてしまいます。信頼するプロキシと信頼するヘッダを明示的に限定してください。

③ TRUSTED_IPS を絞る。 製品側で許可する接続元IPの一覧です。ここが広く開いていると防壁 (b) が実質的に無効になります。SSO連携に必要なホストだけに限定するのが基本です。

④ ログで URL_ROLLING_THROTTLES_LIMIT_EXCEEDED を監視する。 回数制限（防壁 (c)）に引っかかったときにログへ出る文字列です。これが並んで記録されていれば、総当たりが試みられた痕跡と読めます。監視対象の文字列としてそのまま登録しておくと、試行を早い段階で拾えます。

加えて、SSO連携そのものを使っていないのであれば、CustomSSO 連携を無効化するという手もあります。これは Bishop Fox が追加の緩和策として提示しているもので、使っていない機能を止めるだけなので副作用も読みやすい対処です。

Bishop Fox の検出スクリプトでできること・できないこと

2026年7月20日、Bishop Fox は検出スクリプト（CVE-2026-11374-check）を公開しました。使う前に、性質と限界を押さえておく必要があります。

これはエクスプロイト（攻撃コード）ではありません。 動作は、無効なチケットを1つ送って cleanup ヘッダの有無を観測するだけで、セッションの復元は一切行いません。他人になりすます処理は入っていないため、自組織の資産に対して安全に実行できます。GitHub上に公開されている CVE-2026-11374 関連のリポジトリは、2026年8月17日時点でこの1件のみです。

一方で、脆弱性の有無の判定には使えません。 修正ビルドはこのコードパス（応答を返す処理の流れ）を変更していないため、パッチ済みのビルドでも同じ応答が返ります。スクリプトが返す POTENTIALLY_AFFECTED という結果は「AD360連携が存在する」ことを示すにとどまり、そのホストが脆弱かどうかは別途ビルド番号を確認して判断する必要があります。連携の棚卸しには使えるが、合否判定には使えない道具、と理解してください。

現在地: 悪用の報告はなく、KEVにも入っていません

2026年8月17日時点の状況を整理します。実環境での悪用報告はありません。 CISA KEVにも未登録で、2026年8月14日版のカタログで確認しています（KEV一覧の日本語版でも同じです）。NVDに併記されている CISA-ADP Vulnrichment の SSVC 判定も Exploitation: none（悪用の証跡なし）／Automatable: no（自動化して大量に攻撃できるものではない）で、Bishop Fox の評価と食い違いません。検出面では、Tenable Nessus のプラグイン 322756が公開済みで、脆弱性スキャナを使っている環境なら未対応のホストを機械的に洗い出せます。

対象製品についても動きはありません。ManageEngine のアドバイザリに載る対象は公開時と同じ4製品のままで、2026年7月以降に対象製品が追加された事実は確認されていません。下の早見表の内容は現在も有効です。

国内の公的注意喚起はゼロのままです

日本国内では、公的機関からの発信が一切ありません。2026年8月17日時点で、JVNおよびJVN iPediaに該当する登録はなく、JPCERT/CCの注意喚起も、IPAの重要なセキュリティ情報への掲載もありません。Security NEXT の記事も確認できませんでした。日本語での言及は、海外記事を翻訳したブログ1本のみです。国内でAD360を運用している組織が、日本語で今回の実像 ― 悪用は難しいが、パッチ後も盗まれたチケットは通る ― にたどり着ける手段は、ほぼないのが実情です。

この欠陥は誰に、どんな被害をもたらすのか

狙われるのは、ManageEngine AD360と連携した管理ツールを、インターネットから届く場所に置いている組織です。これらの製品は、社員が自分でパスワードを再設定したり、管理者がアカウントや監査ログを扱ったりするための入り口です。つまり、攻撃者にとっては「社内の鍵束」がまとまっている場所であり、そこを正面から開けられるなら、これほど都合のいい標的はありません。

攻撃者がやることは、ログイン中の利用者を識別する合言葉（SSOチケット）を推測し、その人になりすましてログイン状態を奪い取ることです。パスワードの入力も、利用者をだますメールも必要ありません。なりすましに成功すると、その利用者が持つ権限と役割をそのまま引き継げてしまいます。乗っ取った相手が管理者であれば、影響は一気に広がります。

被害として現実的なのは、社員アカウントの乗っ取りを足がかりにした社内システムへの侵入、パスワード再設定機能を悪用した他アカウントの掌握、そして監査ログの閲覧や改ざんによる「侵入の痕跡消し」です。ID管理の土台が破られると、その上に乗っている全社の利用者管理が揺らぎます。なお、後述するようにこの攻撃は条件がそろわないと成立しにくい面もありますが、深刻度が高いことに変わりはありません。だからこそ、修正版への更新を急ぐ価値があります。

対象製品と修正版の早見表

影響を受ける4製品と、それぞれの修正ビルド・公開日を整理します。自社で使っている製品のビルド番号と照らし合わせ、下記より古ければ更新が必要です。修正は2026年6月初旬から順次提供されています。

いずれも単体で使っている場合ではなく、AD360に統合して連携させている構成が対象です。各製品の修正は「サービスパック」として配布されており、製品内の更新メニューか、ManageEngineのサービスパック配布ページから適用できます。

【2026年8月17日 追記】この4製品という範囲は現在も変わっていません。ベンダーのアドバイザリを2026年8月17日時点で確認しましたが、7月以降に対象製品が追加された事実は確認されていません。ビルド番号と修正日も上表のとおりで変更ありません。ただし、修正ビルドを当てただけでは終わらない点があります（冒頭の追記を参照してください）。

技術的に何が起きているのか

問題の核心は、SSOのセッションを認証する際に発行される「チケット」の作り方にあります。ManageEngineの説明によると、AD360経由でこれらの製品にSSOでサインインしたとき、そのセッションを認証するために生成されるチケットが、認証されていない攻撃者から予測可能でした。本来チケットは、第三者には推測できないランダムな値であるべきものです。

これは不十分な乱数の使用（CWE-330）と予測可能な識別子の生成（CWE-340）に分類され、結果として認証不備（CWE-287）を招きます。攻撃者は有効なチケットを言い当てることで、対象の利用者の身元（identity）と役割（role）の情報を取得し、そのアカウントを乗っ取れる、とアドバイザリは説明しています。

CVSSのベクトル（CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H）を読み解くと、攻撃はネットワーク越しに、事前の認証も利用者の操作もなしに成立し得ます。一方で「攻撃の複雑さ：高（AC:H）」とされており、チケットの予測には一定の条件や試行が必要で、誰でも簡単に再現できるわけではありません。とはいえ、認証なしでアカウントを奪える性質と影響範囲の広さから、総合スコアは9.0（クリティカル）と評価されています。Zohoはチケットの生成方法を強化し、推測できないように修正したとしています。

【2026年8月17日 追記】公開時点では「チケットの予測には一定の条件や試行が必要」としか書けませんでしたが、その中身が判明しました。チケットIDは System.currentTimeMillis() の値そのもの、つまりミリ秒単位の現在時刻で、CUSTOM_SSO_TICKET クッキーとして送り返せばセッションを乗っ取れます。同時に、Bishop Fox の分析によって悪用を阻む3層の防壁と、修正版でも残るリスク（クッキーが non-HttpOnly のままである点）も明らかになっています。詳細は冒頭の追記にまとめました。

いま管理者がやるべきこと

回避策（設定変更による一時しのぎ）は公表されていません。対応は修正ビルドへの更新が唯一の手段です。順番に進めます。

① 自社の構成を確認する。 まず、ADSelfService Plus・RecoveryManager Plus・M365 Manager Plus・ADAudit Plusのいずれかを、AD360と連携させて使っているかを確認します。AD360との統合をしていなければ、本件の直接の対象ではありません。

② ビルド番号を確認し、更新する。 各製品のビルド番号が上の早見表より古ければ、配布されているサービスパックを適用します。ADSelfService Plusは6529、RecoveryManager Plusは6321、M365 Manager Plusは4817、ADAudit Plusは8703以降が対策済みです。更新手順は各製品のアドバイザリからたどれます。

③ 公開範囲を見直す。 これらの管理ツールは、本来インターネットに広く公開する必要のないものです。社外から直接アクセスできる状態になっていないか、ファイアウォールやアクセス制限を点検します。万一、別の脆弱性が出たときの被害を抑える基本対策にもなります。

④ 更新後も、追加のハーデニングを行う。【2026年8月17日 追記】 修正版はチケットの値をランダム化しただけで、クッキー自体は non-HttpOnly かつ長寿命のままです。セッションタイムアウトの短縮、リバースプロキシの信頼設定の厳格化、TRUSTED_IPS の限定、ログ内の URL_ROLLING_THROTTLES_LIMIT_EXCEEDED の監視までをセットで行ってください。手順の詳細は冒頭の追記にまとめています。

ManageEngineのアカウント管理製品は、過去にも認証回避の脆弱性が実際の攻撃に悪用され、米政府の悪用が確認された脆弱性リスト（KEV）に複数回掲載されてきた経緯があります。今回のCVE-2026-11374は執筆時点でKEVには載っておらず、悪用の報告も確認されていませんが、狙われやすい製品であることは念頭に置いて、更新を後回しにしないのが安全です。同種の「ログイン基盤の認証回避」では、ログイン基盤Casdoorの認証回避や、GitLabのアカウント乗っ取りでも、社内設置型の製品ほど更新が遅れがちで危険、という共通点があります。

わかっていること・まだわからないこと

よくある質問

Q. ManageEngineの製品を単体で使っています。影響はありますか？

今回のアドバイザリは、4製品を統合スイートのAD360と連携させた構成を対象としています。単体運用について脆弱性の言及はありません。ただし、修正ビルドは安定して提供されているため、構成にかかわらず最新のサービスパックへ更新しておくのが安全です。

Q. CVSS 9.0なのに「攻撃の難度は高い」とはどういうことですか？

CVSSのスコアは、影響の大きさ（認証なしでアカウントを奪える）と攻撃のしやすさを合わせて算出されます。今回は影響が極めて大きい一方、ベクトルには AC:H（攻撃の複雑さ＝高）が入っています。Bishop Fox の分析によれば、その中身はサーバ間ハンドシェイク・送信元IPの縛り・1IPあたり約40回／60秒の回数制限という3層で、インターネット越しの総当たりは現実的ではありません。9.0という数字は「誰でも即座に悪用できる」ことを意味しない、と読むのが正確です。

Q. すでに攻撃されている恐れはありますか？

2026年8月17日時点でも、実環境での悪用の報告やKEVへの掲載は確認されていません。CISA-ADP の SSVC 判定も「悪用の証跡なし」「自動化不可」で、Bishop Fox の評価とも一致します。ただしManageEngineのアカウント管理製品は過去に攻撃の標的になった実績があり、油断はできません。更新を後回しにしないことが最善の備えです。

Q. 修正ビルドを当てれば、この件は完了ですか？

完了しません。修正はチケットの値をランダムなUUIDに置き換えただけで、クッキー自体は non-HttpOnly（JavaScriptから読める）かつ長寿命のベアラトークンのままです。そのため、何らかの経路で盗まれたチケットは修正済みのホストでも通ります。ベンダー側でこの点に手が入った形跡は確認されていないため、セッションタイムアウトの短縮、TRUSTED_IPS の限定、リバースプロキシの信頼設定の厳格化までを利用者側で行う必要があります。

Q. Bishop Fox の検出スクリプトを使えば脆弱かどうか判定できますか？

判定はできません。このスクリプトは無効なチケットを送って応答ヘッダを観測するだけの検出専用ツールで、エクスプロイトではありません。修正ビルドはこのコードパスを変更していないため、パッチ済みのホストでも同じ応答が返ります。結果の POTENTIALLY_AFFECTED は「AD360連携が存在する」ことを示すにとどまるので、脆弱性の有無は必ずビルド番号で確認してください。

Q. 日本の公的機関からは注意喚起が出ていますか？

2026年8月17日時点で出ていません。JVN iPediaへの登録も、JPCERT/CCの注意喚起も、IPAの重要なセキュリティ情報への掲載も確認できませんでした。日本語での言及は、海外記事を翻訳したブログ1本のみです。

更新履歴

参照元

• ▸ManageEngine - Security advisory: CVE-2026-11374
• ▸Bishop Fox - A Millisecond of Predictability: Why CVE-2026-11374 Is Hard to Exploit（2026年7月21日）
• ▸GitHub - BishopFox/CVE-2026-11374-check（検出専用スクリプト）（2026年7月20日）
• ▸Tenable - Nessus Plugin 322756
• ▸ManageEngine ADSelfService Plus - リリースノート（build 6529 / 7000 の記載を確認）
• ▸NVD - CVE-2026-11374
• ▸ManageEngine AD360 製品ページ
• ▸CISA - Known Exploited Vulnerabilities Catalog