Die im Rahmen des Patch Tuesday veröffentlichten Windows-Sicherheitsupdates vom Dezember 2025 führen in zahlreichen Unternehmensumgebungen zu gravierenden Störungen bei Microsoft Message Queuing (MSMQ). In der Folge fallen Webanwendungen auf IIS aus, Nachrichtenwarteschlangen bleiben stehen und geschäftskritische Prozesse verarbeiten Daten nur noch verzögert oder gar nicht mehr.
MSMQ-Probleme nach Windows-Sicherheitsupdate: betroffene Versionen und Symptome
Nach aktuellen Informationen betreffen die Störungen Systeme mit Windows 10 22H2, Windows Server 2019 und Windows Server 2016, auf denen die Sicherheitsupdates KB5071546, KB5071544 und KB5071543 installiert wurden. MSMQ ist als optionaler Windows-Komponent weit verbreitet und wird in vielen Unternehmen als zuverlässige Messaging-Schicht zwischen Anwendungen eingesetzt.
Administratoren berichten nach der Installation der Dezember-Patches über ein charakteristisches Fehlerbild:
– MSMQ-Warteschlangen bleiben inaktiv oder sind nicht erreichbar;
– IIS-Websites und Webservices brechen mit Meldungen wie „Nicht genügend Ressourcen“ ab;
– Anwendungen können keine Nachrichten mehr in die Queues schreiben;
– Eventlogs melden angeblichen Mangel an RAM oder Speicherplatz, obwohl ausreichend Ressourcen verfügbar sind.
Technische Ursache: geänderte Sicherheits- und Zugriffsrechte für MSMQ
Microsoft führt die Störungen auf Anpassungen der Sicherheitsarchitektur von MSMQ zurück, insbesondere auf neu bewertete NTFS-Berechtigungen der Verzeichnisse, in denen MSMQ seine Daten ablegt. Im Fokus steht der Ordner C:\Windows\System32\MSMQ\storage, der die persistente Speicherung der Nachrichtenwarteschlangen übernimmt.
Mit den Dezember-Updates benötigen Konten, unter denen die MSMQ-Dienste laufen, nun explizit Schreibrechte auf dieses Verzeichnis. In vielen Umgebungen war der Zugriff zuvor primär Administratoren vorbehalten. Fehlen diese Rechte, schlagen Schreiboperationen über die MSMQ-API fehl und werden von den aufsetzenden Anwendungen fälschlich als Ressourcenengpass interpretiert.
Besonders deutlich zeigt sich das Problem in MSMQ-Clusterumgebungen unter hoher Last. Hier führen zahlreiche gleichzeitige Schreibversuche zu einer Kaskade von Fehlermeldungen, die sich auf mehrere Clusterknoten ausweiten und im schlimmsten Fall ganze Service-Landschaften beeinträchtigen.
Auswirkungen auf Business Continuity und Cybersicherheit
MSMQ fungiert in vielen Architekturen als Rückgrat für Zahlungssysteme, Auftragswarteschlangen, Microservices-Kommunikation und Integrationsszenarien zwischen Altsystemen und modernen Anwendungen. Ein Ausfall oder eine starke Verzögerung der Warteschlangen kann direkte Folgen haben: verspätete Transaktionsverarbeitung, nicht angenommene Kundenaufträge, verfehlte SLA-Vorgaben und kostenintensive Serviceunterbrechungen.
Für Sicherheits- und IT-Verantwortliche entsteht zudem ein klassisches Dilemma: Die fehlerhaften Sicherheitsupdates installiert lassen und Ausfälle in Kauf nehmen oder die Patches zurückrollen und damit die Angriffsfläche wieder erhöhen. Branchenberichte wie der Verizon Data Breach Investigations Report zeigen seit Jahren, dass die Ausnutzung bekannter, ungepatchter Schwachstellen zu den häufigsten Initialvektoren erfolgreicher Angriffe gehört. Ein pauschaler Patch-Rollback ist daher sicherheitlich hochriskant.
Patch-Management: Balance zwischen Verfügbarkeit und Risiko
In professionellen Umgebungen mit MSMQ sollte der Umgang mit den Dezember-Updates strukturiert erfolgen. Sinnvolle Schritte umfassen unter anderem:
– Inventarisierung: Zügig identifizieren, auf welchen Systemen MSMQ aktiviert ist und die Updates KB5071546/KB5071544/KB5071543 installiert wurden;
– Business-Impact-Bewertung: Kritikalität der betroffenen Dienste und potenzielle Schäden durch Ausfälle oder Verzögerungen ermitteln;
– Technische Analyse: System- und MSMQ-Logs sowie IIS-Events auswerten, um den Zusammenhang mit den geänderten Zugriffsrechten verlässlich zu bestätigen;
– Getestete Änderungen: Anpassungen an Berechtigungen (z. B. NTFS-ACLs des storage-Ordners) oder ein möglicher Patch-Rollback ausschließlich in Test- oder Staging-Umgebungen erproben, bevor produktive Systeme angepasst werden.
Empfohlene Sofortmaßnahmen für Windows- und MSMQ-Administratoren
Microsoft hat das Problem bestätigt und arbeitet an einer Korrektur, ohne jedoch zum jetzigen Zeitpunkt einen konkreten Veröffentlichungstermin zu benennen. Bis ein offizieller Fix verfügbar ist, sollten Administratoren einen risikobewussten Zwischenweg wählen.
Empfehlenswert sind insbesondere folgende Maßnahmen:
– Laufende Beobachtung offizieller Quellen: Bekanntgegebene Known Issues und die Dokumentation der betreffenden KB-Updates sowie von MSMQ regelmäßig prüfen;
– Vermeidung flächendeckender Rollbacks: Falls ein Rückbau der Patches in einzelnen, besonders betroffenen Umgebungen unumgänglich ist, sollten kompensierende Kontrollen wie Netzwerksegmentierung, restriktive Firewall-Regeln und engmaschiges Security-Monitoring verstärkt werden;
– Sorgfältige Dokumentation: Alle temporären Workarounds – etwa angepasste NTFS-Berechtigungen – detailliert festhalten, um nach Bereitstellung eines offiziellen Patches sauber zur Standardkonfiguration zurückkehren zu können;
– Pilotierung neuer Updates: Kritische Komponenten wie MSMQ, IIS und Cluster-Dienste grundsätzlich über Pilotgruppen und Testsysteme aktualisieren, bevor sie breit im Rechenzentrum oder in der Cloud ausgerollt werden.
Die aktuellen MSMQ-Störungen im Zuge der Windows-Sicherheitsupdates vom Dezember 2025 verdeutlichen, wie eng Vulnerability Management und Business Continuity miteinander verknüpft sind. Organisationen, die strukturierte Patch-Prozesse, Testumgebungen, klar definierte Rollback-Szenarien und eine enge Zusammenarbeit von Betrieb und Security etabliert haben, können auf solche Vorfälle deutlich resilienter reagieren. Es lohnt sich, diese Prozesse jetzt kritisch zu überprüfen und zu stärken, um beim nächsten „Patch Tuesday“ Sicherheitsgewinne zu realisieren, ohne geschäftskritische Services unbeabsichtigt zu gefährden.
