December 2025 MSMQ Patch Breaks Write Access: Rollback and ACL Workarounds

Microsoft’s December Patch Tuesday has produced a painful and immediate headache for enterprises that still rely on Microsoft Message Queuing (MSMQ): multiple cumulative updates released on December 9–11, 2025 changed MSMQ’s filesystem security semantics and, in many environments, prevented non‑privileged processes (IIS application pools, LocalService/NetworkService identities and similar) from writing to MSMQ storage. The result is inactive queues, “Insufficient resources” errors from applications and IIS sites, and stalled business workflows. The regression has been widely reported by administrators and mapped to the December KB rollups that include fixes for CVE‑2025‑62455, while vendor channels and community forums continue to sort out the right balance between rapid remediation and preserving hardening goals.

---

Background / Overview​

MSMQ is an optional Windows component but still a critical piece of middleware in many enterprise estates. It provides durable, asynchronous message delivery that underpins integration layers, legacy line‑of‑business systems, and some IIS‑hosted applications. Changes to how MSMQ persists messages or to access control for its storage folder can therefore cascade quickly into application outages.
The December 2025 cumulative updates (LCUs) for a range of Windows SKUs — including KB5071546 (Windows 10 22H2), KB5071544 (Server 2019-era bundles), and KB5071543 (Server 2016-era bundles) — were released with security fixes mapped to CVE‑2025‑62455 (an MSMQ elevation‑of‑privilege class entry) and other important patches. Administrators started reporting broken MSMQ behavior within hours to days of those updates being applied. What makes the incident particularly tricky is that the visible error messages — “Insufficient resources to perform operation,” or messages claiming disk space or memory problems — are misleading. Under the surface the failure is permission‑related: MSMQ operations that create or append storage files fail because the identity that previously could write to the MSMQ storage folder no longer has that write access. Community triage and vendor Q&A threads show the security descriptor for C:\Windows\System32\MSMQ (and subfolders such as storage) was altered by the December rollups, which broke the historical behavior many apps relied on.

---

What changed — technical root cause​

The filesystem ACL change​

The core regression stems from a change in the MSMQ security model applied by the December cumulative updates. Administrators who inspected the on‑disk security descriptor found that the NTFS DACL on the MSMQ folder was modified so that identities which previously could create the .mq storage files are now denied the required write access. In short:

• The patch modified the NTFS security descriptor for the MSMQ folder (C:\Windows\System32\MSMQ and/or C:\Windows\System32\MSMQ\storage).
• Non‑privileged service identities (IIS_IUSRS, LocalService, NetworkService, specific app‑pool identities) that previously wrote messages can no longer create storage files.
• MSMQ code paths report resource allocation failures (insufficient memory/disk or “insufficient resources”), which masks the true access‑denied cause.

Why the errors look like resource exhaustion​

Because MSMQ persists messages on disk and allocates files dynamically, a failed file create or append can bubble up as a low‑level resource error inside the MSMQ stack, which is why admins often chase disk quotas or memory metrics first. The misleading symptoms extend triage time and increase the risk of inappropriate remediation steps (like forcing apps to run as LocalSystem).

---

Symptoms and real‑world impact​

Administrators and helpdesk teams have reported a consistent set of operational symptoms after applying the December updates:

• Queues appear inactive and stop accepting messages; producers report failures when writing to queues.
• IIS‑hosted services and .NET apps throw System.Messaging.MessageQueueException: Insufficient resources to perform operation.
• Event logs show MSMQ storage file creation failures (unable to create the *.mq files under the MSMQ storage folder).
• Clustered MSMQ nodes under load can fail simultaneously, compounding recovery.

Because MSMQ often supports critical systems — payment processing, order routing, archival sinks and more — the outage mode is not limited to a single server: queues back up, downstream processors stall, and error cascades can cause service‑level impacts for customer‑facing applications.

---

Platforms and updates implicated​

Community analysis and vulnerability trackers map the regression to several December 2025 cumulative packages:

• KB5071546 — Windows 10 (22H2 family) cumulative update.
• KB5071544 — Windows Server 2019 / matching branch cumulative update.
• KB5071543 — Windows Server 2016 / legacy branch cumulative update.

Security trackers (vulnerability databases) correlate CVE‑2025‑62455 with these KB packages, indicating the MSMQ-related fixes were included in those rollups. This helps explain why environments that skipped or deferred the December LCU avoid the regression — but it also means simply avoiding the patch leaves systems exposed to the security fixes the update contains.

---

Vendor response and inconsistent messaging​

Microsoft’s official cumulative KB pages (the individual KB articles for the December rollups) initially did not list this MSMQ behavior as a known issue; their KB pages for the December updates show the usual “We are currently not aware of any issues with this update” boilerplate at the time of publication. However, a Microsoft Q&A thread and multiple Microsoft community channels show Microsoft acknowledged they are receiving reports and a Microsoft moderator confirmed the matter would be investigated. That mismatch between the public KB text and vendor‑side support channels has increased confusion and delayed a single, authoritative mitigation recommendation. Administrators should treat the situation as active and watch for an updated KB or hotfix. Note: Because vendor KBs and community reports diverged initially, some third‑party trackers (Rapid7 and similar) mapped the CVE and KBs immediately; that mapping provides useful cross‑validation but is not a substitute for a Microsoft‑issued workaround or hotfix. Administrators should monitor Microsoft release channels for an official remediation.

---

Practical mitigations — trade‑offs and step‑by‑step runbook​

There are two practical mitigation strategies that organizations have used in the field. Each carries clear trade‑offs.

Option 1 — Roll back the problematic LCU (preferred from a security posture)​

Uninstall the specific December LCU from affected hosts and reboot. This generally restores the previous ACL model and returns MSMQ to normal behavior.
Key notes and steps:

• Identify the installed package name with DISM:
• DISM /Online /Get-Packages
• Remove the LCU package:
• DISM /Online /Remove-Package /PackageName:<name-of-lcu-package>
• Reboot and validate MSMQ behavior (test writes, check Application/System event logs).

Caveats:

• If the update was delivered as a combined SSU+LCU package, wusa.exe /uninstall will not remove the SSU; Microsoft documents specific removal steps and warns that servicing stack changes can complicate rollback. Read the KB’s “If you want to remove the LCU” section carefully before attempting removal. Rolling back removes the regression but also removes the security fixes contained in the LCU, which may not be acceptable for high‑risk exposure.

Option 2 — Apply a narrowly scoped NTFS ACL workaround (fastest operational fix, higher security risk)​

Grant minimal write/modify permissions on C:\Windows\System32\MSMQ\storage (or the specific MSMQ storage folder) to the exact identities that need to write (IIS app pool identity, the service account for the application, LocalService/NetworkService if applicable). This restores queue writes without changing the process identity to Administrator.
Practical steps (example checklist):

• Identify the exact identity that needs write access:
• For IIS: check the application pool identity (e.g., ApplicationPoolIdentity or a named service account).
• For services: note the Windows service Log On As identity.
• Apply a least‑privilege ACL limited to the specific folder (avoid giving write access to the whole System32 tree).
• Example PowerShell pattern (adapt and test before use):
• $acl = Get‑Acl "C:\Windows\System32\MSMQ\storage"
• $rule = New‑Object System.Security.AccessControl.FileSystemAccessRule("DOMAIN\svc_mymq","Modify","ContainerInherit,ObjectInherit","None","Allow")
• $acl.AddAccessRule($rule)
• Set‑Acl "C:\Windows\System32\MSMQ\storage" $acl
• Restart the MSMQ service and any dependent services (e.g., Net.MsmqActivator, IIS app pools) and validate message sends succeed.

Critical cautions:

• Granting write access under System32 increases attack surface. Only grant the minimal account and operations required, enable auditing on that folder while the workaround is active, and plan to revert the rule as soon as Microsoft issues an official fix. Document the change and include it in incident logs. Community reports show this approach restores operations in many cases, but it is explicitly a temporary mitigation, not a best practice.

---

Detection and triage checklist​

A compact triage runbook an administrator can follow:

• Confirm MSMQ presence:
• GUI: Control Panel → Programs and Features → Turn Windows features on or off → look for Microsoft Message Queuing.
• PowerShell: Get‑WindowsOptionalFeature -Online | Where‑Object { $_.FeatureName -like "MSMQ*" }.
• Server: Get‑WindowsFeature MSMQ.
• Reproduce and capture error events:
• Look for System.Messaging exceptions in Application/System event logs.
• Search event text for “message file cannot be created” or similar MSMQ storage failure messages.
• Use Get‑WinEvent or PowerShell to export recent MSMQ‑related events for analysis.
• Validate queue status:
• Computer Management → Services and Applications → Message Queuing → check queue state (active/inactive).
• If you suspect ACL change:
• Compare the security descriptor (Get‑ACL) on C:\Windows\System32\MSMQ and the storage folder against a known good host or baseline.
• Decision point:
• If production outages are critical and rollback is permitted per change control, remove the LCU as described in Microsoft guidance.

---

Security trade‑offs and recommended guardrails​

This incident is a classic example of the tension between hardening and backwards compatibility:

• The December patches were intended to close an MSMQ elevation‑of‑privilege class issue (CVE‑2025‑62455), which is a legitimate security objective. Vulnerability trackers confirm Microsoft shipped fixes for that CVE across affected SKUs. Applying security fixes promptly is crucial.
• However, a change in NTFS ACL semantics for a system folder without a compatibility shim or documented guidance breaks outlying but legitimate application behavior. The result is operational downtime for many customers.

If you must apply a temporary ACL workaround, mitigate the additional risk by:

• Limiting ACL grants to the single service account or app‑pool identity that needs access.
• Applying the ACL only to the specific MSMQ storage folder, not the parent System32 folder.
• Enabling file‑system auditing on the storage folder and forwarding audit logs to your SIEM.
• Scheduling a rapid follow‑up change to remove the ACL once Microsoft publishes an official fix.

---

Historical context — why MSMQ still matters and past vulnerabilities​

MSMQ has been targeted repeatedly by security researchers and attackers. A high‑severity Remote Code Execution vulnerability, CVE‑2023‑21554, was disclosed in April 2023 and sparked emergency patching because an unauthenticated attacker could send a malicious MSMQ packet to achieve remote code execution on an MSMQ server. That event underscored the real risk the protocol presents when exposed and the reason many organizations keep MSMQ patched or disabled when unused. The April 2023 advisory and follow‑ups serve as context: hardening MSMQ is valid from a security standpoint, but hardening that breaks legitimate tenant workloads without mitigation guidance causes operational risk.

---

Recommendations — what to do now (priority checklist)​

• Inventory: Identify all hosts with MSMQ installed (use PowerShell / DISM / Server Manager). Prioritize those supporting production workloads.
• Test ring: If you have a test/staging ring, reproduce the issue there with the December updates to validate impact and mitigation steps.
• Short‑term mitigation: Prefer rollback of the December LCU in heavily impacted systems if change control and exposure tolerances allow. If rollback is impractical, apply a narrow ACL workaround as described and monitor closely.
• Monitoring and audit: Enable file and MSMQ operational auditing and set up alerts for MSMQ errors, queue activity dropouts, and unusual writes to the MSMQ folder.
• Reconcile security: Track CVE‑2025‑62455 and the associated Microsoft KB guidance; plan to re‑apply the security update once Microsoft publishes a fix or a sanctioned workaround.
• Long term: Where feasible, plan migration paths away from legacy MSMQ to modern queuing platforms (Azure Service Bus, RabbitMQ, Kafka) for new development; for legacy apps, include MSMQ compatibility in patch testing cycles.

---

Critical analysis: vendor engineering trade‑offs and operational lessons​

This regression is an instructive case in large‑scale OS engineering:

• Strengths: Microsoft’s December rollups address multiple security issues across a broad attack surface; closing privilege‑elevation and RCE vectors in MSMQ is an important hardening step given historical high‑severity bugs (for example, CVE‑2023‑21554). The company’s security posture and vulnerability upstreaming are necessary.
• Weaknesses: Changing a filesystem permission model for an on‑disk system folder that many legacy services implicitly relied on — and doing so without an immediate documented mitigation or compatibility shim — produced a real‑world operational impact. The apparent lag between community reports and an updated, clear vendor KB entry increased confusion.
• Risk: Community workarounds that grant write access under System32 are functional but increase the attack surface. Administrators who accept those mitigations must do so knowingly and add compensating controls (auditing, minimal scope, rapid reversion plan).

In short: security hardening is vital, but rolling changes that break long‑standing, legitimate behaviors require vendor clarity and enterprise‑grade mitigation guidance before broad deployment.

---

What we still don’t know — flagged uncertainties​

• Microsoft’s KB pages for the December rollups (as of initial publication) did not list MSMQ as a known KB‑level issue, while Microsoft Q&A and community channels show the vendor is aware of reports. This inconsistency should be treated as a temporary documentation gap and monitored. Administrators should not rely solely on the KB page until Microsoft publishes an explicit known‑issue note or hotfix.
• The full engineering justification for the specific ACL change (design rationale or compatibility testing outcomes) has not been publicly detailed; that leaves questions about whether the ACL modification was intentional or accidental. Treat public statements accordingly and expect a formal update from Microsoft.

---

Final verdict and operational takeaway​

The December 2025 cumulative updates fixed legitimate MSMQ security issues but also introduced a compatibility regression by changing the MSMQ storage folder’s NTFS permissions. Administrators face a difficult choice: preserve the security posture by staying patched and apply a temporary (and riskier) ACL workaround, or roll back the LCU and restore operational continuity while reaccepting the pre‑patch security exposure.
Actionable priorities for Windows administrators:

• Treat MSMQ hosts as high‑risk assets: inventory, isolate network exposure (block port 1801 where appropriate), and monitor closely.
• Prefer rollback when possible for critical outages; otherwise apply a narrowly scoped ACL workaround and protect it with auditing and a rapid expiration/reversion plan.
• Watch Microsoft’s release channels for an authoritative KB amendment or an out‑of‑band hotfix; delay broad LCU rollout to additional rings until patch compatibility is validated in staging.

This episode is a reminder that operating‑system hardening and compatibility must be balanced deliberately: security fixes are vital, but vendor tooling and guidance need to anticipate how deep, low‑level permission changes will affect legacy middleware that enterprises still depend on. Administrators should respond pragmatically — prioritize business continuity for critical systems, but document temporary mitigations and roll them back once a vendor‑approved fix is available.

---

Conclusion
The December 2025 MSMQ regression demonstrates how a small change in access semantics can cascade into broad operational impact. Until Microsoft issues a formal remediation or detailed mitigation guidance, organizations must choose between rollback and narrowly scoped ACL workarounds, each with clear trade‑offs. Inventory and quick triage will be the immediate priorities for IT teams, and longer‑term, this incident argues for more exhaustive compatibility testing around low‑level security adjustments and a renewed focus on retiring legacy middleware where feasible.

---

Source: Techzine Global Windows patch causes multiple Message Queuing errors

 

[ChatGPT]

Microsoft’s December patch wave has introduced a disruptive regression that breaks Microsoft Message Queuing (MSMQ) on a range of Windows builds, causing queues to go inactive and IIS‑hosted applications to fail when they attempt to write messages—an issue traced to tightened NTFS permissions on the MSMQ storage folder that Microsoft has acknowledged and is investigating.

Background​

MSMQ (Microsoft Message Queuing) is a long‑standing Windows subsystem that provides durable, on‑disk message persistence and asynchronous delivery for applications ranging from legacy IIS web apps to enterprise integration middleware. Because MSMQ persists messages as files under the system path, its correct operation depends on precise NTFS permissions and the ability for service identities (IIS app pools, LocalService/NetworkService, or named service accounts) to create and append message files. The December 9, 2025 cumulative updates (for example, KB5071546 for Windows 10 build 19045.6691 and matching server LCUs) included a security hardening change to MSMQ that modified the component’s filesystem security semantics; Microsoft’s KB entry now lists Message Queuing as a known issue after installation. This article summarizes the public facts, verifies technical claims against vendor and independent sources, analyzes the risks and trade‑offs, and delivers a practical runbook for administrators who must triage or remediate affected MSMQ infrastructure. Assertions in community reports and industry articles are cross‑checked where possible; where claims remain anecdotal they are explicitly flagged.

---

What Microsoft has confirmed (verified)​

• The December 9, 2025 cumulative updates include changes that can affect MSMQ functionality; Microsoft added a known‑issue note to the update KBs describing MSMQ symptoms.
• The observable root cause listed by Microsoft is a change to the MSMQ security model that alters NTFS permissions on C:\Windows\System32\MSMQ\storage, requiring non‑administrator MSMQ users to have explicit write access in scenarios where they previously did not.
• Affected SKUs and builds documented in Microsoft’s update pages include Windows 10 (22H2/21H2 ESU builds) and server branches represented by the December LCUs for Windows Server 2016 and 2019; Microsoft’s KBs for those December packages were updated to add the MSMQ known issue.

These vendor confirmations are corroborated by Microsoft’s own Q&A and community threads where administrators report identical symptoms and, in many cases, restoration of functionality after rolling back the December LCU or adjusting folder ACLs.

---

Timeline — how the problem surfaced​

• December 9, 2025: Microsoft released the December cumulative updates (LCUs / SSUs) that package fixes including an MSMQ hardening change; KB entries were published for each affected SKU.
• Within days (December 10–12): Administrators began reporting IIS applications returning System.Messaging.MessageQueueException errors — typically surfaced as “Insufficient resources to perform operation” — and MSMQ queues going inactive. Community triage linked the failures to the MSMQ storage path and to a changed NTFS security descriptor.
• Microsoft updated relevant KB pages to list MSMQ as a known issue and stated the matter is under investigation; no single Microsoft‑issued hotfix or prescriptive workaround was initially published beyond the advisory.

---

Technical root cause (what changed and why it matters)​

At the heart of the outage is a change in the MSMQ security model that altered the NTFS discretionary access control list (DACL) and security descriptor on the MSMQ storage folder (C:\Windows\System32\MSMQ\storage). Historically, MSMQ relied on a combination of system privileges and an ACL structure that allowed the service and certain lower‑privileged service identities to create and write the .mq message files into storage. The December updates appear to have added or changed inheritance flags in the folder’s security descriptor (for example, an Auto‑Inherited flag in the SDDL), resulting in the effective loss of write permissions for non‑admin identities that previously functioned without explicit ACL entries. When MSMQ attempts to create or append storage files and is denied at the filesystem level, the subsystem surfaces opaque resource allocation errors; hence the misleading “insufficient disk space or memory” or “insufficient resources” exceptions despite healthy system resources. Microsoft’s KB explicitly points to the NTFS permission change on the storage folder as the cause. Independent vulnerability trackers and security databases map the MSMQ fixes in December’s LCUs to CVE‑2025‑62455 (an MSMQ elevation of privilege / improper input validation issue), confirming the security intent behind updating MSMQ but not absolving the compatibility fallout.

---

Symptoms and real‑world impact​

Administrators and application owners have reported a consistent pattern of failures after installing the December updates:

• MSMQ queues suddenly appear inactive and refuse to accept messages.
• IIS‑hosted web apps that send messages to MSMQ throw System.Messaging.MessageQueueException errors, commonly logged as “Insufficient resources to perform operation.”
• Event logs show failed attempts to create message files (for example: The message file 'C:\Windows\System32\msmq\storage.mq' cannot be created*).
• Diagnostic logs may misleadingly report “There is insufficient disk space or memory”, confusing triage.
• The problem is observable on single servers and amplified in clustered MSMQ deployments under load; cluster nodes losing write access simultaneously can lead to distributed state inconsistencies.

Real outages tied to these symptoms have been reported by practitioners on community channels and in support threads; many organizations that still run MSMQ for legacy or integration scenarios (financial processing, healthcare middleware, logistics adapters) have experienced service interruptions where message processing halted until corrective action was taken. These sector‑specific impact claims are documented in community reporting but are anecdotal and not quantified by Microsoft’s advisories—treat such industry impact claims as reported incidents rather than vendor‑attested scope.

---

Platforms and scope (verified)​

Multiple Microsoft KBs and vendor advisories indicate the known issue affects the December 2025 LCUs for multiple Windows releases. Verified affected platforms include:

• Windows 10, version 22H2 (ESU builds; KB5071546).
• Windows Server 2019 (December LCU; KB5071544 / package variants).
• Windows Server 2016 (December LCU; KB5071543 / package variants).

At the time of vendor advisories and the initial community wave, there were far fewer confirmed reports for Server 2022; site‑level reporting indicates the regression primarily surfaced on older server branches and Windows 10 ESU SKUs. Cross‑validation using Rapid7 and other vulnerability trackers confirms CVE mapping and product lists that include Server 2016/2019 and Windows 10 SKUs.

---

Immediate mitigations administrators are using (pros and cons)​

Two practical containment options have emerged in the field; each carries trade‑offs that must be weighed against business continuity and security posture.

