2026年10月の後半、Linuxサーバーの管理者を悩ませる材料が一度に出そろいました。Anthropicが研究環境で認証なしの遠隔root実行を実証したと報告したCVE-2026-98432、CISAのKEV（悪用が確認された脆弱性の一覧）に載ったFragnesia、GitLabを上げても直らなかったAlpine Linuxの事例です。
先に結論を書きます。今週の順番は、CVSSの点数だけで決めないでください。軸は「KEVに載っているか」と「外から届くか」の2つです。KEV掲載のPHP2Shellの影響を受けるPHPやGitLabを公開しているサーバーを今日片付け、同じサーバーのFragnesiaを塞ぐ。外から届くMPTCPの待受があるサーバーも同じ扱いにして、修正が配布済みなら同じ再起動でまとめて適用し、未提供なら今日中に待受の公開を止めるか緩和策を入れる。それ以外のTCP公開サーバーは、CVE-2026-98432の修正を今週の枠に入れる。この順番をおすすめします。
この記事では、20年以上Linuxサーバーの運用と指導に携わってきた立場から、点数・上流の修正・パッチ適用の3つが実際の危険度とどうズレているかを整理し、今日コピペで進められる確認手順までを解説します。想定環境はRHEL系、Ubuntu、Debianです。攻撃の再現手順は扱いません。記事中の状況は2026年10月31日時点のものなので、作業の前に各ベンダーの最新情報を見直してください。
この記事のポイント
・今週の優先順位はKEV掲載と外部到達性で決める
・98432は9.8だがKEV未掲載。外から届くMPTCP待受は先に対処
・10月31日時点でRHELとUbuntuの修正は未提供
・更新後は実行中カーネルと同梱部品まで確かめる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
CVE-2026-98432で何が起きたのか：事実の整理
CVE-2026-98432は、LinuxカーネルのIPv4 TCP処理にあるuse-after-free（解放済みメモリを参照してしまう欠陥）です。TCPの接続を確立する途中でIPオプションの情報を持つ領域が解放され、その後も参照される場合があります。修正は、この領域の解放をkfree()からkfree_rcu()へ改めるものです。導入は4.4です。話題になったきっかけは、Anthropicが10月27日に公開した研究発表です。multipath TCP（MPTCP、1つの接続で複数の経路を使う機能）の待受があるLinuxサーバーへパケットを送り、認証なしでrootとして任意のコマンドを実行できる攻撃コードを、AIが書いたと報告しました。使われたのは一般公開されていない内部研究モデルです。
| 項目 | 2026年10月31日時点の内容 |
|---|---|
| CVE公表 | 2026年10月15日 |
| CVSS | 9.8（Linux CNAの値。NVD自身の分析は未実施）。Red Hatも9.8（draft）でCritical、Ubuntuは9.8でHigh、SUSEとAmazon Linuxは8.1 |
| 上流の修正版 | 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10、7.3（NVDの記録） |
| KEV | 掲載なし |
| 実悪用 | 報告は見つからず（悪用がないという意味ではありません） |
「MPTCPを使っていないから安全」とは言えません
Anthropicの実証はMPTCPの待受を前提にしていますが、CVEの記録そのものにMPTCPの語は出てきません。Go Security Teamの告知（oss-securityに転送）は「the underlying bug is not specific to MPTCP」（バグはMPTCP固有ではない）と述べ、MPTCPの待受が無いシステムでも類似の攻撃が成り立つ可能性に触れています。Red Hatの評価も、通常のTCPサービスが接続を受け付ける経路を問題にしています。Red HatはCVEページで、確実なコード実行には精密なヒープ制御が要るとし、主な帰結としてサービス停止やメモリ破壊を挙げています。ただし速報RHSB-2026-016では、遠隔コード実行につながりうる（to trigger remote code execution）と書いています。CloudLinuxは自社カーネルでは再現できていないと述べていますが、これは同社カーネルの範囲の話で、Anthropicの報告を否定するものではありません。「Anthropicは研究環境でroot実行まで実証したと報告している。第三者による再現は確認できず、実悪用の報告も見つかっていない」が、今言える範囲です。
もう1つ、自分で有効にした覚えがなくてもMPTCPの待受が生まれる環境があります。上流カーネルの
net.mptcp.enabledは既定で1です。これはMPTCPソケットを作れるという意味で、待受の有無は別の話ですが、この値が1のサーバーでは、Go 1.24以降のプログラムがLinuxの待受ソケットで既定でMPTCPを有効にします。一方、RHELは既定でMPTCPを無効にしていて、AlmaLinuxも同様です。同じ名前空間の値が0なら、Goのプログラムがあっても待受は生まれません。ディストリごとの値は、後の手順で確かめてください。ズレ1：CVSSの点数と実際の危険度
CVSSの基本値は、脆弱性そのものの性質を測る数字です。そのサーバーで今狙われているか、別の穴とつながるかまでは表しません。今回は、その差が並んで見えます。| CVE | CVSS | KEV | 性質 |
|---|---|---|---|
| CVE-2026-98432 | 9.8 | 掲載なし | ネットワーク経由。研究環境での実証の報告あり |
| CVE-2026-46300（Fragnesia） | 7.8 | 10月28日に追加 | ローカルの権限昇格 |
| CVE-2026-41709（VMware ESX） | 2.7 | 10月28日に追加 | 管理者権限で操作をログに残さず実行 |
Fragnesiaが興味深いのは、公表が5月13日（CVEレコードの公開は5月23日）で、KEV入りが10月28日という点です。約5か月前の、しかも「ローカルの権限昇格」が今になって一覧に載りました。KEVの説明文には、PHP2Shell（CVE-2026-109618 / CVE-2026-109619）と連鎖させ、PHPのWebシェルを仕込んでrootでコマンドを実行できる旨が書かれています。
つまり、ローカルの穴は単体では外から届かなくても、Web層の穴が入口を作れば届きます。ローカル権限昇格を「ログインできる人だけの話」と片付ける判断は、公開Webサーバーでは通用しません。Fragnesia自体の仕組みはFragnesia解説記事にまとめてあります。
逆に、KEV未掲載の9.8を「まだ悪用されていないから後回し」と読むのも危険です。KEVは悪用の証拠が集まった後で載る一覧で、載っていないことは安全の証明になりません。点数は入口として使い、判断は連鎖と到達性で下す。これがズレ1の結論です。
ズレ2：「上流修正済み」と「自分のサーバーが修正済み」
Anthropicの発表には、この脆弱性は上流で修正され、保守中の安定版カーネルへ移植済みと書かれています。ただ、多くのサーバーが動かしているのは上流のカーネルでなく、ディストリが配布するカーネルです。ベンダーの状況は次のとおりで、そろっていません。| ディストリ | 2026年10月31日時点の状況 |
|---|---|
| RHEL 8 / 9 / 10 | kernelがAffected、修正版は未提供。Red Hatは修正を急いでいると表明。RHEL 6 / 7はNot affected |
| AlmaLinux 8 / 9 / 10 | 修正カーネルをtestingリポジトリで提供中、本番リポジトリは未反映 |
| Ubuntu 26.10 / 26.04 / 24.04 / 22.04 | Vulnerable, work in progress（修正作業中）。20.04、18.04、16.04もVulnerable |
| Debian | bookwormは6.1.190-1、trixieは6.12.113-1で修正 |
| SUSE | 全体はPending。SLES 16.0などは修正済み、SLES 15 SP7などはAffected |
| Oracle Linux | UEKに修正errataあり。RHCKの修正は記載なし |
| Amazon Linux | AL2とAL2023に勧告あり |
CVE公表から2週間以上たっても、RHELとUbuntuの利用者には修正カーネルが届いていません。この空白は、どれだけ
dnf upgradeやapt upgradeを打っても埋まりません。バージョン文字列だけで判定できない理由
ここでよくあるつまずきが、uname -rの数字と上流の修正版を比べてしまうことです。たとえばUbuntu 24.04の6.8.0-149.149は、上流の修正版6.6.159より数字が大きく見えますが、Ubuntuのページでは修正作業中の版として載っています。RHELの5.14.0系も、ベンダーが修正を移植する運用なので、上流の番号との大小比較に意味はありません。Debianではuname -rが6.1.0-xx-amd64のような形で、パッケージの版はuname -vを見ないと分かりません。判定に使うのは、ディストリのセキュリティ情報と、入っているパッケージの版です。
ズレ3：「更新した」と「直った」
3つ目のズレを一番はっきり見せたのが、Alpine Linuxが公表した自社GitLabへの攻撃です。CVE-2026-97229はCVSS 10.0で、GitLabは10月12日に修正版19.4.2 / 19.3.5 / 19.2.8を出しました。ところが修正の本体はGitLabのコードにはなく、Rubyの正規表現エンジン側にありました。GitLabの公式パッケージには修正が入りますが、Alpineは標準のRubyを使う構成でした。Alpineの公表から流れを追います。修正版の19.3.5へ上げるつもりが19.3.4を入れてしまい、10月20日に攻撃者のアカウント登録と探査、10月21日に本攻撃。10月22日に19.3.6へ更新しましたが、これでは直りませんでした。上流のRubyが修正を出したのは10月23日です。未修正と判明したのは10月26日で、その後サービスを閉じて再構築し、全パスワードとGitLabのシークレットキーを更新して、19.3.7とRuby 3.3.13で再開しています。Alpineは「攻撃者がサーバー上でコードを実行した証拠は見つかっていないが、否定もできない」と述べており、それでも再構築を選びました。
教訓は「GitLabの版数だけ見ても、実際に動いている部品は分からない」ということです。同じ形のズレはカーネルにもあります。
・カーネル：パッケージを更新しても、再起動するまで動いているのは古いカーネルです
・PHP：パッケージを更新しても、php-fpmやApacheが再起動されるまでは古いコードが動き続けます
・コンテナ：カーネルはホストのものを共有するので、イメージの更新では直りません。逆にイメージ内のRubyやPHPは、ホストの更新では直りません
「更新コマンドが成功した」は作業の記録にすぎません。完了と言えるのは、実際にロードされているものを見た後です。
AIが攻撃コードを書く時代の時間軸：53分をどう読むか
48分と5分、合わせて53分という数字が話題になっています。Anthropicの原文では、これは実証コードの実行時間です。カーネルのアドレス情報を漏らすのに48分、そこからコマンド実行に至るまで5分。AIが攻撃コードを作るのにかかった時間ではありません。開発に要した時間は発表に書かれていません。留保すべき点はほかにもあります。対象のカーネルの版やディストリ、設定は記事に書かれておらず、外部の読者が同じ条件を確かめることはできません。報告や修正の日付も示されていないので、「修正から攻撃コード完成まで何日」という計算もできません。これは攻撃の被害報告でなく、AI開発企業自身による研究発表で、第三者による再現も確認できていません。
それでも無視してよい話ではないと、私は考えます。当サイトでは4月にProject Glasswingを取り上げ、5月には生成AIがゼロデイを発見する時代としてGoogleの報告を紹介しました。そこへ今回、カーネルの遠隔root実行を研究環境で実証したという報告が加わりました。
一方、猶予の短さを示す材料は、AIの話を抜きにしても手元にあります。GitLabは修正公開が10月12日で、Alpineへの本攻撃が10月21日。PHPは修正公開が10月21日で、PHP2ShellのKEV追加が10月26日でした。AIの関与はどちらにも示されていませんが、「月1回のパッチ枠で間に合う」という前提はすでに苦しくなっています。
パッチ公開から悪用までの猶予が縮むなら、変えるべきは次の4つだと考えます。
・情報を見る頻度：KEVとベンダー勧告を、月例でなく日次で見る
・外部公開の一覧：どのサーバーのどのポートが外から届くかを、平時から把握しておく
・再起動の段取り：カーネル更新と再起動を例外扱いにせず、短時間で回せる手順にしておく
・作り直せる状態：Alpineのように侵害を否定できないとき、再構築できる構成と手順を持っておく
今週の優先順位の決め方：KEVと外部到達性で分ける
KEV掲載と外部到達性に、連鎖先の有無を重ねて分けます。| 順位 | 条件 | 今週やること |
|---|---|---|
| 1（今日） | KEV掲載で外から届く。公開中のPHP、外部からアクセスできるGitLab | 更新と関連サービスの再起動。修正前から公開していたなら侵入の痕跡も確かめる |
| 2（今日から明日） | KEV掲載の連鎖先と、報告された実証の前提に当たるサーバー。順位1のサーバーのFragnesia、一般ユーザーやコンテナが同居するサーバー、CVE-2026-98432で外から届くMPTCP待受があるサーバー | カーネル更新と再起動。CVE-2026-98432の修正が配布済みなら同じ再起動でまとめて適用。未提供なら今日中に待受の公開を止めるか緩和策を入れる |
| 3（今週） | KEV未掲載でも外から届く。CVE-2026-98432で、外から届くMPTCP待受は無いがTCPを公開しているサーバー | 修正配布済みなら更新と再起動。未提供なら緩和策を検討し、配布の通知を待つ |
| 4（次の定期枠） | 内部からしか届かず、ほかの順位に当たらないもの | 定期パッチで対応。KEV掲載のものは枠の先頭に置き、社内の踏み台になりうるサーバーは順位を上げる |
KEVの期限（Fragnesiaは10月31日、GitLabは11月1日）は米国連邦機関向けのもので、日本の民間企業の義務ではありません。
順位1のサーバーは、更新だけで終わらせないでください。修正前から公開していたなら侵入の痕跡を確かめ、否定できなければAlpineのように作り直しを検討します。
CVE-2026-98432について、KEV掲載、実悪用の報告、root実行まで動くと確かめられた攻撃コードの公開のどれかを確認したら、順位2と順位3のサーバーは順位1へ移してください。10月31日時点で、レースの発火を示すと称するコードは公開リポジトリに出始めていますが、root実行まで第三者が確かめたという報告は見つかっていません。KEVへの掲載は悪用の後になるので、KEVだけを待たないでください。Debianのように修正が配布済みのディストリでは、順位2と順位3のカーネル更新は1回の再起動で済む可能性が高いので、再起動を分ける前に手順2で版を確かめてください。
GitLabには別件のCVE-2026-110264もあり、こちらの修正版は19.3.6、19.4.3、19.5.1です。更新するなら、その時点の最新の修正版を選んでください。
今日やるチェックリスト：上から順にコピペで進める
コマンドはRHEL系とUbuntu / Debian系で分けてあります。自分の環境の行だけ実行してください。手順1のパッケージ導入を除き、手順2～6は読むだけで、システムの設定を変更しません。1. 準備：必要なコマンドを入れる
# RHEL / AlmaLinux / Rocky の場合 sudo dnf install -y iproute nftables curl # Ubuntu / Debian の場合 sudo apt-get update sudo apt-get install -y iproute2 nftables curl # Ubuntu のみ（手順2で pro コマンドを使います） sudo apt-get install -y ubuntu-pro-client
2. 実行中のカーネルと、修正の配布状況を見る
# 全ディストリ共通：OSと実行中カーネル grep -E '^(NAME|VERSION)=' /etc/os-release uname -r uname -v # RHEL系：エラータの有無と、実行中カーネルの変更履歴 dnf updateinfo list --cve CVE-2026-98432 dnf updateinfo list --cve CVE-2026-46300 rpm -q --changelog kernel-core-$(uname -r) | grep -E 'CVE-2026-(98432|46300)' # Ubuntu：--dry-run は変更を加えず内容だけ表示します sudo pro fix CVE-2026-98432 --dry-run sudo pro fix CVE-2026-46300 --dry-run # Debian：入っているカーネルパッケージの版 dpkg -l 'linux-image-*' | grep '^ii'
pro fixの結果で判定してください。pro fixの出力例（環境により異なります）# 未修正の場合 Sorry, no fix is available yet. CVE-2026-98432 is not resolved. # 修正済みの場合 The update is already installed. CVE-2026-46300 is resolved.
3. 更新済みなのに古いカーネルで動いていないか見る
# RHEL系：入っているカーネル（新しい順）と実行中カーネルを比べる rpm -q --last kernel-core | head -n 3 uname -r # Ubuntu / Debian：入っているカーネルと、再起動要求の有無 dpkg -l 'linux-image-*' | grep '^ii' ls -l /var/run/reboot-required
/var/run/reboot-requiredが無くても、再起動不要とは言い切れません。このファイルを作らない構成もあります。Ubuntuは一覧の最新版とuname -r、Debianはdpkg -lの版とuname -vを比べてください。4. MPTCPの待受と、外に開いているポートを見る
# MPTCPの待受（-M がMPTCPの指定） sudo ss -Mlnp # sysctl でMPTCPソケットの作成可否を見る（上流の既定は 1、RHEL系の既定は 0） sysctl net.mptcp.enabled # TCPの待受全体。0.0.0.0 や [::] は全インターフェースで待ち受けている sudo ss -tlnp # Dockerを使っている場合だけ：コンテナ内も見る（コンテナ名は書き換えてください） PID=$(sudo docker inspect -f '{{.State.Pid}}' コンテナ名) sudo nsenter -t "$PID" -n ss -Mln
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 4096 192.0.2.10:8080 0.0.0.0:*
ssが見せるのは待受だけで、実際に外から届くかは分かりません。ファイアウォールとクラウドのセキュリティグループも合わせて判断してください。また、ssが見るのは今いるネットワーク名前空間だけなので、コンテナは別に確かめます。MPTCPの待受が無くても修正は必要です。外から届くMPTCP待受があれば順位2、無ければ順位3です。5. KEVの掲載状況を自分で確かめる
# KEVのJSONを取得 curl -fsS -o /tmp/kev.json https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json # 1 なら掲載、0 なら未掲載 for c in CVE-2026-98432 CVE-2026-46300 CVE-2026-109618 CVE-2026-109619 CVE-2026-97229; do printf '%s: ' "$c" grep -c "\"cveID\": \"$c\"" /tmp/kev.json done
6. PHPとGitLabの実体を見る
# PHPの版（これはコマンドライン用のPHPの版です） php -v # 動いているPHP-FPMとWebサーバー systemctl list-units --type=service --state=running 'php*' 'httpd*' 'apache2*' # Apacheに組み込まれたPHP（mod_php）の有無 # RHEL系 sudo httpd -M | grep -i php # Ubuntu / Debian sudo apache2ctl -M | grep -i php # サービスの起動時刻（サービス名は上の一覧に合わせて書き換えてください） systemctl show -p ActiveEnterTimestamp サービス名 # GitLab公式パッケージの版（ホストに直接入れた場合） head -n 1 /opt/gitlab/version-manifest.txt # GitLabを自前のRubyで動かしている場合：ホストのRuby ruby -v # コンテナで動かしている場合：コンテナの中のRuby（コンテナ名は書き換えてください） sudo docker exec コンテナ名 ruby -v
すぐ更新できない場合の緩和策：Red Hatのnftables規則
RHELのように修正が未提供の場合、Red Hatの速報RHSB-2026-016にnftablesの緩和策があります。これはパッチの代替ではありません。Red Hat自身が「not a substitute for patching」と明記し、完全な対処は更新だけ（the only complete solution）としています。この規則は、IPオプション付きのIPv4 TCPパケットを破棄して攻撃を受ける範囲を減らしますが、Red Hatは完全には防げないとしています（cannot fully prevent it）。通常のアプリケーション通信は概ね影響を受けない見込みとする一方、必要な業務を妨げる可能性にも触れ、自分の通信で見直し、本番以外で試すよう求めています。これはRed Hatの手順で、ほかのディストリの公式な緩和策ではありません。Ubuntuのページに緩和策の記載はありません。
ここからはRed Hatの文書に無い、当サイトの補足です。この規則はホスト宛ての通信を見るinputフックに置かれます。ブリッジ経由でコンテナへ転送される通信はここを通らないので、Dockerのポート公開やKubernetesのPodで待ち受けるサービスには、この規則だけでは効かないものとして扱ってください。
# 規則のファイルを作る cat > cve-2026-98432.nft <<'EOF' table inet cve_2026_98432 { chain input { type filter hook input priority -310; policy accept; ip protocol tcp ip hdrlength > 5 counter drop } } EOF # 文法を検査してから読み込み、内容を表示する sudo nft --check --file cve-2026-98432.nft sudo nft --file cve-2026-98432.nft sudo nft list table inet cve_2026_98432
list tableのcounterを時々見てください。増えていれば、この規則が実際にパケットを捨てています。この規則は専用のテーブルに入るので、既存のファイアウォール規則は書き換えません。ただし保存はされません。再起動で消えるうえ、nftablesサービスの再読み込みでも消えることがあります。順位2の再起動の後など、修正カーネルに切り替わるまでは次のコマンドで確かめ、無ければ入れ直してください。
# 1行ずつ実行してください。まず残っているか確かめる sudo nft list table inet cve_2026_98432 # テーブルが無かったときだけ入れ直す（cve-2026-98432.nft があるディレクトリで実行） sudo nft --file cve-2026-98432.nft # 入れ直した後に確かめる sudo nft list table inet cve_2026_98432
# 修正カーネルへ更新した後に取り除く sudo nft delete table inet cve_2026_98432
sysctl -w net.mptcp.enabled=0も、oss-securityで紹介されています。ただし、この値はネットワーク名前空間ごとなのでコンテナには及ばず、新しいソケットの作成を止める設定なので動作中のプログラムは再起動が要り、OSを再起動すれば元に戻ります。MPTCPを必要とするプログラムにも影響が出るうえ、これで全ての悪用経路が塞がるという一次情報はありません。プログラム単位の無効化（GoのGODEBUG=multipathtcp=0）も「fragile mitigation」（壊れやすい緩和策）と呼ばれています。Go Security Teamの告知の結論も修正カーネルへの更新です。
まとめ：ズレを埋めてから「対応済み」と言う
CVE-2026-98432の9.8という数字は、それだけでは今週の順番を決めてくれません。| 論点 | 見るもの | 確認に使うコマンド |
|---|---|---|
| 点数と危険度 | KEV掲載、外部到達性、連鎖先 | sudo ss -tlnp |
| 上流とディストリ | ベンダーの配布状況とパッケージの版 | dnf updateinfo list --cve CVE-2026-98432 |
| 更新と修正完了 | 実行中のカーネルと実際の部品 | uname -r |
| AIの時間軸 | 日次の情報確認と再起動の段取り | grep -c '"cveID": "CVE-2026-98432"' /tmp/kev.json |
今日の順番は、KEV掲載で外から届くものを片付け、連鎖先と外から届くMPTCP待受を塞ぎ、残りのCVE-2026-98432の修正を今週の枠に入れることです。RHELとUbuntuは、外に開いたサーバーの洗い出しを先に済ませておくと、修正が届いた日に迷わず動けます。
参考（一次情報）
・CVE-2026-98432 カーネルCVE告知
・Anthropic研究発表（2026年10月27日）
・oss-security（Go Security Teamの告知）
・oss-security（MPTCPの無効化についての投稿）
・Red Hat RHSB-2026-016
・CISA PHP2Shellアラート
・Alpine Linux GitLabインシデント報告
・AlmaLinuxの告知
・CloudLinuxの告知
・関連：当サイトFragnesia検知（auditd・Falco・eBPF）、livepatchを当てた後の運用設計
「更新した」と「直った」の違いを、自信を持って説明できますか？
実行中のカーネル、待受ポート、再起動の段取り。どれも記事で読むだけでなく、実機で繰り返し手を動かして初めて「守れる知識」になります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、サーバーの守り方を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
＜PR＞手元に置いて学びを深める1冊
Linuxサーバーセキュリティ徹底入門 オープンソースによるサーバー防衛の基本
まずは上の無料メルマガで学ぶのが第一歩です。加えて手元に置くなら、2013年刊の本書がサーバー防御の基本を学ぶ土台になります。コマンドは今のOSの文書と照らして読んでください。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：PwnEscape（CVE-2026-99999）｜仮想マシンからホストを狙うLinuxカーネル脆弱性と、KVMホストの更新・再起動の段取り
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます