Dirty Frag Linux脆弱性は、Linuxサーバーへ低権限で侵入された後に、攻撃者がroot権限へ昇格するために悪用されるローカル権限昇格の脆弱性です。結論から言うと、Microsoft DefenderやMicrosoft Defender for CloudでLinux環境を監視している管理者は、カーネル更新の適用状況、esp4・esp6・rxrpcモジュールの利用有無、SSH・Webシェル・コンテナ経由のローカル実行リスクを優先的に確認すべきです。
Microsoftは、Dirty FragをLinuxカーネルのネットワーク処理とメモリ断片処理に関係する脆弱性として説明しており、esp4、esp6はCVE-2026-43284、rxrpcはCVE-2026-43500に関連するとしています。攻撃者が最初からrootを持っている必要はありません。SSHアカウントの侵害、Webシェル、低権限サービスアカウント、コンテナからの脱出など、すでに何らかの実行権限を得た後の被害拡大に使われる点が重要です。(Microsoft)
Dirty Frag Linux脆弱性とは何か
Dirty Fragは、Linuxカーネル内のネットワーク関連コンポーネントであるesp4、esp6、rxrpcなどを悪用し、低権限ユーザーからroot権限への昇格を可能にする脆弱性です。
誤解しやすい点は、Dirty Fragが「外部から直接ログインなしで侵入できる脆弱性」ではないことです。主なリスクは、攻撃者がすでにサーバー上で何らかのコマンドを実行できる状態になった後、root権限を取得して被害を広げることにあります。
たとえば、次のような状況では優先度を高く見積もる必要があります。
| リスクが高い環境 | 理由 |
|---|---|
| SSHログインを許可しているLinuxサーバー | 低権限アカウントの侵害後にroot化される可能性がある |
| インターネット公開Webアプリを稼働するサーバー | Webシェル設置後の権限昇格に使われる可能性がある |
| コンテナホスト、CI/CDランナー、ビルドサーバー | コンテナやジョブからホスト側への影響が大きい |
| IPsec、VPN、関連ネットワーク機能を使うサーバー | esp4、esp6を無効化できない場合がある |
| Microsoft Defenderで監視しているLinuxワークロード | Defender側の検知・脆弱性管理情報を確認できる |
Microsoftは、影響を受ける可能性のある環境としてUbuntu、RHEL、CentOS Stream、AlmaLinux、Fedora、openSUSE、OpenShiftなどを挙げています。ただし、実際の影響はディストリビューション、カーネルバージョン、モジュール構成、ベンダーパッチの適用状況によって変わります。(Microsoft)
2026年5月9日時点で管理者が押さえるべき変更点
Microsoftの公式情報で特に重要なのは、Dirty Fragが「侵入後の権限昇格リスク」として扱われている点です。攻撃者がroot権限を得ると、認証情報の窃取、ログ改ざん、セキュリティツールの停止、横展開、永続化が容易になります。
| 確認項目 | 内容 | 管理上の意味 |
|---|---|---|
| 脆弱性の性質 | Linuxローカル権限昇格 | 侵入後の被害拡大を防ぐ対策が必要 |
| 関連CVE | CVE-2026-43284、CVE-2026-43500 | 片方だけでなく両方を追跡する |
| 関連コンポーネント | esp4、esp6、rxrpc、xfrm/IPsec関連機能 | モジュールの利用有無を確認する |
| 攻撃経路 | SSH、Webシェル、コンテナ、低権限アカウントなど | ローカル実行権限を持つ経路を棚卸しする |
| Microsoft Defenderの対応 | 検知、脆弱性管理、追加保護の調査 | Defenderポータルでアラートと対象デバイスを確認する |
Microsoftの記事公開時点では、CVE-2026-43284についてLinux Kernel OrganizationのパッチがNVDにリンクされている一方、CVE-2026-43500についてはRxRPC関連として予約されているが、NVDでは未公開と説明されていました。(Microsoft)
その後、NVDではCVE-2026-43500のレコードが2026年5月11日に公開され、rxrpcのDATA/RESPONSEパケット処理に関する説明、CVSS 3.1のHigh評価、kernel.orgのパッチ参照が掲載されています。実運用では、Microsoft公式情報だけでなく、NVDと各ディストリビューションの最新アドバイザリもあわせて確認してください。(NVD)
影響範囲を判断するための実務チェック
Dirty Fragの対応では、「Linuxを使っているか」だけで判断すると不十分です。重要なのは、攻撃者がローカルでコードを実行できる余地があるか、関連モジュールが存在するか、カーネル更新を適用して再起動済みかです。
まず確認するコマンド
以下は、Linuxサーバーで初期確認を行うための例です。実行前に、自社の運用ルールと変更管理手順に従ってください。
cat /etc/os-release
uname -r
lsmod | egrep '^(esp4|esp6|rxrpc|xfrm_)'
modinfo esp4 2>/dev/null | head
modinfo esp6 2>/dev/null | head
modinfo rxrpc 2>/dev/null | head確認の見方は次の通りです。
| 確認結果 | 判断 |
|---|---|
| 対象ディストリビューションで、ベンダーが影響ありとしている | パッチ適用を優先する |
esp4、esp6、rxrpcがロード済み | 一時的な無効化可否を検討する |
| モジュールは存在するがロードされていない | 自動ロードを防ぐ設定を検討する |
| カーネル更新済みだが再起動していない | 旧カーネルで稼働中の可能性がある |
| コンテナだけ更新済み | ホストカーネルは未対策の可能性がある |
特にコンテナ環境では、アプリケーションイメージを更新してもホストのLinuxカーネルは更新されません。Kubernetes、OpenShift、CIランナー、コンテナビルド基盤では、ノードOS側のカーネル更新と再起動、またはノード入れ替えまで含めて対応を完了させる必要があります。
管理者が実施すべき対応手順
Dirty Frag対応は、単にパッチを当てるだけではなく、攻撃経路の封じ込め、検知、再発防止まで含めて進めるべきです。
対応の優先順位
| 優先度 | 対象 | 先にやること |
|---|---|---|
| 最優先 | SSH公開サーバー、踏み台、Webアプリサーバー | パッチ確認、不要アカウント停止、ログ調査 |
| 最優先 | コンテナホスト、CI/CDランナー | ノード単位のカーネル更新、ジョブ権限の見直し |
| 高 | IPsec、VPN、xfrm関連機能を使うサーバー | 停止できる機能と業務影響を確認 |
| 高 | Microsoft Defenderで保護しているLinux端末 | アラート、脆弱性管理、検知名を確認 |
| 中 | ローカルユーザーが限定された内部サーバー | メンテナンス計画に入れて更新と再起動を実施 |
カーネル更新を適用する
最も確実な対策は、利用しているディストリビューションの公式パッチを適用し、更新後のカーネルで再起動することです。
# Debian / Ubuntu系の例
sudo apt update
sudo apt full-upgrade
sudo reboot
# RHEL / Fedora / AlmaLinux系の例
sudo dnf upgrade
sudo reboot
# openSUSE系の例
sudo zypper patch
sudo reboot更新後は、必ず稼働中のカーネルを確認します。
uname -rパッケージ管理上は更新済みでも、再起動していなければ古いカーネルで動き続けていることがあります。サーバー台数が多い環境では、「更新済み」と「再起動済み」を別々に管理してください。
一時対策としてモジュール無効化を検討する
すぐにカーネル更新や再起動ができない場合は、esp4、esp6、rxrpcの無効化を一時対策として検討できます。Microsoftも、未使用のrxrpcカーネルモジュールの無効化、esp4、esp6、xfrm/IPsec関連機能を安全に無効化できるかの評価を推奨しています。(Microsoft)
一例として、各ディストリビューションの案内では、該当モジュールのロードを防ぐmodprobe設定と、ロード済みモジュールのアンロードが示されています。ただし、IPsec VPNやRxRPC関連機能を使っている環境では通信断や業務影響が出る可能性があります。(AlmaLinux OS)
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/dirtyfrag.conf
sudo modprobe -r esp4 esp6 rxrpc 2>/dev/null || trueロールバックが必要な場合の例です。
sudo rm /etc/modprobe.d/dirtyfrag.conf
sudo modprobe esp4 2>/dev/null || true
sudo modprobe esp6 2>/dev/null || true
sudo modprobe rxrpc 2>/dev/null || true本番環境では、いきなり全台に適用せず、VPN、監視、バックアップ、認証、クラスタ通信に影響がないかを検証してから展開してください。
Microsoft Defenderで確認すべきポイント
Microsoftは、Dirty Fragに関連する挙動についてMicrosoft Defenderで監視・検知を進めていると説明しています。特に、Microsoft Defender XDR、Microsoft Defender Antivirus、Microsoft Defender for Endpoint、Microsoft Defender for Cloud、Microsoft Defender Vulnerability Managementを利用している組織は、ポータル上で対象デバイスとアラートを確認してください。(Microsoft)
| 製品・機能 | 確認する内容 |
|---|---|
| Microsoft Defender Antivirus | Exploit:Linux/DirtyFrag.A、Exploit:Linux/DirtyFrag.B、Trojan:Linux/DirtyFrag.*系の検知 |
| Microsoft Defender for Endpoint | 不審なSUID/SGIDプロセス起動、suを伴う権限昇格の兆候 |
| Microsoft Defender for Cloud | Dirty Frag脆弱性悪用の可能性を示すアラート |
| Microsoft Defender Vulnerability Management | CVE-2026-43284、CVE-2026-43500に関連する脆弱なデバイス一覧 |
| Microsoft SentinelなどのSIEM | SSHログイン、Webシェル疑い、ELFバイナリ実行、権限昇格イベントの相関分析 |
Microsoftは、限定的な実環境での活動として、SSHアクセス後にインタラクティブシェルが起動し、ELFバイナリがステージングされ、suを通じた権限昇格が観測されたケースを説明しています。さらに、GLPI関連ファイルの変更、システム調査、PHPセッションファイルの削除や読み取りといった活動も示されています。(Microsoft)
GLPIを使っていない環境でも、次のような挙動は調査対象にしてください。
| 調査すべき兆候 | 見るべき場所の例 |
|---|---|
| 直近の不審なSSHログイン | /var/log/auth.log、/var/log/secure |
低権限ユーザーからのsuやsudo実行 | 認証ログ、EDRアラート |
| 不審なELFファイルの実行 | /tmp、/var/tmp、Web公開ディレクトリ |
| SUID/SGIDファイルの異常 | find / -perm -4000 -type fなど |
| Webシェル疑い | Webサーバーログ、最近変更されたPHPファイル |
| セッションファイルの削除・閲覧 | PHPセッションディレクトリ、アプリログ |
開発者が確認すべきポイント
Dirty Fragはカーネル側の脆弱性ですが、開発者の対応も重要です。アプリケーションが侵入口になると、Dirty Fragのようなローカル権限昇格によってサーバー全体の侵害へ発展する可能性があります。
開発者は、次の点を確認してください。
| 確認項目 | 具体例 |
|---|---|
| アプリの実行ユーザー | Webアプリをrootで実行していないか |
| ファイルアップロード | 実行可能ファイルやスクリプトを配置できない設計になっているか |
| CI/CDジョブ | ビルドジョブが過剰な権限でホストに触れないか |
| コンテナ設定 | privilegedコンテナ、ホストPID/ネットワーク共有を不要に使っていないか |
| 秘密情報 | 低権限プロセスから認証情報やトークンを読めないか |
| ログ | 権限昇格前後の行動を追えるだけのログが残るか |
特に見落とされやすいのは、コンテナ環境です。コンテナ内のパッケージを更新しても、Dirty Fragの根本対策であるホストカーネルの更新にはなりません。開発チームとインフラチームで、「アプリイメージの更新」と「ノードOSの更新」を分けて管理してください。
展開・移行時に失敗しやすいポイント
Dirty Frag対応では、急いで作業するほど設定ミスやサービス停止が起きやすくなります。以下の失敗パターンを事前に避けてください。
| 失敗しやすい対応 | なぜ危険か | 正しい進め方 |
|---|---|---|
| CVE-2026-43284だけを見る | rxrpc側のCVE-2026-43500を見落とす | 両方のCVEとモジュールを確認する |
| パッチ適用だけで完了扱いにする | 再起動していないと旧カーネルのまま | uname -rで稼働中カーネルを確認する |
全台でesp4、esp6を無効化する | IPsec VPNなどが停止する可能性がある | 依存サービスを確認し、段階展開する |
| コンテナイメージ更新で対策済みと判断する | ホストカーネルは変わらない | ノードOS更新、再起動、入れ替えを行う |
| キャッシュ削除を完全な復旧策と考える | 侵害されたアカウントや永続化は残る | フォレンジック、認証情報ローテーションも実施する |
| Defenderアラート待ちにする | 未検知の侵害や設定不備を見逃す | 脆弱性管理、ログ調査、パッチ展開を並行する |
侵害が疑われる場合の対応
すでに攻撃を受けた可能性がある場合、単にモジュールを無効化したり、パッチを適用したりするだけでは不十分です。Microsoftは、悪用が発生していた場合、メモリやキャッシュされたファイル内容に悪意ある変更が残る可能性があり、重要ファイルの整合性確認やキャッシュクリアの検討が必要だと説明しています。(Microsoft)
対応の流れは次のように整理できます。
| 手順 | 実施内容 |
|---|---|
| 隔離 | ネットワークから切り離す、不要なSSHを停止する |
| 証拠保全 | プロセス、ネットワーク接続、ログ、疑わしいファイルを記録する |
| 権限昇格の確認 | su、sudo、SUID/SGID、認証ログを確認する |
| 重要ファイルの検証 | /etc/passwd、/etc/shadow、/etc/sudoers、PAM設定、SSH鍵を確認する |
| パッチ適用 | ベンダー提供の修正済みカーネルへ更新し、再起動する |
| 認証情報の更新 | 侵害された可能性のあるパスワード、鍵、トークンをローテーションする |
| 監視強化 | Defender、SIEM、EDRで同様の挙動を継続監視する |
キャッシュクリアを行う場合の例です。
sync
echo 3 | sudo tee /proc/sys/vm/drop_cachesただし、キャッシュクリアは本番環境のディスクI/Oを一時的に増加させ、性能に影響する可能性があります。また、侵害後の恒久的な復旧策ではありません。ログ改ざん、永続化、認証情報流出の確認を省略しないでください。(Microsoft)
いま取るべき行動
Dirty Frag Linux脆弱性への対応は、次の順番で進めると実務上の抜け漏れを減らせます。
| 順番 | やること |
|---|---|
| 1 | Linuxサーバー、コンテナホスト、CIランナー、OpenShiftなどの対象資産を洗い出す |
| 2 | uname -rとディストリビューション情報を取得し、ベンダーのパッチ状況と照合する |
| 3 | esp4、esp6、rxrpc、xfrm/IPsec関連機能の利用有無を確認する |
| 4 | 公式パッチを適用し、再起動後のカーネルを確認する |
| 5 | すぐに更新できない場合は、業務影響を評価した上でモジュール無効化を検討する |
| 6 | Microsoft Defenderのアラート、脆弱性管理、SUID/SGIDやsu関連の検知を確認する |
| 7 | 侵害が疑われる場合は、キャッシュだけでなく重要ファイル、認証情報、永続化の有無まで調査する |
Dirty Fragは、単体で「入口」になる脆弱性というより、侵入後に攻撃者の権限を一気に高める脆弱性です。だからこそ、パッチ適用だけでなく、SSH、Webアプリ、コンテナ、CI/CD、Microsoft Defenderの検知状況をまとめて確認する必要があります。まずは対象Linuxホストを棚卸しし、更新済みカーネルで再起動済みかを確認してください。
コメント