De update moest de deur dichtdoen

Microsofts Patch Tuesday van september 2026 bevatte een fix voor CVE-2026-69525, een lek in Extern-bureaubladservices met een CVSS-score van 9.8 op 10, het soort score dat gereserveerd is voor fouten die een vreemde op internet zonder wachtwoord kan misbruiken. Een speciaal geprepareerd pakket naar poort 3389 kon een use-after-free-fout veroorzaken en code uitvoeren met de rechten van de dienst, zonder in te loggen.

Beheerders die de update op schema installeerden, de verantwoorde keuze volgens elke normale maatstaf, deden precies wat beveiligingsteams elke maand vragen.

Toen begon Extern bureaublad zelf uit te vallen

Binnen enkele uren na installatie van KB5122876 op Server 2019, KB5122882 op Server 2022 of KB5122871 op Server 2025 begonnen de Extern-bureaubladservices te falen. Verbindingen die bij het opstarten werkten, werkten enkele uren later niet meer. Bestaande sessies konden niet netjes afmelden. Nieuwe verbindingspogingen bleven hangen en liepen uiteindelijk vast op een timeout, en in het ergste geval hielp alleen een harde herstart van de server.

Een beheerder omschreef het patroon simpel: het werkt eerst, maar na de eerste afmelding crasht de dienst en kan geen enkele gebruiker meer inloggen. Een onderzoeker die de fout naspeurde wees op een deadlock tussen het Extern-bureaubladproces en de Local Session Manager, een diagnose die Microsoft niet heeft bevestigd.

Wat brak er, en waar

Windows Server-versieUpdateSymptoom
Server 2019KB5122876RDS faalt uren na het opstarten
Server 2022KB5122882Sessies hangen bij afmelden
Server 2025KB5122871Nieuwe verbindingen lopen vast op een timeout

Microsoft heeft alleen bevestigd op de hoogte te zijn van de meldingen en te onderzoeken. De oorzaak is niet bevestigd, en er is geen hersteldatum genoemd.

Waarom het ertoe doet

Waarom het ertoe doet: Dit is geen abstract debat over patchbeheer, het is een acute keuze voor elk team dat Windows Server draait met Extern bureaublad open naar buiten, en in Europese en Britse organisaties met thuiswerkers, externe partners of filialen is dat de meerderheid. Terugdraaien opent op dezelfde servers opnieuw een lek van ernst 9.8 dat zonder inloggegevens te misbruiken is. De update laten staan kan ervoor zorgen dat externe toegang zelf, de reden dat die servers bestaan, zonder waarschuwing stopt met werken.

Ja, maar

Ja, maar: Geen van beide opties is eigenlijk de enige uitweg. Beheerders die zich geen volledige terugdraai en geen kapotte externe toegang kunnen veroorloven, beperken in plaats daarvan de RDP-blootstelling op netwerkniveau, door poort 3389 te beperken tot een VPN of een jump host in plaats van het open internet, waardoor de patch geinstalleerd blijft, de makkelijkste weg naar het verholpen lek wordt afgesloten, en er tijd wint voor een officiele oplossing zonder op een van beide faalscenario's te gokken.

De kern

De kern: "Alles meteen patchen" en "een week wachten voor de zekerheid" zijn hier allebei het verkeerde instinct, want de echte beslissing gaat niet over snelheid, maar over blootstelling. Test elke cumulatieve update op een kleine kanariegroep voordat die elke server bereikt, en beperk netwerktoegang tot alles wat de update zou kunnen raken, zodat een slechte patch een handvol machines treft in plaats van elke Extern-bureaubladsessie in het bedrijf tegelijk.