UbuntuのLTS版を運用している人にとって、kernelの脆弱性対応は単なる更新通知ではありません。隔離や権限分離の土台そのものに関わるので、修正の遅れはそのまま運用判断の遅れにつながります。今回の話は、CVSS 9.8というかなり重い評価のCVE-2026-98432について、Ubuntuがまだ修正版kernelを出していない、というものです。対象は22.04、24.04、26.04のLTSで、しかも現時点ではETAも示されていません。
元記事が伝えているのは、UbuntuがCVE-2026-98432に対する修正済みkernelをまだ配布していない、という事実です。この脆弱性はCVSS 9.8とされており、記事ではcritical、つまり深刻度の高い問題として扱われています。ところが、UbuntuのLTS系である22.04、24.04、26.04については、ベンダーが提供する更新がまだ出ていません。LTSは長期サポート版なので、安定運用を重視するサーバーや業務環境で選ばれやすいのですが、その土台になるkernelに修正版がない状態が続いている、というのが記事の主旨です。
記事は、これらのリリースを使っている運用者には、穴を塞ぐ公式kernelパッケージが今のところ存在しないと述べています。影響が大きいのは、インターネットに公開されているシステムや、複数の利用者やワークロードが同じ基盤を共有するself-hosted環境だとしています。そうした環境では、kernelが隔離や権限境界を支えるため、修正がないままだと、CVEが可能にする遠隔またはローカルの攻撃にさらされた状態が続く、という説明です。
さらにUbuntuは、この修正について到着予定時刻、つまりETAを公表していないと記事は指摘しています。現時点で管理者に残されている選択肢は、標準のkernelを使い続けるか、もし存在するならout-of-treeの緩和策を当てるか、あるいはすでにパッチが入っている別のリリースやkernelへ移るか、のいずれかです。要するに、Ubuntu側からの公式な解決策を待つしかないのに、その見通しがまだ立っていない、という状況を伝える記事です。
この記事でまず気になるのは、LTSという言葉が持つ安心感が、こういう場面ではかなり脆いことです。LTSは「長く使える」「更新が安定している」という意味で選ばれますが、実際にはその安心感はベンダーが重要な修正をどれだけ早く配れるかに支えられています。kernelの脆弱性は、アプリケーションの1機能が壊れる話とは違って、システム全体の土台に穴が空く話です。だから、修正版がないという事実は、単に「後で直るだろう」では済みません。LTSを選んだ理由そのものが揺らぎます。
しかも、元記事は22.04、24.04、26.04をまとめて挙げています。これはかなり重い。古い版だけの問題ではなく、最新のLTSまで巻き込まれているからです。運用担当者は「古い環境だから仕方ない」とは言えず、現役の標準構成でも同じ不確実性を抱えることになります。LTSだからこそ広く使われ、そのぶん影響範囲が広い。そこがこの話の厄介なところだと思います。
CVSS 9.8という数字は強烈ですが、実際の現場では点数だけで状況は片付きません。点数が高いということは危険度の目安にはなりますが、管理者にとって本当に重要なのは「いつ、どのパッケージで、どう直せるのか」です。元記事では、その肝心の修正版kernelがまだ出ていないとされ、ETAもない。ここが痛い。脆弱性情報が公開された時点で注意喚起はできても、根本的な解決はベンダー更新が来ない限りできないからです。
この構図は、セキュリティ運用の限界も示しています。監視を強めても、WAFを入れても、別レイヤーでできることには限界がある。kernelレベルの問題は、最終的にはOS提供側の修正に依存する部分が大きい。だからこそ、Ubuntuのようなディストリビューションでは、修正の配布速度がそのまま安全性の一部になります。逆に言えば、配布が止まると、利用者側の努力だけでは埋めにくい空白が生まれる。これは「使う側が悪い」ではなく、プラットフォームとしての責任が問われる場面だと思います。
記事がわざわざ internet-facing と multi-tenant self-hosted systems に触れているのは、そこが最も実害に近いからでしょう。外部公開されているサーバーは当然リスクが高いですが、multi-tenant、つまり複数の利用者や用途が同じ基盤を共有している環境では、kernelの脆弱性は単なる1台の問題にとどまりません。隔離の前提が崩れると、影響は横に広がります。自宅で小さく使うサーバーならまだしも、事業やコミュニティの基盤でこれが起きると、復旧手順や顧客説明まで含めて面倒になります。
さらに厄介なのは、元記事が「どんな攻撃が可能か」を細かく書いていないことです。普通なら攻撃ベクトルを見て優先度を決めますが、今回はそこよりも「未修正のまま残っている」という状態そのものがニュースになっています。これは、技術的な危険度だけでなく、運用上の不確実性が問題だということです。管理者は、パッチ待ちのあいだに一時対策を入れるのか、別のkernelへ逃がすのか、ワークロードの場所を変えるのかを考えなければならない。セキュリティ対応が、純粋な修正作業ではなく移行判断になる。そこに現場のしんどさがあります。
元記事では、管理者の選択肢として標準kernelの継続利用、out-of-tree mitigation、別のreleaseやkernelへの移動が挙げられています。この並びが示すのは、待つこと自体が実質的な判断だという点です。何もしないという選択にも、当然ながらリスクがあります。だから現場は、まだ修正がないと分かっていても、ログの監視を厚くする、公開面を狭める、影響の大きいサービスだけ別環境に逃がす、といった現実的な対処を積み上げるしかない。
私はここで、LTSの「保守的であること」が必ずしも安全と同義ではないと感じます。安定した版を選ぶことは合理的ですが、脆弱性対応が遅れた瞬間、その安定は逆に足かせになる。もちろん、すべての脆弱性に即応するのは難しいし、ベンダー側にも確認や回帰テストの都合があるはずです。それでも、CVSS 9.8級の問題でETAすら出ていないなら、利用者は「更新を待てばよい」では済まされません。こういう記事は、脆弱性そのものより、更新が届かない時間の長さが運用を直撃することを思い出させます。
参考: Ubuntu LTS kernels still unfixed for critical CVE-2026-98432
