Opdateringen skulle lukke døren
Microsofts Patch Tuesday i september 2026 indeholdt en rettelse til CVE-2026-69525, en fejl i Fjernskrivebordstjenester med en CVSS-score på 9.8 ud af 10, den slags score der er forbeholdt fejl, en fremmed på internettet kan udnytte uden adgangskode. En specialbygget pakke sendt til port 3389 kunne udløse en use-after-free-fejl og køre kode med tjenestens rettigheder, uden krav om login.
Administratorer der installerede opdateringen efter planen, det ansvarlige valg efter enhver normal målestok, gjorde præcis det, sikkerhedsteams beder om hver måned.
Så begyndte Fjernskrivebord at fejle af sig selv
Få timer efter installation af KB5122876 på Server 2019, KB5122882 på Server 2022 eller KB5122871 på Server 2025 begyndte Fjernskrivebordstjenesterne at fejle. Forbindelser der virkede ved opstart, virkede ikke længere få timer senere. Eksisterende sessioner kunne ikke logge af korrekt. Nye forbindelsesforsøg hængte og timede til sidst ud, og i de værste tilfælde var en hård genstart af serveren den eneste løsning.
En administrator beskrev mønsteret ligeud: det virker i starten, men efter første log-af går tjenesten ned, og ingen flere brugere kan logge ind. En forsker der sporede fejlen pegede på en deadlock mellem Fjernskrivebord-processen og Local Session Manager, en diagnose Microsoft ikke har bekræftet.
Hvad der gik i stykker, og hvor
| Windows Server-version | Opdatering | Symptom |
|---|---|---|
| Server 2019 | KB5122876 | RDS fejler timer efter opstart |
| Server 2022 | KB5122882 | Sessioner hænger ved log-af |
| Server 2025 | KB5122871 | Nye forbindelser timer ud |
Microsoft har kun bekræftet at kende til meldingerne og undersøge sagen. Årsagen er ikke bekræftet, og der er ikke nogen dato for en rettelse.
Hvorfor det betyder noget
Hvorfor det betyder noget: Det er ikke en abstrakt debat om patch-styring, det er et reelt valg for ethvert team der driver Windows Server med Fjernskrivebord åbent udad, og i europæiske og britiske virksomheder med hjemmearbejdere, eksterne leverandører eller filialer er det de fleste af dem. At rulle tilbage åbner igen en fejl med alvorlighed 9.8 på de samme servere, en fejl der kan udnyttes uden legitimationsoplysninger. At lade opdateringen sidde kan få selve fjernadgangen, grunden til at de servere findes, til at stoppe uden varsel.
Ja, men
Ja, men: Ingen af de to muligheder er i virkeligheden den eneste udvej. Administratorer der hverken kan risikere en fuld tilbagerulning eller ødelagt fjernadgang begrænser i stedet RDP-eksponeringen på netværksniveau, ved at begrænse port 3389 til et VPN eller en jump host frem for det åbne internet, hvilket holder opdateringen installeret, lukker den letteste vej til den rettede sårbarhed, og køber tid til en officiel rettelse uden at satse på nogen af de to fejlscenarier.
Kort sagt
Kort sagt: "Opdater alt med det samme" og "vent en uge for en sikkerheds skyld" er begge det forkerte instinkt her, for den egentlige beslutning handler ikke om hastighed, men om eksponering. Test hver kumulativ opdatering på en lille kanariegruppe, før den når alle servere, og begræns netværksadgang til alt, opdateringen kan røre, så en dårlig opdatering ødelægger en håndfuld maskiner i stedet for hver Fjernskrivebordssession i virksomheden på en gang.
Læs videre: Apples CEO-chok fra 2011 kostede 12 gange mere end 2026's | Xboxs kovending handlede om markedsføring, ikke spillene
