2025年12月のWindowsセキュリティ更新を入れた直後から、IIS（Internet Information Services：Webサーバー）上のアプリが突然つながらない、MSMQ（Message Queuing：メッセージキュー）が止まって業務が詰まる、しかもログが「リソース不足」っぽい嘘をつく――そんな報告が増えています。とくに企業の古めサーバーやESU（Extended Security Updates：延長セキュリティ更新）環境で刺さりやすく、復旧優先の判断が迫られがちです。今日は「何が壊れたのか」と「いま現場で効く直し方」を、コメント欄が盛り上がる前提でまとめます。

いま起きていることを一言で

12月9日の更新でMSMQの保存先フォルダー権限が変わり、書き込みできずにIISが落ちる・キューが止まる症状が出ています。 (BleepingComputer)

MSMQはアプリ同士の「非同期の伝言板」みたいな仕組みで、表に出にくいけど、POS（Point of Sale：販売時点情報管理）や工場系、監視系みたいな“止まると困るやつ”が静かに依存してたりします。GBHackers系の報道でも、負荷が高い環境やクラスター（cluster：冗長構成）で障害が目立つ、とされています。 (gbhackers.com)

発生日時と対象KB・ビルド

起点は2025年12月9日公開の月例更新（Patch Tuesday）で、既知の問題として認められた後、12月18日に定例外（out-of-band：OOB）更新が出ました。 (BleepingComputer)

まず「自分の環境が当たりか」を、KB番号とOSビルドで殴り合わせるのが早いです。

Windows 10系（ESU/LTSC含む）だと、KB5071546（OSビルド 19045.6691/19044.6691）がトリガーになりやすい、とMicrosoftが説明しています。 (Microsoft サポート)
Windows Server 2019ならKB5071544（OSビルド 17763.8146）。 (Microsoft サポート)
Windows Server 2016ならKB5071543（OSビルド 14393.8688）。 (Microsoft サポート)

そして修正版（OOB）はざっくりこの3つが中心です。
Windows 10 22H2（ESU）/Enterprise LTSC 2021：KB5074976（OSビルド 19045.6693/19044.6693） (Microsoft サポート)
Windows Server 2019/Enterprise LTSC 2019：KB5074975（OSビルド 17763.8148） (Microsoft サポート)
Windows Server 2016/Windows 10 version 1607：KB5074974（OSビルド 14393.8692） (Microsoft サポート)

出やすいエラー表示とエラーコード

見た目は「リソース不足」でも、実態は権限（permission：アクセス許可）で書けないだけ、が今回のイヤらしい点です。 (BleepingComputer)

現場で多いのはこのへん。
「Insufficient resources to perform operation（操作を実行するためのリソースが不足しています）」でIISやアプリが落ちる。 (BleepingComputer)
System.Messaging.MessageQueueException で同趣旨の例外が出る。 (Microsoft Learn)
エラーコードが付く場合は 0x80004005 が報告されています。 (4sysops.com)
さらに厄介なのが「There is insufficient disk space or memory（ディスク領域またはメモリが不足しています）」みたいな false positive（誤検知）系のログ。増設を考えた人、わかる…その気持ち。 (BleepingComputer)

原因は何か（推定じゃなく公式説明ベース）

更新で C:\Windows\System32\MSMQ\storage のNTFS権限が締まり、非管理者の実行主体が書き込めなくなったのが根っこです。 (Microsoft サポート)

Microsoftの説明はわりと直球で、「MSMQのセキュリティモデル変更」により、通常は管理者に制限されるフォルダーへ“MSMQユーザーが書き込み権限を必要とする状態”になった、とされています。結果としてMSMQ API経由の送信がリソース系エラーに化けて失敗する。クラスター環境で負荷がかかると症状が出やすい、も同じ文脈です。 (Microsoft サポート)

ここ、地味に重要で。「ディスク不足」でも「メモリ不足」でもなく、書けない。つまり“詰まってるのは権限”です。don’t だまされて。

そもそも「脆弱性」と何が関係あるの？

今回の発端はMSMQの脆弱性（CVE-2025-62455）対応の一環とみられ、硬化（hardening：堅牢化）が互換性を踏んだ形です。 (NVD)

CVE-2025-62455はNVD上では「不適切な入力検証（improper input validation）」によるローカル特権昇格、と整理されています。 (NVD)
で、セキュリティ修正は当然当てたい。でも当てたら止まった。ここで現場は二択に追い込まれがちです。
「セキュリティ優先で止まった業務をどう戻す？」
「業務優先で戻したら、脆弱性面はどう担保する？」
コメント欄、ここ一番意見が割れそう。あなたはどっち派？

公式対応状況（いまは直った？）

Microsoftは既知の問題として認め、12月18日（現地時間）にOOB更新をMicrosoft Update Catalogで提供して解消済み扱いです。 (Microsoft Learn)

Windows Release Health（リリース正常性）にも「解決済み（Resolved）」としてKB5074976等が案内されています。 (Microsoft Learn)
窓の杜も、複数OS向けに定例外パッチが出たことをまとめています。 (窓の杜)
なお個人のWindows Home/ProではそもそもMSMQが有効化されていないことが多く、影響は「企業・管理ITが中心」と明言されています。 (BleepingComputer)

他ユーザーの報告（フォーラムの生声）

コミュニティ側では「KBを戻したら直った」「IISから送ると落ちる」がかなり早い段階で共有されました。 (Microsoft Learn)

Microsoft Q&Aでは、IISのWebアプリからSystem.Messagingで送った途端に MessageQueueException が出て、Server 2019はKB5071544、Server 2016はKB5071543をロールバック（rollback：更新取り消し）すると復旧した、という具体例が出ています。 (Microsoft Learn)
Redditのr/sysadmin系メガスレでも、今月の「何が壊れた？」枠としてMSMQが話題に上がり、CVEとの関連やOOB配布の話が流れていました。 (Reddit)

あなたの現場でも「更新直後から突然」でした？それとも「負荷が上がった瞬間だけ」？その差、けっこうヒントになります。

まずやるべき影響確認（切り分け）

KBとビルドとエラーメッセージが揃ったら、ほぼ今回の事象です。 (BleepingComputer)

(1) winver か「設定→更新の履歴」で、KB5071546/KB5071544/KB5071543 の有無とOSビルドを確認します。 (BleepingComputer)
(2) アプリログ／イベントログで「Insufficient resources to perform operation」や「disk space or memory」系が混ざっていないか見ます。 (BleepingComputer)
(3) IISのアプリプールID、NetworkService、特定サービスアカウントなど、“誰がMSMQを叩いているか”を洗い出します。ここを外すと直したつもりで再発します、たぶん。 (Microsoft Learn)

対処の現実解はだいたい3ルート

最優先はOOB更新（KB5074976/KB5074975/KB5074974）の適用で、次点がロールバック、最後が暫定の権限調整です。 (窓の杜)

(1) 正攻法：OOB更新を入れる
Microsoft Update Catalogから該当KBを入れる流れです。Release Healthでも「カタログでOOBを出した」と案内されています。 (Microsoft Learn)
Windows 10 ESU/LTSCはKB5074976、Server 2019はKB5074975、Server 2016はKB5074974。ここ、間違えると当然入らないので注意。 (窓の杜)

(2) 業務復旧優先：問題のKBをアンインストール
「今すぐ止血」が必要なら選ばれがちです。実際にロールバックで直った報告は複数あります。 (Microsoft Learn)
ただし、元のセキュリティ修正（CVE対応）も一緒に外す可能性があるので、戻したら戻したで“いつOOBを当て直すか”までセットで決めないと、あとで心がしぬ。 (NVD)

(3) 暫定回避：storageフォルダーのACL調整
原因が ...\MSMQ\storage の書き込み権限であることはMicrosoft側も説明しています。 (Microsoft サポート)
なので「MSMQを動かす実行主体にだけ必要最小限の書き込み権限を付ける」という発想になりますが、権限を広げすぎると別のリスクを呼ぶので、ここはチームのセキュリティ方針と要相談。やるなら“期限付きの暫定”で扱うのが無難です。 (Microsoft サポート)

ひとつだけ考察：なぜこんな“壊れ方”をした？

今回の教訓は「セキュリティの意図」と「運用の前提（サービスアカウント権限）」がズレると、エラー文が平気で嘘をつくことです。 (Microsoft Learn)

MSMQって、現代の派手な仕組みじゃないぶん、昔の設計のまま“暗黙の前提”で動いてるケースが多い。そこにhardeningが入ると、正しくは「Access Denied（アクセス拒否）」なのに、上の層が「リソース不足」に丸めて投げてくる。だから現場は増設や監視調整に走って時間を溶かす。いや、ほんとに辛い…（ここで一回だけ誤字っぽく言うと、しんどぃ）。

あなたの環境では、MSMQを誰の権限で動かしてました？ LocalSystem？ NetworkService？アプリプールID？その違い、たぶん再発率に効きます。

コメント欄をフォーラム化：投稿テンプレ

同じ症状でもOS・KB・実行主体で分岐するので、環境情報が集まるほど助かります。

コメントするなら、こんな感じで書いてくれると他の人が救われます。
「OS：Windows Server 2019／ビルド：17763.8146／更新：KB5071544／症状：IISが500、MSMQ inactive／エラー：Insufficient resources…（0x80004005）／対処：KB5074975で復旧」
「OS：Windows 10 22H2（ESU）／ビルド：19045.6691／更新：KB5071546／症状：キュー書き込み不可／ログ：disk space or memory／対処：OOB待ち→KB5074976でOK」

で、あなたはどれに近い？それとも「うちは違う落ち方した」派？そこがいちばん面白いところです。