Microsoft-beveiligingsupdates van december veroorzaken storing op Windows Server

De in december uitgekomen beveiligingsupdates voor Windows verstoren de functionaliteit van message queueing (MSMQ) op de 2016- en 2019-versies van Windows Server. Ook Windows 10 is geraakt. Door deze storing werken zakelijke applicaties en Microsofts webserver IIS niet goed.

Microsoft bevestigt de problemen veroorzaakt door de beveiligingsupdates van december, meldt Bleeping Computer. Het gaat om de updates KB5071546, KB5071544 en KB5071543 die Microsoft uitbracht op de Patch Tuesday van deze maand. Op getroffen computers kunnen diverse symptomen optreden. Deze lopen uiteen van inactieve MSMQ-queues tot IIS-websites die onderuit gaan met foutmeldingen van 'onvoldoende resources'.

Ook kunnen zakelijke applicaties problemen ondervinden doordat ze geen data kunnen wegschrijven naar queues. Verder kunnen sommige systemen ten onrechte meldingen geven dat er onvoldoende opslagruimte of geheugencapaciteit beschikbaar is. MSMQ is een een op Windows draaiende dienst die communicatie verzorgt tussen applicaties op het besturingssysteem.

De oorzaak van deze storing op Windows ligt in veranderingen die Microsoft aanbrengt in het securitymodel voor de MSMQ-service. Daardoor gelden er nu aangescherpte permissies voor het schrijven van data in kritieke systeemmappen. Systeembeheerders hebben die rechten normaliter wel, maar dat geldt niet voor MSMQ-gebruikers die met minder rechten zijn ingelogd op Windows-systemen.

Door Jasper Bakker

Nieuwsredacteur

15-12-2025 • 17:29

33

Submitter: theRageXIII

Reacties (33)

Sorteer op:

Weergave:

Er heeft toch geen A.I. aan de code gezeten?
Heb je het artikel wel helemaal gelezen of wilde je gewoon "grappig" zijn?

Het betreft een aangescherpt beveiligingsmodel, waarbij de gevolgen eerder (goed) gecommuniceerd hadden moeten worden.
Mja, toch een beetje een dingetje van Microsoft - eerst iets loslaten in het wild en als er problemen zijn met een verklaring komen. Als je van tevoren al weet dat een mogelijke wijziging 'disruptive' kan zijn, dan moet je dat op zijn minst een paar weken van tevoren aankondigen. Of dat je dit soort updates 'on-demand' kan installeren.
De verklaring is gewoon steekhoudend en komen met "er heeft toch geen AI aangezeten" slaat hierin nergens op.

Als het dikke problemen bevat door bugs die niet verklaarbaar zijn, dan zou de opmerking beter op z'n plaats zijn.
Maar als je dat weken van tevoren aankondigde laat je aanvallers weten hoe dit te exploiten voor weken is dat wat je wilt.
En precies nu vraagt een grote klant deze door te voeren, ondanks ons advies even te wachten, ik ga deze link onmiddellijk doorsturen!

Dank Tweakers _/-\o_
MSMQ is een optioneel component dat standaard niet geïnstalleerd is. Ik heb bij een klant van me 1 server waar het wel aangezet is (zonder aanwijsbare reden), de rest heeft geen MSMQ.
Waarschijnlijk is MSMQ het meest obscure en minst gebruikte Windows component. Ik heb me vaak afgevraagd waarom Microsoft het uberhaupt ontwikkeld heeft want het heeft in mijn ogen niks in een OS te zoeken.
Het is een hele praktische API die niet aangeslagen is. Dingen als ActiveMQ/Artemis zijn aardig populair voor cloudoplossingen, al lijkt men in de cloud eerder naar iets als SES te bewegen dezer dagen.

De API is erg oud en nooit populair geworden maar voor het besturen van dingen als automatisering en het verwerken van batchtaken lijkt dit me een uitstekende oplossing.

Windows biedt wel meer API's aan waar je op andere besturingssystemen zelf wat aan elkaar moet duct-tapen en eerlijk gezegd vind ik de Windows-aanpak hier een stuk beter. Ik kan me geen andere message queue uit 1997 bedenken die dezelfde API aan heeft gehouden en nog beveiligingsupdates krijgt.
JMS 1.1 komt uit 2002 en wordt nog steeds ondersteunt door moderne message brokers. De hele gedachte achter een message broker is eigenlijk zoals service calls nu zijn maar dan asynchroon. Ieder schaalbaar platform heeft wel een vorm van message queueing in zich. De hele opzet komt zo rechtstreeks uit mainframe land gewaaid
In het verleden werd dit vaak gebruikt icm MS Biztalk Servers (ESB) waarbij de Biztalk Soap/REST API's, berichten op Windows MSMQ plaatste om zo de BizTalk messagebox te ontlasten. Hierdoor had je een buffer tussen de API's en BizTalk engine. Hierdoor kon je bv onderhoud doen op biztalk terwijl aangesloten systemen nog steeds berichten kon aanbieden.
Microsoft's vorm van RabbitMQ e.d.
Tegenwoordig heeft Microsoft daarvoor Azure Service Bus.

Dat het niets met een OS te maken heeft ben ik het wel mee eens.
Al is het wel supereenvoudig en vrij vlot en met een vinkje aan te zetten.
Tsja, mee eens. Laatste versie komt volgens Wikipedia uit 2012 tijdperk. Terug denkend zat ik toen volgens mij in een team dat activemq gebruikte, maar als je volop in het Microsoft ecosysteem zat dan was dit vast toen ook een mooie oplossing. En dan zijn we nu 15 jaar verder, maar je weet ook dat in grote organisaties genoeg van die legacy systemen rondzwerven.
Klopt!

Bij deze klant staat dit op productie dus wel op verschillende servers, en wilde dat we de updates voor en op kerst uitrolde.... Neen dus, want onze 24/7 gaat problemen tegenkomen :) vandaar mijn dank aan Tweakers :)
Als je op Tweakers wacht ben je vaak te laat. Er zijn betere professionelere ICT media, die sneller info delen en ook vaker meer info delen. Bleeping is mijn favoriet. Ook kun je je inschrijven voor Microsoft mailing, betreffende de info op het even welke technologie. Maar je kan Tweakers door geven als bron. Is lekker leesbaar voor iedereen, ook voor niet informatici.
Maar de fix lijkt zelf goed de permissies te hebben staan en niet zomaar wat te doen..

Dus zo moeilijk is het nu ook weer niet
en nu leest de klant je comment.
Gaat er daar ook eens wel wat goed met de maandelijkse updates? Ik zie nu wel héél regelmatig problematiek met Windows updates hier voorbij komen…
Als ze nu gewoon even recall op al hun AI code genereer modellen installeren kunnen ze andere AI laten zoeken naar de fouten om zo hun model te verbeteren.

Die 30% moet gewoon beter kunnen. ( /s voor de zekerheid, ge wit ooit nooit )
Is dit wel een bug of probleem.

Klinkt mij meer als lui appdev die onder te veel permissies iets doet wat exoitable is en ms nu dicht heeft gezet.
Ik als eindgebruiker heb hier last van bij ons ERP/CRM pakket sinds laatste MS server update vorige week. Vandaag issue kunnen achterhalen in de MSMQ functionaliteit, en toen werd al snel duidelijk dat dit een issue in MS update was.


Erg vervelend, want heb ook nog geen echt werkende functionele workaround (buiten opties als patch terugdraaien of beveiligingsrechten van queue folder aanpassen).

[Reactie gewijzigd door stenkate op 15 december 2025 19:01]

Het onderliggende probleem lijkt een elevation of privileges-bug te zijn: https://www.rapid7.com/db/vulnerabilities/microsoft-windows-cve-2025-62455/

Ik vermoed dat de permissies aanpassen de enige oplossing zal zijn als ze een permissiefout hebben gepatcht. Zoiets zag je ook bij hun print spooler patch, veel van de oude systemen binnen Windows kunnen niet veilig werken met niet-administrator-gebruikers en daarom worden oplossingen voor beveiligingslekken snel een backwards compatibility-risico.
Ik zie dat MS officieel een workaround heeft gepubliceerd, waar je contact met ze voor moet opnemen:
Microsoft Support: A workaround is available for affected devices. To apply the workaround and mitigate this issue in your organization, please contact Microsoft Support for business.
Mijn aanname is dat het in de richting is van wat jij aangeeft mbt permissies aanpassen.

[Reactie gewijzigd door stenkate op 17 december 2025 16:15]

Microsoft heeft nu officieel een fix:
Resolution: This issue was resolved by the Windows out-of-band update, released December 18, 2025 (KB5074975), which is available via the Microsoft Update Catalog, and updates released after that date. We recommend you install the latest update for your device as it contains important improvements and issue resolutions, including this one.
Toch blij dat ik Windows updates altijd even een weekje laat pruttelen voordat ik ze installeer.
Toch blij dat ik Windows updates altijd even een weekje laat pruttelen voordat ik ze installeer.
Voor consumenten updates is het wat minder belangrijk. Maar server updates zijn vaak ook belangrijke security patches die gedicht worden. Ik vind het echt ronduit belachelijk en slordig van Microsoft hoe vaak ze fouten maken in hun patches. Je gooit hier hele enterprise omgevingen mee plat, dat is echt niet zomaar iets. En je kan nooit 100% alles uitsluiten, maar het lijkt nu bijna elke maand wel raak te zijn met hun patches.
Er wordt inderdaad wel een lokaal te exploiteren issue gefixt in deze update.
Als dat een groot risico is voor je situatie is zit je wel een beetje met een probleem nu.
Wij gebruiken MSMQ op Server2019 voor Siemens Scada applicaties. Nu draait dit niet naar de buitenwereld en installeren we de updates meestal niet op de dag van uitkomst en wachten we op Siemens support. Gelukkig draaien we in Proxmox en maken we voor die tijd even een backup en een snapshot.
Wordt dat nog gebruikt?
Goed topic dit, gaat ons veel ellende besparen.

Draai dit commando op al je servers:

Get-WindowsFeature MSMQ* | Where-Object {$_.Installed -eq $true}

en je ziet waar MSMQ geinstalleerd is. Is het Windows 10. 2016 of 2019 heb je mogelijk een probleem.
Ja komen we nu ook net achter. Net de update terug gedraaid...
Vraag is eerder aangezien het om app permissies gaat zaan de permissies waaronder de appdev het geïmplementeerd heeft wel correct wat dat blijk als een exploit te gebruiken.
Ik kan niet echt zuivere chocola maken van wat je probeert te zeggen.

Maar als ik in de goede richting denk: je mag toch hopen dat een dev ook een testaccount heeft om te testen of het als standaard gebruiker naar behoren werkt?

Om te kunnen reageren moet je ingelogd zijn