この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
これは Ubuntu を Windows の Active Directory（AD）で管理する公式ツール ADSys の脆弱性で、CVSSは 9.0（Critical）。社内ネットワークに割り込んだ攻撃者に、通信の盗み見やなりすましを許してしまう内容です。20年以上 Linux サーバーの現場にいますが、AD連携をしている組織にとっては、優先度を上げて当てるべき1件だと考えています。
この記事は「攻撃手法をどう再現するか」ではなく、現役の管理者が、今あるUbuntuにどうやってパッチをあてて検証するかという実務手順に絞って書きます。攻撃者視点の深掘りは別の専門サイトに譲り、ここでは「確認 → 適用 → 検証」の3ステップを地に足のついた形で整理します。
・CVE-2026-12249 は ADSys（Ubuntu の AD連携公式ツール）の脆弱性で、CVSSは9.0 Critical。証明書の自動取得を暗号化なしのHTTPで行っていた点が原因です。
・本質は中間者攻撃（MITM）。社内ネットワークに入り込んだ攻撃者が偽の証明書を端末に信じ込ませ、通信の盗聴やなりすましを許します。
・影響を受けるのは ADSys 0.13.0 ～ 0.16.2。修正版は 0.16.3 以降です。
・Ubuntu 24.04 / 22.04 LTS は
sudo apt update && sudo apt upgrade で対応できます。20.04 LTS は標準サポートが終了しているため、Ubuntu Pro（ESM）が必要です。・対応は「適用して終わり」ではありません。
apt policy adsys でバージョンを実機確認し、適用後の挙動まで見届けるのが現場の鉄則です。
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
CVE-2026-12249 とは何か（ADSysと影響範囲）
そもそもADSysは何をしているツールか
ADSys は、Ubuntu を Windows の Active Directory に参加させ、グループポリシー（GPO）や証明書配布などを Ubuntu 側で受け取って適用するための、Canonical 公式のツールです。Windows管理者が慣れ親しんだ AD の仕組みで Linux 端末も一元管理したい、という現場で使われます。今回問題になったのは、その機能のうち 証明書の自動取得（auto-enrollment） の部分です。AD配下の端末が、社内の認証局（CA）から自動的に証明書を受け取る仕組みですが、この取得通信が 暗号化なしのHTTP で行われていました。
なぜCVSS 9.0という高スコアになったのか
CVSS 9.0 は Critical に分類される、かなり高い値です。理由は、攻撃が成立したときの影響範囲の広さにあります。この脆弱性の分類は CWE-348「信頼性の低い情報源の使用（Use of Untrusted Information Source）」です。平たく言えば、本来信じてはいけない経路から受け取った証明書を、端末が無条件に信じてしまうという構造です。証明書は通信の信頼の土台なので、ここが崩れると、その端末が関わる暗号化通信全体の前提が揺らぎます。
注意したいのは、これがリモートからいきなり成立する種類のものではなく、社内ネットワークに割り込める位置を攻撃者が確保していることが前提だという点です。とはいえ、社内LANは「内側だから安全」という油断が残りやすい場所で、実務では決して低く見積もれません。
脆弱性の本質：HTTPでの証明書取得が招く中間者攻撃
暗号化なしのHTTPだと何が起きるのか
証明書の取得通信が暗号化なしのHTTPだと、その通信経路上に居座った攻撃者は、中身を読むだけでなく 書き換える こともできます。これが中間者攻撃（MITM、Man-in-the-Middle）です。具体的には、攻撃者が本物のCAになりすまし、偽のルート証明書を端末に送り込みます。端末は「正規の経路で受け取った証明書だ」と思い込んでこれを信頼ストアに取り込んでしまう。一度この偽証明書を信じてしまうと、攻撃者は以後の暗号化通信を自由に盗み見たり、別のサーバーになりすましたりできるようになります。
証明書という「信頼の起点」をすり替えられるのが、この脆弱性の怖いところです。単なる情報漏えいにとどまらず、なりすましによる二次被害まで連鎖しうる構造になっています。
影響を受けるバージョンと修正バージョン
影響範囲と修正版を整理します。| 区分 | ADSysバージョン |
|---|---|
| 影響を受ける | 0.13.0 ～ 0.16.2 |
| 修正済み | 0.16.3 以降 |
自分の環境がどのバージョンかは、後述する
apt policy adsys で実機確認するのが確実です。「うちは新しいから大丈夫」という思い込みではなく、必ず数字で確かめてください。
実務パッチ運用：確認→適用→検証の3ステップ
ステップ1：現状バージョンの確認
まず、ADSys がインストールされているか、入っているなら何のバージョンかを確認します。慌ててアップグレードする前に、現状把握が先です。# show installed version of adsys
apt policy adsys
# 実行例（影響を受けるバージョンの場合）
adsys:
Installed: 0.16.2~22.04.1
Candidate: 0.16.3~22.04.2
Version table:
0.16.3~22.04.2 500
*** 0.16.2~22.04.1 100
ここで
Installed が 0.13.0 ～ 0.16.2 の範囲なら、影響を受ける対象です。Candidate に 0.16.3 以降が出ていれば、リポジトリ側には修正版が届いている状態なので、次のステップに進めます。ステップ2：パッチの適用
Ubuntu 24.04 LTS / 22.04 LTS は、通常のアップデート手順でそのまま適用できます。# パッケージ情報を更新してアップグレード
sudo apt update
sudo apt upgrade
# ADSysだけを対象に当てたい場合
sudo apt install --only-upgrade adsys
本番環境でいきなり
apt upgrade を全体に当てるのが不安なら、--only-upgrade adsys で対象パッケージを絞るのが安全です。AD連携は端末の認証に直結するため、関係ないパッケージまで巻き込んで予期せぬ挙動を招くのは避けたいところです。注意点として、Ubuntu 20.04 LTS は標準サポート（メンテナンス）が終了しています。20.04 でこの修正を受け取るには、Ubuntu Pro（ESM、拡張セキュリティメンテナンス）の有効化が必要です。個人利用の範囲なら無償枠で使える場合があるので、20.04 のまま運用が続いている端末があれば、Pro の有効化状況を合わせて棚卸ししてください。
ステップ3：適用後の検証
「アップグレードしたから終わり」ではありません。本当に修正版に入れ替わったかを数字で確認します。# 適用後にバージョンを再確認
apt policy adsys
# Installed が 0.16.3 以降になっていればOK
adsys:
Installed: 0.16.3~22.04.2
さらに、AD連携が壊れていないかも確認します。証明書の自動取得を実際に使っている環境なら、適用後に端末が正常にポリシーを受け取れているか、いつもの運用フローで動作確認をしておくと安心です。検証まで含めて初めて「対応完了」と言えます。
ここまでの作業は、Ubuntu のパッケージ管理（apt）と AD連携の基礎が頭に入っていると一気に楽になります。背景から手を動かして固めたい方には、定番の解説書を1冊そばに置いておくことをおすすめします。
うまくいかない場合のトラブルシュート
Candidateに0.16.3が出てこないとき
apt policy adsys を実行しても Candidate に 0.16.3 以降が出てこない場合、リポジトリ情報が古いのが原因のことが多いです。まず sudo apt update を実行してから、もう一度確認してください。それでも出ない場合は、20.04 のように標準サポートが切れているケースを疑います。前述のとおり、20.04 は Ubuntu Pro（ESM）を有効化しないと修正版が降ってきません。
pro status で有効化状況を確認しましょう。アップグレード後にAD連携が不調になったとき
万一、適用後にポリシー適用や認証で不具合が出た場合は、慌てて元に戻す前に、まずjournalctl -u adsysd でサービスのログを確認します。証明書取得の経路が変わったことに起因するのか、別の設定要因なのかを切り分けるのが先です。本番環境では、こうした切り分けを落ち着いてできるかどうかで復旧時間が大きく変わります。現役管理者にとっての教訓
今回の件で改めて確認しておきたいのは、「内部ネットワークだから暗号化は不要」という発想は、もう通用しないということです。証明書の取得という、普段あまり意識しない自動処理の経路にこそ、信頼の土台を崩すリスクが潜んでいました。AD連携のような「他社のエコシステムに乗る」仕組みは、便利な反面、自分たちの目の届きにくい通信が増えます。だからこそ、ベンダーの脆弱性情報を受け取ったら、影響範囲を自分の手でバージョン確認し、当てて、検証するという当たり前のサイクルを、淡々と回せる体制が効いてきます。
こうした「確認 → 適用 → 検証」の型は、特定のCVEに限らず、あらゆるパッチ運用に共通する基本動作です。緊急対応のたびに調べ直すのではなく、自分の手順として体に入れておくことが、結局いちばんの近道になります。
セキュリティ全般の考え方を体系的に整理したい方には、入口のアプリ側の脆弱性パターンを押さえる定番書も役に立ちます。
PR
通信のなりすましや盗聴がなぜ成立するのか、その原理を腰を据えて学べる一冊。CVE単発の対応にとどまらず、攻撃の前提を理解しておくと判断が速くなります。
まとめ：CVE-2026-12249の対応チェックリスト
ここまでの対応を一覧で整理します。手元の端末で順に確認してください。| ステップ | やること | 確認コマンド/基準 |
|---|---|---|
| 1. 確認 | ADSysのバージョン把握 | apt policy adsys で 0.13.0～0.16.2 なら対象 |
| 2. 適用 | 24.04/22.04はアップグレード | sudo apt update && sudo apt upgrade |
| 2b. 20.04 | Ubuntu Pro（ESM）を有効化 | pro status で確認 |
| 3. 検証 | 修正版への入れ替わりを確認 | Installed が 0.16.3 以降 |
| 3b. 動作 | AD連携の正常動作を確認 | ポリシー適用・認証の動作確認 |
CVSS 9.0 という数字に身構えるよりも、自分の環境のバージョンを確かめて、淡々と当てて、検証する。緊急パッチ対応は、この基本動作を慌てずに回せるかどうかがすべてです。
緊急パッチ対応、自信を持って本番に当てられますか？
apt policy でのバージョン確認、対象パッケージを絞った適用、適用後の検証、そしてサービスログでの切り分け。記事で読むだけでなく、実機で繰り返し手を動かすことで初めて身につきます。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxカーネルからstrncpyが消えた日｜6年362コミットが示す"安全なC"の現実解
- 前のページへ：Secure Boot証明書が2026年6月失効｜UEFI CA 2011刷新でLinux管理者がやるべき確認と対応
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます