さくらのクラウドが脆弱性対応の保守予定を案内！新規プロジェクト停止と稼働中の確認点

さくらのクラウドは2026年10月19日、Linuxカーネルの脆弱性CVE-2026-99999への対応情報を更新し、順次メンテナンスを実施する予定を追記しました。対象者には、実施日の1週間前を目途に日時や影響などを登録メールアドレスへ案内するとしています。

同サービスでは10月16日から新規プロジェクトの作成を一時停止しています。一方、作成済みプロジェクトは利用でき、この作成停止に伴う既存リソースの稼働への影響はないと説明しています。「作れない」と「止まっている」は別の状態です。

本記事は、10月19日の保守予定の追記を受けたニュースです。脆弱性の公表日は10月15日、クラウドの告知公開日は10月16日、今回確認した更新日は10月19日、情報確認日は日本時間10月20日です。これらは攻撃や被害の発生日を意味しません。

まず公式告知から分かる範囲を確認する

停止しているのは、さくらのクラウドの作業空間である「プロジェクト」の新規作成です。再開時期は決まり次第案内するという状況で、この記事で再開日を予測することはできません。専用サーバ PHY、高火力PHYも、申し込みに新規プロジェクト作成が必要な場合は申し込めないと案内されています。

この説明を、既存プロジェクト内のすべての操作が停止しているという意味へ広げてはいけません。反対に、既存リソースが稼働していることから、今後のメンテナンスも無影響だとは判断できません。具体的な作業日時と影響は、自分が対象となる案内で確認する必要があります。

さくらのクラウド：CVE-2026-99999への対応状況（10月19日更新）

脆弱性はWebアプリではなくカーネルの処理に関わる

Linux kernel CVE teamの公表資料は、不適切なチェックサムのメタデータを持つパケットがIPv4の処理へ入り、チェックサムを補う処理でネットワークヘッダーが壊れる問題を説明しています。入力側のより完全な検証には追加作業が必要とも記載されています。

同資料のCVSS v3.1は9.3で、評価ベクトルの攻撃元区分はローカルです。高いスコアを見て「公開Webサイトへ外部からアクセスするだけで、どのサーバーも侵害できる」と言い換えるのは不正確です。自社構成の影響は提供元の説明と照合してください。

上流カーネルには修正が案内されていますが、それだけで各クラウドや各OS配布元の対応が完了したとは言えません。また、今回確認したクラウド告知は利用者の情報漏えいや侵害の発生を示すものではありません。本記事でも被害確認やAIを用いた攻撃とは扱いません。

Linux kernel CVE team：CVE-2026-99999公表資料

ホストとゲストの対応を同じチェック欄にしない

ここからは本サイトが提案する運用手順です。仮想サーバーでは、クラウド事業者が管理するホスト側と、利用者が管理するゲストOS側を分けて考えます。どちらもLinuxという名前でも、管理権限、適用する更新、再起動の担当は同じではありません。

例えば、利用者が仮想サーバー内でパッケージを更新しても、その作業は事業者が管理する基盤の更新を証明しません。事業者の保守が終わっても、自分が管理するゲストOSの更新状態が自動的に確認済みになるわけではありません。

契約形態によって利用者がOSを操作できない場合もあります。レンタルサーバーや運用代行付きの契約では、別サービス向けの手順を流用せず、契約した製品の告知と管理範囲を確認します。カーネルを操作できない担当者へ更新作業だけを依頼しても、対応は進みません。

最初の作業は対象資産と通知先の棚卸し

クラウドの契約名、プロジェクト、利用中のリソース、OS管理者、保守窓口、登録メールの受信者を一覧にすることを提案します。制作会社が開設して引き渡した環境では、現在の運営者が保守通知を受け取れるかも確認してください。

連絡を受けた人が影響を判断できず、実作業の担当者には届かない状態がないかを点検します。対象かどうか分からない場合は、契約情報を添えて正規のサポート窓口へ確認し、推測した日程を社内へ流さないようにします。

本番だけでなく、検証、バッチ処理、メール連携、監視などの用途も整理します。サイト自体が表示されていても、別の仮想サーバー上の処理が遅れると注文確認や通知へ影響することがあります。これは今回の被害を示す説明ではなく、保守の影響を洗い出すための一般的な観点です。

新規作成の制限は移行や復旧の計画にも関係する

説明用の仮想例として、来週のサイト移転に合わせて新しいプロジェクトを作り、そこで検証してから切り替える計画を考えます。稼働中のサイトが正常でも、予定した作業の入口が使えなければ、移行日や検証期間の見直しが必要になります。

自社の復旧手順が「障害時に新規プロジェクトを作る」ことを前提にしている場合も、手順が現在実行できるかを確認します。ただし今回の制限から、バックアップを復元できない、既存プロジェクトへ追加できないなどと一律に断定してはいけません。必要な操作を個別に確認してください。

対応を急ぐあまり、別の環境へ本番データを無審査でコピーすることも避けます。代替先を使う場合は、契約、アクセス制御、データの扱い、切り戻し条件を確認し、元の制限を回避できたことだけを成功基準にしないようにします。

計画を変更する場合は、公開予定日だけでなく、検証に使える時間と切り戻しの期限も関係者へ共有します。制限が解除された直後に検証を省略して本番へ移すのではなく、通常必要な確認を実施できる日程を取り直してください。納期と安全確認の両方を明示することが重要です。

ゲストOSの修正状況は配布元の単位で調べる

上流の公表資料には修正版が複数のカーネル系列ごとに示されています。しかし、OS配布元が修正を取り込むと、上流と異なるバージョン表記のパッケージになることがあります。数字の見た目だけで修正済みかどうかを判定せず、使用する配布元のCVE情報とパッケージ情報を参照します。

今回確認したUbuntuの情報では、linuxパッケージの複数のリリースが「Needs evaluation」とされていました。評価待ちという記載は、安全とも悪用確認済みとも同義ではありません。他のパッケージや配布元の状態まで同じだとみなさず、対象の行と更新日時を確認してください。

Ubuntu：CVE-2026-99999の評価・パッケージ状況

更新の導入と実際の反映を分けて記録する

本サイトでは、更新前の実行中カーネル、導入済みパッケージ、更新対象、必要な再起動や反映手順を担当者が確認することを提案します。Linuxでは更新パッケージをインストールしても、実行中のカーネルがその場で置き換わるとは限りません。

再起動やライブパッチの扱いは構成と提供元の手順に従います。記事にある上流の修正版へ独自に入れ替えることを全利用者へ勧めるものではありません。サポート対象のカーネルから外れると、ドライバーや監視、バックアップなどへ別の影響を与える可能性があります。

作業記録には「更新を実行した」だけでなく、実行中の版、配布元の修正情報、反映の確認方法と結果を残します。ホスト側については、利用者が中身を調べられないからと無理に検証せず、事業者の完了通知や問い合わせ回答を根拠として保存します。

保守前はバックアップと継続中の処理を確認する

保守日時の案内を受けたら、影響対象、停止や再起動の有無、作業時間帯、利用者側の準備を読み取ります。公式告知の「1週間前を目途」という案内は、個々の作業が何分で終わるかを保証するものではありません。

準備として、バックアップの取得結果と復元手順を確認します。バックアップがあることと、必要な時点までデータを戻せることは別です。データベースとアップロードファイルの整合性、保存先へ接続するための権限なども、既存の運用手順で確かめてください。

注文処理、決済連携、予約、定期ジョブのような状態を持つ処理では、中断した場合の再実行条件を確認します。二重送信や二重処理を避ける方法をアプリ側で整理しておくと、保守後に単にジョブを動かし直すだけで問題を増やすことを防げます。

保守後は表示以外の業務フローも検証する

作業後の確認は、トップページが表示されたかだけで終えないことを提案します。管理画面へのログイン、フォーム送信、画像の表示、外部APIへの接続、メール通知、定期処理など、普段のサービスに必要な機能を対象にします。

検証には実取引を発生させない方法を選び、本番の決済や利用者への一斉通知を不用意に実行しないでください。監視の一時停止を設定した場合は解除を確認し、作業前後のエラー率や処理の遅延を比較します。

問題があれば発生時刻、対象リソース、操作、エラーを記録し、保守の案内番号と合わせて問い合わせます。すべてを今回の脆弱性のせいと決めつけず、更新や再起動で表面化した別の設定問題も含めて切り分けることが必要です。

対応済みの条件と残る不確実性

今回のニュースから必要なのは、慌ててすべてのサイトを停止することではなく、契約したサービスの制限と保守予定を把握することです。新規作成の停止、既存リソースの稼働、将来の保守の影響を分けると、関係者へ必要な判断を伝えやすくなります。

本サイトでは、対象環境の確認、通知の受信、担当範囲ごとの修正確認、必要な反映作業、保守後の検証を別々に記録することを提案します。未確認の環境や配布元の評価待ちは、対応済みへまとめず残してください。

事業者の告知だけでは自社の侵害有無は判定できません。異常な通信や不審な操作などが別に見つかった場合は、脆弱性対応とは別に組織のインシデント対応へ進めます。最新の作業予定はこの記事の掲載日ではなく、契約先の公式告知と個別通知を確認してください。