• Option A — Roll back the December LCU (preferred when feasible for security‑conscious environments facing severe outages):
• Steps: identify the installed package via DISM or wusa, uninstall the package (example: DISM /Online /Get-Packages then DISM /Online /Remove‑Package /PackageName:<package>), reboot, validate MSMQ writes and IIS behavior.
• Pros: Restores pre‑patch behavior and service continuity.
• Cons: Reintroduces the security fixes that the LCU intended to deliver; removal can be complicated when updates were installed as combined SSU+LCU bundles and may require careful servicing stack handling. Microsoft’s removal guidance must be followed.
• Option B — Apply a narrowly scoped NTFS ACL workaround to restore MSMQ write access to the storage folder:
• Steps used in practice include granting Modify (or the minimum required) to the specific service identity that writes to MSMQ, for example using icacls:
• icacls "C:\Windows\System32\MSMQ\storage" /grant "NT AUTHORITY\NETWORK SERVICEOI)(CI)(M)" /T (replace identity with the precise account in your environment).
• Pros: Restores MSMQ without uninstalling security updates; can be targeted and reversible.
• Cons: Granting write/modify to a System32 subfolder increases attack surface; if broadly applied or left permanent, it can allow a lower‑privileged compromise to escalate or persist. Any ACL workaround must be logged, auditable, and scheduled for rollback after a vendor fix.

Community threads and Microsoft Q&A posts show admins using both approaches; some large environments chose to roll back the LCU for critical hosts while applying targeted ACLs to carefully audited non‑production rings for short‑term throughput needs.

---

How to triage an affected host — practical checklist​

• Confirm MSMQ presence: Get‑WindowsOptionalFeature -Online | Where‑Object { $_.FeatureName -like "MSMQ*" } or Get‑WindowsFeature on servers.
• Check installed updates: Settings → Update history, wusa /query, or DISM /Online /Get-Packages to find the December LCU package.
• Reproduce safely in a lab: Before changing production ACLs, reproduce the behavior on a test host by applying the LCU and verifying whether a non‑privileged identity can create files in C:\Windows\System32\MSMQ\storage.
• Inspect event logs: Look for System.Messaging exceptions, errors that reference creation failures for *.mq files, and misleading “insufficient disk space or memory” messages.
• If immediate restoration is required and rollback is feasible: follow Microsoft’s documented remove package guidance for the specific LCU, reboot, and validate.
• If rollback is not possible: apply a minimal, explicitly scoped ACL to the storage folder for the precise identity that needs write access, enable file‑access auditing (auditpol /subcategory:"File System" /success:enable /failure:enable and add a SACL entry), and schedule an immediate vendor fix once available.

---

Security trade‑offs and risk analysis​

This incident highlights the perennial trade‑off between OS hardening and compatibility with legacy middleware:

• The December updates addressed real security flaws in MSMQ (CVE‑2025‑62455 and related items are listed in vendor and third‑party trackers), so applying fixes is important to reduce local elevation and other exploit risks.
• Conversely, altering filesystem ACL semantics without a documented compatibility shim or a clear, supported mitigation path caused operational breakage for legitimate application identities that depended on prior behavior. This produced immediate availability risk for critical systems.

If teams adopt the community ACL workaround, they must mitigate the introduced security risk by:

• Making the ACL change as narrow as possible (restrict to the exact service principal).
• Enabling file‑system auditing to detect unexpected writes or tampering.
• Treating the ACL change as an emergency, time‑limited exception and reverting it promptly after the vendor hotfix.

Rolling back the update restores availability but reintroduces the pre‑patch security posture; that trade‑off must be documented and accepted by risk owners.

---

Vendor response and what to watch for​

Microsoft has acknowledged the regression in the relevant December KB documentation and listed MSMQ as a known issue while the engineering teams investigate; the KB pages are the authoritative source for official guidance and hotfixes. Administrators should monitor those KB entries and Microsoft’s Security Update Guide for out‑of‑band fixes or updated guidance before broadly reapplying the December LCUs in production rings. Key signals to watch for from Microsoft:

• A published hotfix / out‑of‑band patch that corrects the permission model while preserving the security hardening intent.
• An official workaround documented by Microsoft that offers a minimal and auditable ACL change or another compatibility shim.
• KB removal guidance clarifications for environments where SSUs and LCUs were combined.

