Uppdateringen skulle stänga dörren
Microsofts Patch Tuesday i september 2026 innehöll en fix för CVE-2026-69525, en brist i Fjärrskrivbordstjänster med en CVSS-poäng på 9.8 av 10, den typ av poäng som är förbehållen buggar en främmande på internet kan utnyttja utan lösenord. Ett speciellt konstruerat paket skickat till port 3389 kunde utlösa ett use-after-free-fel och köra kod med tjänstens rättigheter, helt utan inloggning.
Administratörer som installerade uppdateringen enligt schemat, det ansvarsfulla valet enligt varje normal måttstock, gjorde precis det säkerhetsteam ber om varje månad.
Sedan började Fjärrskrivbord krascha av sig självt
Några timmar efter installation av KB5122876 på Server 2019, KB5122882 på Server 2022 eller KB5122871 på Server 2025 började Fjärrskrivbordstjänsterna fallera. Anslutningar som fungerade vid start slutade fungera några timmar senare. Befintliga sessioner kunde inte logga ut rent. Nya anslutningsförsök hängde sig och gick till slut i timeout, och i de värsta fallen var den enda lösningen en hård omstart av servern.
En administratör beskrev mönstret rakt av: det fungerar först, men efter den första utloggningen kraschar tjänsten och ingen ytterligare användare kan logga in. En forskare som spårade felet pekade på en deadlock mellan Fjärrskrivbord-processen och Local Session Manager, en diagnos Microsoft inte har bekräftat.
Vad som gick sönder, och var
| Windows Server-version | Uppdatering | Symtom |
|---|---|---|
| Server 2019 | KB5122876 | RDS fallerar timmar efter start |
| Server 2022 | KB5122882 | Sessioner hänger sig vid utloggning |
| Server 2025 | KB5122871 | Nya anslutningar går i timeout |
Microsoft har bara bekräftat att man känner till rapporterna och utreder saken. Grundorsaken är inte bekräftad, och inget datum för en fix har nämnts.
Varför det spelar roll
Varför det spelar roll: Det här är ingen abstrakt debatt om patchhantering, det är ett verkligt val för varje team som kör Windows Server med Fjärrskrivbord öppet utåt, och i europeiska och brittiska verksamheter med distansarbetande personal, externa leverantörer eller filialer gäller det de flesta. Att rulla tillbaka öppnar på nytt en brist med allvarlighetsgrad 9.8 på samma servrar, en brist som går att utnyttja utan inloggningsuppgifter. Att låta uppdateringen ligga kvar kan få själva fjärråtkomsten, anledningen till att de servrarna finns, att sluta fungera utan förvarning.
Ja, men
Ja, men: Inget av de två alternativen är egentligen den enda utvägen. Administratörer som varken kan riskera en fullständig återställning eller trasig fjärråtkomst begränsar istället RDP-exponeringen på nätverksnivå, genom att begränsa port 3389 till ett VPN eller en jump host istället för öppna internet, vilket håller patchen installerad, stänger den enklaste vägen till den åtgärdade sårbarheten, och köper tid till en officiell fix utan att satsa på något av de två felscenarierna.
Sammanfattningsvis
Sammanfattningsvis: "Patcha allt direkt" och "vänta en vecka för säkerhets skull" är båda fel instinkt här, för det egentliga beslutet handlar inte om hastighet, utan om exponering. Testa varje kumulativ uppdatering på en liten kanariegrupp innan den når alla servrar, och begränsa nätverksåtkomst till allt uppdateringen skulle kunna påverka, så att en dålig patch slår ut en handfull maskiner istället för varenda Fjärrskrivbordssession i företaget på en gång.
Läs vidare: Apples vd-chock från 2011 kostade 12 gånger mer än 2026 års | Xboxs helomvändning gällde marknadsföringen, inte spelen
