WSUS同期バグに手動修正手順、悪用済みのゼロデイパッチ配信を妨げる障害にMicrosoftが対応

関連記事 WSUS同期バグに手動修正手順、悪用済みのゼロデイパッチ配信を妨げる障害にMicrosoftが対応 Microsoftは、Windows Server Update Services(WSUS)の同期エラーを解消するための手動修正手順(KB5121986)を公開した。この同期エラーにより、すでに悪用が確認されている2つのゼロデイ脆弱性を含む月例パッチの配信が、多くの企業ネットワークで滞る事態となっていた。WSUS管理者は、速やかにデータベースのバックアップとクリーンアップクエリを実行し、パッチ適用を再開する必要がある。 ■同期障害の背景と影響 Microsoftは2026年7月22日、Windows Server Update Services(WSUS)サーバーがMicrosoft Updateと同期できなくなっている問題に対し、手動での修復手順(KB5121986)を公開した。この問題は、サーバー側のメタデータ累積が原因で発生し、企業のパッチ適用パイプラインがオフラインになってから8日が経過していた。この間、すでに悪用が確認されている2つのゼロデイ脆弱性のパッチが、数千の企業ネットワークでデプロイできない状態が続いていた。 この同期障害の影響は極めて深刻である。WSUSの停止によって配信が滞っていた脆弱性は、2026年7月の月例パッチ(Patch Tuesday)で修正されたものの中でも特に危険性が高く、米国サイバーセキュリティ・インフラセキュリティ庁(CISA)が定める連邦政府機関向けの対応期限の1つはすでに超過している。 今回の事態は、1年以上前から深刻化している構造的なリスクを浮き彫りにした。2026年7月の障害は、過去14ヶ月間で4回目となるWSUSの同期障害である。さらに、Microsoftは2024年9月にWSUSの非推奨化を正式に決定しており、信頼性向上のためのエンジニアリング投資は計画されていない。 ■同期障害の原因:何が起きたのか デフォルトでは、WSUSはMicrosoft Updateサーバーと1日1回同期し、利用可能なWindowsパッチの最新メタデータを取得する。製品カテゴリ、更新プログラムの分類、適用ルール、置き換え関係、検出ロジック(ディテクトイド)などを含むこのメタデータは、「SUSDB」(SQL Server Update Services Database)と呼ばれるSQLデータベースに蓄積される。今回の障害が発生したサーバーでは、蓄積されたメタデータの量が、MicrosoftのIISでホストされているアプリケーションプール「WsusPool」が1回の同期要求で処理できる上限を超えてしまい、タイムアウトや同期の完全な失敗を引き起こした。 その結果、影響を受けたWSUSサーバーでは、管理者がWSUSや、WSUSを上位カタログソースとして使用するMicrosoft Configuration Manager(SCCM)を通じて、新しいパッチの検出、承認、配信を行うことができなくなった。 MicrosoftはWindowsリリースヘルスダッシュボードでこの影響範囲を認めており、WSUSサーバーでの同期時間の増加やタイムアウトが発生する可能性を指摘していた。特に2026年7月の月例パッチ配信が始まる前日の7月13日から影響が顕著になったという。WSUSの階層構造を運用している環境では、同期パイプラインが各レベルで実行されるため、親サーバーからレプリカサーバーへと障害が連鎖した。 過去のいくつかのWSUSのトラブルとは異なり、今回の障害はクライアント端末に起因するものでも、不具合のある累積更新プログラムによるものでもない。原因は完全にMicrosoftの配信インフラ側にあり、サービス側および既存のWSUS環境内で過剰なメタデータが蓄積されたことで、同期処理の負荷が限界に達して破綻した。 ■配信が滞っていた2つの悪用済みゼロデイ脆弱性 今回の障害は、最悪のタイミングで発生した。WSUSの同期障害が深刻化した翌日の7月14日、Microsoftは同社の観測史上最大規模となる月例パッチをリリースした。これには3つのゼロデイ脆弱性を含む622件のCVE(共通脆弱性識別子)が含まれていた。 そのうち2つのゼロデイ脆弱性は、パッチが公開される前にすでに実際の攻撃で悪用されていることが確認されており、いずれもCISAの「既知の悪用された脆弱性(KEV)」カタログに追加されている。 1つ目の「CVE-2026-56164」は、オンプレミスのSharePoint Server(2016、2019、Subscription Edition)に影響する脆弱性で、認証されていない攻撃者がネットワーク経由で、資格情報やユーザーの操作なしに特権を昇格させることを可能にする。Microsoftの深刻度評価は「警告(Moderate)」(CVSSスコア5.3)だが、セキュリティ業界はこの評価に一斉に反発しており、米国の国立脆弱性データベース(NVD)は独自に「緊急(Critical)」(CVSSスコア9.8)と評価している。CISAは7月14日にこれをKEVカタログに追加し、連邦政府機関に対して7月17日までの対応を求めていたが、その期限はすでに過ぎている。 2つ目の「CVE-2026-56155」は、Active Directoryフェデレーションサービス(AD FS)に影響する。AD FSは、連携するすべてのアプリケーションが信頼する認証トークンを発行・署名するサービスである。この脆弱性が悪用されると、攻撃者はAD FSホストのローカル管理者権限を取得し、接続されているすべてのサービスで任意のユーザーになりすますトークンを偽造できるようになる。この脆弱性は、Microsoftのインシデント対応部門であるDART(Detection and Response Team)によって発見された。これは、実際の攻撃調査の過程で見つかったことを示唆している。CISAが定めるこの脆弱性の対応期限は7月28日である。 WSUSに依存している組織では、同期パイプラインが切断されている間、これら2つの脆弱性に対するパッチを適用できない状態が続いていた。本日公開された手動手順は、まさにこの問題を解決するためのものである。 ■部分的な修正により取り残された運用サーバー Microsoftは7月18日に対策を講じたものの、それには大きな制限があった。サーバー側の緩和策によって同期パフォーマンスが回復したのは、新規にインストールされた、または再構築されたWSUSサーバーのみだった。長年にわたってメタデータが蓄積されている、企業の大部分を占める既存の運用WSUSサーバーは、取り残されたままだった。 Microsoftは、新規インストールや再構築された環境で同期が回復したことを確認しつつ、既存のサーバーから問題のあるメタデータを安全に削除するための手順を準備中であると説明していた。それが本日公開されたガイドラインである。 多くの組織にとって、運用のWSUSサーバーを再構築することは容易ではない。完全な再構築を行うと、事前に慎重に記録して復元しない限り、長年設定してきたコンピュータグループ、承認ルール、下位のSCCMデプロイ関係などが消去されてしまう可能性がある。そのため、Microsoftが安全性を確認した手動クリーンアップ手順を実行することが、影響を受けた多くの環境にとって現実的な解決策となる。 ■手動によるSUSDBクリーンアップ:管理者が行うべき手順 Microsoftが公開したKB5121986のガイドラインでは、同期を正常に再開するために、以下の3つの主要な操作を順番に実行することを求めている。 第1に、変更を加える前に、レプリカサーバーを含むWSUS階層内のすべてのSUSDBデータベースのバックアップを作成すること。SUSDBはWSUS運用の要であり、データベースに対する操作を行う前に復元ポイントを確保することは必須である。 第2に、すべてのSUSDBインスタンスに対して、SQL Server Management Studio(SSMS)からクリーンアップクエリを実行すること。このクエリは、適切に整理されずに蓄積された「ディテクトイド(検出ロジック)」のメタデータを対象としており、既存のパッチ承認やデプロイ設定に影響を与えることなく、安全に削除できる行を削除する。 第3に、レジストリ値「MaxXMLPerRequest」をデフォルト設定に戻すこと。この値は、IISのWsusPoolアプリケーションプールが1回の同期要求で処理するXMLの量を制御する。以前の回避策でこの値を変更していた場合、今回のクリーンアップによって調整が不要になるため、元に戻す必要がある。 これら3つのステップを完了した後、Microsoftは管理者に対し、SUSDBのインデックス再作成、WSUSサーバークリーンアップウィザードの実行、そしてキャッシュされたカタログ状態をクリアするための「IISReset」またはWsusPoolアプリケーションプールのリサイクルを実行するよう指示している。クリーンアップ後の最初のWindows Updateスキャンは通常より時間がかかる場合があるが、それ以降のスキャンは正常化する。また、ディテクトイド削除後もクライアント側の「DataStore.edb」ファイルは自動的には縮小しないが、これは想定された挙動であり、スキャン性能には影響しない。 WSUSの階層構造を管理している場合は、すべてのレプリカサーバーを含む環境内のすべてのSUSDBに対してこのクリーンアップを実行する必要がある。最上位のサーバーだけで実行しても、下位サーバーの問題は解決しない。 ■14ヶ月で4回の障害:なぜ問題が繰り返されるのか 今回の同期障害は、過去14ヶ月間で4回目となる。Microsoftは2025年5月、7月、8月にも同様のWSUS同期障害に対処しており、その都度インフラレベルでの介入が必要となり、企業のパッチ適用スケジュールが遅れる原因となっていた。 このパターンが意味するのは、個々の障害の深刻さだけでなく、問題が繰り返されているという事実である。Microsoftは2024年9月20日にWSUSの非推奨化を発表し、新機能の開発や機能要望の受付を終了した。セキュリティ更新プログラム自体は引き続きWSUSチャネルを通じて提供され、当面の間は機能し続けるものの、信頼性やアーキテクチャの改善に対するエンジニアリング投資は計画されていない。Microsoftが推奨する移行先は、クライアント端末向けには「Windows Autopatch」や「Microsoft Intune」、サーバー向けには「Azure Update Manager」といったクラウドネイティブなツールである。 14ヶ月で4回という障害頻度は、「非推奨」が必ずしも「安定」を意味しないことを示している。Microsoftが積極的に開発していないインフラは、今回露呈したようなメタデータの蓄積や同期のスケーラビリティ問題に対して、積極的な強化(ハードニング)も行われない。WSUSを使い続ける組織は、Microsoftが戦略的に手を引いた製品を維持するという、継続的な運用リスクを受け入れていることになる。 さらに今回の障害を複雑にしたのは、問題の発生源が上位の配信インフラ側にある点である。ローカルデータベースの破損や更新プログラムの不具合とは異なり、今回の障害は完全にMicrosoft自身のメタデータ配信サービスに起因していた。そのため、管理者が初期の障害を防ぐ手立てはなかった。影響を受けたすべての運用サーバーで必要となる手動クリーンアップは、組織側が招いたものではないが、避けることのできない復旧作業となっている。 ■管理者が今すぐ行うべき対応 同期障害が発生している既存のWSUSサーバーを運用している組織は、KB5121986に従い、バックアップ、クリーンアップクエリの実行、MaxXMLPerRequestのリセットを順に実行する必要がある。バックアップの手順は決して省略してはならない。また、クリーンアップはプライマリサーバーだけでなく、階層内のすべてのSUSDBに対して実行する必要がある。 クリーンアップを完了する前に手動同期を繰り返しても、根本的な問題は解決せず、復旧作業の時間を無駄にするだけである。まずはクリーンアップを最優先で実行すべきだ。 同期が復旧した後は、2026年7月の累積更新プログラムのデプロイを最優先課題として進める必要がある。特に、CVE-2026-56164のパッチはすべてのオンプレミスSharePoint Serverインスタンスに適用し、インターネットに公開されている環境を優先すること。また、CVE-2026-56155のパッチはすべてのAD FSインフラに適用する必要がある。AD FSの脆弱性については、CISAの対応期限である7月28日が迫っているため、迅速にクリーンアップを行えば期限内の対応が可能である。 WSUSを今後も長期的に使い続けるべきか検討している組織にとって、今回の障害は一過性のトラブルではなく、重要な判断材料となる。Microsoftのクラウドネイティブな代替手段(Windows Update for Businessポリシーを組み合わせたIntune、Windows Autopatch、Azure Update Managerなど)は、ローカルでSQLカタログを保持しないため、サーバー側でのメタデータ累積という同様のリスクを抱えていない。移行の決定は急を要するものではないが、頻発する障害のパターンは、移行コストを評価する上での明確な運用リスクとして考慮されるべきである。 ■注目ポイントQ&A ●Microsoftが本日公開したWSUSの同期修正プログラムとはどのようなもので、実行しても安全ですか? Microsoftが公開したKB5121986のガイドラインは、WSUSのSQLデータベース(SUSDB)をバックアップし、蓄積された不要なディテクトイド(検出ロジック)メタデータを安全に削除するSQLクエリを実行した上で、MaxXMLPerRequestレジストリ値をデフォルトに戻すよう指示しています。Microsoftは、このクエリが対象とするメタデータは既存の環境から安全に削除できることを確認しています。このクリーンアップによって、既存の更新プログラムの承認、コンピュータグループ、デプロイ設定が影響を受けることはなく、同期タイムアウトの原因となっていた古いメタデータのみが削除されます。 ●7月18日の修正が、既存のWSUSサーバーではなく新規サーバーにしか効果がなかったのはなぜですか? Microsoftが7月18日に実施したサービス側の緩和策は、配信パイプラインをクリーンにすることで、新規にインストールまたは再構築されたWSUSサーバーが今後問題のあるメタデータを蓄積しないようにするものでした。しかし、既存の運用サーバーには、サービス側の修正が適用される前に、ローカルのSUSDBデータベースに問題のメタデータがすでに蓄積されていました。そのため、これらの既存サーバーではローカルデータベースのクリーンアップを個別に行う必要があり、それが本日公開されたKB5121986の手順となっています。 ●WSUSの同期障害によって配信が妨げられていた脆弱性と、その深刻度について教えてください。 最も深刻なのは、すでに悪用が確認されているSharePoint Serverの脆弱性「CVE-2026-56164」と、AD FSの脆弱性「CVE-2026-56155」です。前者は認証なしでリモートから特権昇格が可能な脆弱性で、Microsoftの評価は「警告(5.3)」ですが、NVDは独自に「緊急(9.8)」と評価しています。後者は認証トークンの署名インフラのローカル管理者権限を奪取される恐れがある極めて危険な脆弱性です。いずれもCISAの「既知の悪用された脆弱性(KEV)」カタログに追加されており、SharePointの対応期限(7月17日)はすでに超過、AD FSの対応期限(7月28日)が迫っています。 ●この障害を受けて、組織はWSUSからの移行を検討すべきでしょうか? Microsoftは2024年9月にWSUSの非推奨化を発表しており、今後の機能改善などの投資は予定されていません。今回の同期障害は過去14ヶ月間で4回目(過去には2025年5月、7月、8月にも発生)であり、その都度手動での対応が必要となり、パッチ適用の遅れを招いています。Microsoftが推奨する代替手段(クライアント向けのMicrosoft IntuneやWindows Autopatch、サーバー向けのAzure Update Manager)は、ローカルにSQLメタデータを保持しないため、同様の障害は発生しません。移行にはコストや設定の手間がかかりますが、WSUSの度重なる障害は明確な運用リスクとなっており、移行コストを検討する際の重要な要素となります。