Until Microsoft issues such guidance, community remedies and rollbacks remain the primary field responses, so track vendor channels closely and avoid blanket, permanent ACL changes.

---

Long‑term considerations — migrate or mitigate?​

This episode underscores the maintenance burden of legacy OS‑level middleware:

• Inventory: Maintain a current inventory of hosts and applications that rely on MSMQ and map business criticality and SLA impact.
• Modernization: Where feasible, evaluate migration paths to managed or modern messaging platforms (Azure Service Bus, RabbitMQ, Kafka). Those platforms decouple message durability from host filesystem semantics and reduce risk exposure to OS patching changes—though migrations bring cost and integration complexity.
• Patch testing: Expand staging and compatibility testing for cumulative updates to include MSMQ‑dependent applications and IIS workloads. Create a small, representative pilot ring to detect regressions before broad rollout.

---

Recommended action plan (prioritized list)​

• Inventory: Identify all systems with MSMQ installed and classify them by business impact.
• Pause broad deployment: Halt deployment of the December LCUs to new rings until compatibility is validated in staging.
• Triage affected production hosts: If experiencing outages, decide between rollback (preferred for security teams if acceptable) or applying a narrow ACL workaround under strict auditing.
• Document and control: Any ACL workaround must be change‑controlled, logged, and scheduled for reversal. Enable file auditing for the storage folder while the exception is in place.
• Monitor vendor channels: Watch Microsoft KB pages and the Security Update Guide for an official mitigation or hotfix. Prioritize applying Microsoft’s resolution once available.
• Plan migration (medium term): Begin a program to reduce reliance on MSMQ for new integrations and consider long‑term modernization for legacy consumers.

---

Critical assessment — strengths, shortcomings, and implications​

Strengths:

• Microsoft patched a genuine MSMQ vulnerability (CVE‑2025‑62455) as part of December’s security work, reducing an elevation risk that attackers could exploit in post‑compromise scenarios. Third‑party trackers and security databases corroborate the CVE mapping.

Shortcomings:

• The change to the NTFS ACL model produced a compatibility regression impacting operational availability. Ideally, such a low‑level permission change should include an explicit compatibility path: either an opt‑in hardening, a documented local workaround, or an automated compatibility shim to preserve functionality for common service identities. The KB pages were updated only after community reports surfaced, which extended triage time for affected administrators.

Implications:

• Enterprises with MSMQ in production now face difficult operational choices: accept security exposure by rolling back, or accept increased attack surface by relaxing filesystem permissions temporarily. Both options require careful documentation, compensating controls, and rapid reversal once Microsoft provides a vendor‑sanctioned fix.

---

Final verdict and takeaway​

The December 2025 Windows cumulative updates fixed an important MSMQ vulnerability but inadvertently tightened NTFS permissions in a way that broke existing MSMQ‑dependent applications and IIS sites. Microsoft has acknowledged the problem and is investigating; the vendor KBs are the authoritative place for updated guidance and eventual hotfixes. Administrators must act pragmatically: inventory MSMQ usage, triage affected hosts using the prioritized checklist above, and choose between rollback and a tightly constrained ACL workaround based on business impact and risk tolerance. Any temporary ACL change must be auditable, time‑boxed, and reversed once Microsoft publishes the corrective update. This incident is a timely reminder that OS hardening and compatibility testing need to be balanced—especially for legacy subsystems that persist across heterogeneous enterprise estates. Short‑term agility and long‑term modernization plans are both required to reduce the chance that a single cumulative update will ripple into service outages for mission‑critical systems.

---

Conclusion
For now, treat hosts with MSMQ as high‑priority assets: inventory them, monitor queue metrics and IIS error logs for System.Messaging exceptions, and defer wider deployments of the December LCUs until the updates have been validated in a staging ring or Microsoft releases an authoritative remediation. Where outages are occurring, follow the measured runbook—prioritize rollback where security risk remains manageable, otherwise apply a narrowly scoped, auditable ACL change and prepare to revert it when a vendor fix is available. The balance between security hardening and operational continuity will determine how teams respond to this regression; tight change control, quick verification, and close vendor monitoring are the practical essentials for the hours and days ahead.

---

Source: Cyber Press https://cyberpress.org/microsoft-msmq-on-iis-servers/