サーバーの脆弱性通知が届いたらどうする？Linuxの実例から学ぶ5つの確認事項

「お使いのサーバーに重大なセキュリティ脆弱性が見つかりました。速やかにOSをアップデートしてください」

ある日、サーバー会社からこんなメールが届いたら、どうしますか？

すぐに対応しなければと思っても、

何を更新すればよいのか分からない
OSをアップデートするとシステムが止まらないか心配
そもそも自社のサーバーが影響を受けるのか分からない

と、対応に迷うこともあるのではないでしょうか。

さらに厄介なのは、重大な脆弱性が公表されても、利用中のOS向けの修正パッチがすぐに提供されるとは限らないことです。

実際に2026年10月、Linuxカーネルの重大な脆弱性「CVE-2026-98432」が公表されました。

私たちテイルウインドでも、お客様のサーバーについて影響を調査し、正式な修正版を適用できるまでのリスクを軽減するため、暫定対策を実施しました。

今回は、この事例をもとに、サーバーの脆弱性通知が届いたときに確認したい5つの項目と、修正パッチがまだ使えない場合の考え方をご紹介します。

1. Linuxに重大な脆弱性。何が問題だったのか？

2026年10月15日、Linuxカーネルの脆弱性「CVE-2026-98432」が公表されました。

Linuxカーネルとは、OSの中核となる部分です。Webサイトや業務システムを動かすサーバーでも広く使用されています。

今回の問題は、IPv4のTCP通信を処理する仕組みに関係しています。

特定の条件下で不正に細工された通信を受信すると、メモリの取り扱いに問題が生じ、次のような影響を受ける可能性があります。

サーバーの異常終了やサービス停止
メモリ内の情報の漏えい
メモリの破損
条件によっては外部からの任意コード実行

Red Hatは、この脆弱性を深刻度「Critical」、CVSSスコア9.8として評価しています。

もちろん、Linuxを使っているサーバーすべてが同じ危険性を持つわけではありません。

利用しているカーネルのバージョン、公開している通信サービス、ネットワーク構成、適用済みの修正などによって影響は変わります。

大切なのは、通知が来たからといって慌てて設定を変更するのではなく、まず自社の環境が影響を受けるか確認することです。

2. 修正パッチがまだ使えない場合、どうする？

一般的に、OSの脆弱性に対する基本的な対応は、OSベンダーが提供するセキュリティ更新を適用することです。

ところが、重大な脆弱性が公表されても、修正パッケージの配布には時間がかかる場合があります。

今回のCVE-2026-98432でも、Ubuntu向けの修正状況が段階的に更新されました。

2026年11月2日には、Ubuntu 22.04 LTS以降を対象とする修正版が、テスト用の「-proposed」リポジトリに用意されたことが発表されています。

ただし、テスト用の修正版が存在することと、通常のセキュリティ更新として安定版が配布されることは別です。

そのため、利用中のOSでどの修正版が利用できるのか、公式情報を確認する必要があります。

パッチを待つ間にも、検討できる対策がある

今回の脆弱性について、Red HatやAWSは、IPオプション付きのIPv4通信を制限する緩和策を紹介しています。

これは、脆弱性に関係する通信経路への到達を制限し、攻撃を受けるリスクを軽減するための方法です。

Linuxには、nftablesなどの通信制御機能があります。

これらを利用して、対象となる通信を遮断することができます。

ただし、この方法には注意点があります。

暫定対策は、脆弱性そのものを修正するわけではありません。

また、サーバーの通信環境によっては、必要な通信に影響する可能性があります。

そのため、設定内容の検討、事前検証、適用後の動作確認が欠かせません。

なお、Ubuntuは今回の脆弱性について、正式なセキュリティ更新の適用を基本方針として案内しています。暫定的な通信制限は、環境ごとの判断が必要なリスク軽減策と考えるべきです。

3. 実際に行ったサーバーの暫定対策

ここからは、私たちテイルウインドが2026年11月3日に行った対応をご紹介します。

お客様から、Xserver VPSの脆弱性通知についてご相談をいただいたことがきっかけでした。

ご依頼は、開発環境のOSをアップデートしてほしい、というものでした。

しかし、確認を進めると、開発環境だけでなく本番環境にも影響があることが分かりました。

そこで、両方のサーバーについて対応を実施しました。

※お客様の情報を保護するため、サーバー名やネットワーク構成などの詳細は省略しています。

① 影響のあるサーバーを確認

まず、開発環境と本番環境で使用しているOSとカーネルを確認しました。

対象となった環境は次のとおりです。

環境	OS	確認結果
開発環境	Ubuntu 26.04 LTS	影響あり
本番環境	Ubuntu 24.04 LTS	影響あり

この時点で使用できる修正パッケージの状況を確認し、すぐに通常の更新だけで解決することは難しいと判断しました。

② nftablesによる暫定的な通信制限

次に、Linuxの通信制御機能であるnftablesを利用し、IPオプション付きIPv4 TCPパケットを遮断するルールを設定しました。

この対応は、特定の通信をサーバー側で遮断し、脆弱性に関係する攻撃経路への到達を減らすことが目的です。

ただし、必要な通信を誤って遮断すると、正常なサービスにも影響するおそれがあります。

そのため、単純にルールを追加するだけでなく、通信の仕組みと既存の設定を確認したうえで適用しました。

③ 通信とWebサイトの動作を確認

設定後には、次の点を確認しました。

遮断対象となる通信が実際に拒否されること
通常の接続が引き続き利用できること
Webサイトなどの応答が作業前後で変化していないこと
作業前から存在する問題と、今回の変更による影響を区別すること

今回の環境では、対象パケットの遮断と通常接続の維持を確認できました。

また、確認したWebサイトの応答についても、作業前後で問題となる変化はありませんでした。

セキュリティ対策は、設定しただけで完了ではありません。目的の通信を遮断できたか、正常な業務を妨げていないか、両方を確認することが重要です。

④ 正式な修正パッチの適用を計画

今回の暫定ルールは、サーバーの再起動によって消える構成でした。

そのため、正式な修正パッチが適用できるようになるまでに再起動する場合は、対策の再確認が必要です。

また、修正版が提供されたら、OS更新と再起動を行い、修正されたカーネルで稼働していることを確認する必要があります。

特に本番環境では、再起動によるサービス停止が発生するため、お客様と作業日時を調整することも欠かせません。

今回のように、暫定対策を行った後も、正式な修正が完了するまで対応を継続する必要があります。

4. サーバーの脆弱性通知が届いたときの5つの確認事項

ここまでの内容を、自社のサーバーに当てはめてみましょう。

セキュリティ通知を受け取ったときは、次の5項目を確認することをおすすめします。

チェック① 自社のサーバーは影響を受ける？

まず、使用中のOSとカーネルを確認します。

Ubuntuなのか、Debianなのか、Red Hat系なのかによって、修正状況や対応手順が異なります。

また、レンタルサーバーやクラウドサービスでは、OSの管理をサービス提供会社が担当している場合もあります。

確認したいこと

利用しているOSとカーネルのバージョン
脆弱性の影響を受けるバージョンか
OSの管理・更新は誰が担当しているか

チェック② 修正パッチは提供されている？

次に、OSベンダーの公式セキュリティ情報を確認します。

確認したいこと

自社のOS向けに修正パッケージが提供されているか
修正済みのバージョンは何か
適用に再起動が必要か

重要なのは、パッケージを更新しただけでなく、修正されたカーネルが実際に動作しているかどうかです。

チェック③ パッチがない場合の暫定対策は？

修正パッチがまだ利用できない場合は、OSベンダーやセキュリティ情報の提供元が案内する緩和策を確認します。

今回のように、特定の通信を遮断することでリスクを軽減できる場合もあります。

ただし、すべての脆弱性に共通する暫定対策があるわけではありません。

通信制限によって業務に支障が出る可能性もあるため、技術的な判断が必要です。

チェック④ 対策後の動作確認はできている？

セキュリティ設定を変更すると、それまで正常に動いていたサービスに影響する場合があります。

たとえば、

Webサイトが表示されなくなる
APIが接続できなくなる
外部システムとの通信に問題が発生する

といったケースも考えられます。

そのため、対策の前後で正常な動作を確認することが大切です。

チェック⑤ 正式な修正までの担当者と予定は決まっている？

暫定対策を実施しても、正式な修正パッチが未適用なら、対応は完了していません。

確認したいこと：

修正パッチの提供状況を誰が確認するか
適用作業は誰が担当するか
本番サーバーの停止時間をどう調整するか
更新後に誰が動作確認を行うか

暫定対策だけで安心してしまい、正式な修正を忘れないようにすることが重要です。

5. 自社だけで対応するのが難しい場合は？

ここまで読んで、

「OSのバージョンをどうやって確認すればよいか分からない」

「サーバーを構築した担当者が、もう社内にいない」

「本番環境なので、設定を変更して問題が出ないか不安」

と感じた方もいるかもしれません。

サーバーの脆弱性対応は、単にコマンドを実行すればよいというものではありません。

現在の環境を確認し、必要な対策を判断し、業務への影響を抑えながら作業する必要があります。

特に本番環境では、対応を急ぐあまりサービス停止につながってしまうことも避けなければなりません。

私たちテイルウインドでは、システムの開発だけでなく、公開後の保守やセキュリティアップデートにも取り組んでいます。

サーバー会社から通知が届いたものの、対応方法が分からない場合や、社内での作業が難しい場合は、まずは現在の状況をご相談ください。

サーバーの管理範囲や構成を確認し、必要な対応を一緒に整理していきます。

6. まとめ：パッチがないからといって、何もできないわけではない

今回のLinuxカーネルの脆弱性は、サーバーのセキュリティ対応を考えるうえで、重要な事例となりました。

修正パッチがすぐに利用できない場合でも、影響を確認し、適切な暫定対策を検討できることがあります。

ただし、暫定対策は根本的な解決ではありません。

大切なのは、「影響確認 → 暫定対策 → 動作確認 → 正式な修正」までを一連の対応として考えることです。

セキュリティ通知が届いた際には、まず自社の環境がどうなっているのかを把握することから始めてみてください。

参考情報

Ubuntu Security：CVE-2026-98432
https://ubuntu.com/security/CVE-2026-98432
Ubuntu：Fixes available in -proposed pocket for CVE-2026-98432（2026年11月2日）
https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432
Red Hat：RHSB-2026-016
https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
AWS：CVE-2026-98432 Security Bulletin
https://aws.amazon.com/security/security-bulletins/2026-160-aws/

※本記事は2026年11月4日時点の公開情報と、2026年11月3日に実施した対応事例をもとに作成しています。修正パッケージの提供状況は随時変わるため、最新の公式情報をご確認ください。