Windows 11 KB5132061: Sicherheitsupdate kann Probleme mit PowerShell-Skripten verursachen
Microsoft hat mit dem November-Patchday 2026 zahlreiche Sicherheitsverbesserungen für Windows 11 veröffentlicht. Doch eine Änderung im aktuellen Update KB5132061 könnte bei Administratoren und Nutzern, die regelmäßig mit PowerShell arbeiten, für unerwartete Schwierigkeiten sorgen.
Der Grund ist eine verschärfte Sicherheitsprüfung für digital signierte PowerShell-Skripte.
Bestimmte Skripte, die bisher problemlos ausgeführt werden konnten, werden nach der Installation des Updates möglicherweise nicht mehr als gültig signiert erkannt.
Dabei handelt es sich nicht um einen klassischen Windows-Fehler, sondern um eine bewusst eingeführte Sicherheitsänderung.
Microsoft hat inzwischen eine ausführliche Anleitung veröffentlicht, mit der sich betroffene Skripte identifizieren und reparieren lassen.
Was ändert sich durch Windows 11 KB5132061?
Mit dem Sicherheitsupdate vom 10. November 2026 hat Microsoft die Überprüfung digitaler PowerShell-Signaturen überarbeitet.
Konkret geht es um die Zeichenkodierung innerhalb von Skriptdateien.
Diese bestimmt, wie Buchstaben, Sonderzeichen und andere Zeichen in einer Datei gespeichert werden.
Besonders wichtig ist dabei UTF-8. Dieses Format wird häufig für PowerShell-Skripte verwendet und unterstützt zahlreiche unterschiedliche Zeichen.
Das Problem: Nicht jede Datei, die als UTF-8 verarbeitet wird, enthält tatsächlich eine vollständig gültige UTF-8-Kodierung.
Bisher konnte Windows bestimmte fehlerhafte Zeichenfolgen bei der Verarbeitung ersetzen und das Skript trotzdem als gültig signiert akzeptieren.
Mit dem November-Update wird diese Überprüfung strenger.
Enthält eine betroffene Datei ungültige Zeichenfolgen, kann Windows die digitale Signatur künftig zurückweisen.
Das bedeutet allerdings nicht, dass plötzlich sämtliche älteren PowerShell-Skripte nicht mehr funktionieren.
Betroffen sind vor allem Dateien, bei denen die verwendete Zeichenkodierung nicht korrekt verarbeitet werden kann.
Warum sind digitale PowerShell-Signaturen wichtig?
Gerade in Unternehmen werden PowerShell-Skripte häufig verwendet, um wiederkehrende Aufgaben zu automatisieren.
Dazu gehören beispielsweise die Installation von Software, die Verwaltung von Benutzerkonten oder verschiedene Wartungsaufgaben auf Windows-Computern.
Viele dieser Skripte laufen regelmäßig und teilweise vollkommen automatisch.
Damit sichergestellt werden kann, dass solche Dateien von einem vertrauenswürdigen Herausgeber stammen und nachträglich nicht verändert wurden, lassen sie sich digital signieren.
Eine solche Signatur basiert auf einem Zertifikat und ermöglicht die Überprüfung der Datei.
Wird ein signiertes Skript verändert, sollte Windows erkennen können, dass die Signatur nicht mehr zum ursprünglichen Inhalt passt.
Das funktioniert allerdings nur dann zuverlässig, wenn die Datei beim Signieren und Überprüfen eindeutig interpretiert wird.
Genau hier setzt Microsoft mit den neuen Sicherheitsprüfungen an.
Aus meiner Sicht ist das grundsätzlich eine sinnvolle Verbesserung.
Schließlich sollte eine digitale Signatur möglichst zuverlässig bestätigen, dass eine Datei tatsächlich unverändert geblieben ist.
Allerdings können solche Änderungen natürlich unangenehm werden, wenn plötzlich ältere Automatisierungen nicht mehr funktionieren.
PowerShell meldet Skripte möglicherweise als nicht signiert
Besonders auffällig ist das neue Verhalten beim Befehl Get-AuthenticodeSignature.
Mit diesem PowerShell-Befehl lässt sich überprüfen, ob eine Datei eine gültige digitale Signatur besitzt.
Ein typischer Aufruf sieht folgendermaßen aus:
Get-AuthenticodeSignature -FilePath "C:\Scripts\Wartung.ps1"
Bei einem betroffenen Skript kann nach dem November-Update plötzlich folgender Status erscheinen:
Status : NotSigned
Das kann auch dann passieren, wenn die Datei zuvor erfolgreich signiert wurde.
Die Signatur wird in diesem Fall aufgrund der strengeren Überprüfung nicht mehr korrekt anerkannt.
Auch der Versuch, ein betroffenes Skript erneut zu signieren, kann fehlschlagen.
Microsoft nennt dafür unter anderem den Status UnknownError.
Zusätzlich kann eine Fehlermeldung erscheinen, die darauf hinweist, dass bestimmte Unicode-Zeichen nicht in die verwendete Codepage übertragen werden können.
Besonders problematisch wird das, wenn innerhalb eines Unternehmens Sicherheitsrichtlinien gelten, die ausschließlich die Ausführung signierter Skripte erlauben.
Dann kann eine bisher funktionierende Automatisierung plötzlich nicht mehr starten.
Auch Windows App Control kann betroffen sein
Die Auswirkungen beschränken sich nicht ausschließlich auf die normale PowerShell-Signaturprüfung.
Microsoft nennt außerdem mögliche Veränderungen im Zusammenhang mit App Control for Business, früher unter anderem als Windows Defender Application Control bekannt.
Diese Sicherheitsfunktion ermöglicht es Unternehmen, genau festzulegen, welche Anwendungen und Skripte auf verwalteten Geräten ausgeführt werden dürfen.
Werden bestimmte Skripte aufgrund ihrer fehlerhaften Kodierung nicht mehr als vertrauenswürdig erkannt, können sie unter Umständen nur noch im eingeschränkten PowerShell-Modus ausgeführt werden.
Dieser wird als ConstrainedLanguage bezeichnet.
Dabei sind bestimmte PowerShell-Funktionen nicht mehr verfügbar.
Für einfache Skripte muss das nicht unbedingt ein Problem sein.
Komplexere Verwaltungsaufgaben können dadurch allerdings fehlschlagen.
Wichtig ist: Nicht jede Meldung über eine ungültige Signatur hängt automatisch mit dem November-Update zusammen. Auch abgelaufene Zertifikate, veränderte Dateien oder andere Probleme können solche Fehler verursachen.
Welche Windows-Versionen sind betroffen?
Die neue Sicherheitsprüfung ist nicht ausschließlich Bestandteil von Windows 11 KB5132061.
Microsoft hat die Änderung auch für weitere unterstützte Windows-Versionen dokumentiert.
Dazu gehören unter anderem:
Windows 11 23H2 bis 26H2
Windows 10 Enterprise LTSC 2021
Windows Server 2016
Windows Server 2019
Windows Server 2022
Windows Server 2025
Auch Windows 11 26H1 gehört zu den unterstützten Versionen.
Die neuen Regeln gelten für entsprechende Windows-Sicherheitsupdates ab dem 10. November 2026.
Damit können auch Unternehmen betroffen sein, die noch ältere Windows-Server-Versionen einsetzen.
Gerade dort werden PowerShell-Skripte häufig seit vielen Jahren verwendet.
Und genau solche über längere Zeit gewachsenen Automatisierungen würde ich nach dieser Änderung besonders im Blick behalten.
Microsoft empfiehlt UTF-8 mit BOM und eine erneute Signierung
Für betroffene Skripte hat Microsoft bereits eine konkrete Empfehlung veröffentlicht.
Die Dateien sollen überprüft, bei Bedarf in eine gültige UTF-8-Kodierung mit Byte Order Mark (BOM) umgewandelt und anschließend erneut digital signiert werden.
Die Byte Order Mark ist eine Kennzeichnung am Anfang einer Datei, anhand derer Windows die verwendete Zeichenkodierung erkennen kann.
Sie kann verhindern, dass die Datei versehentlich mit einer anderen Kodierung interpretiert wird.
Allerdings reicht es nicht immer aus, einfach nur eine BOM hinzuzufügen.
Wenn die Datei bereits beschädigte oder ungültige Zeichen enthält, müssen diese zunächst überprüft und korrigiert werden.
Eine erneute Signierung ist erforderlich, wenn die Datei bei der Korrektur verändert wurde und die bisherige Signatur dadurch nicht mehr gültig ist.
Deshalb sollte man bei solchen Reparaturen nicht einfach wahllos alle PowerShell-Dateien neu speichern.
Gerade in Unternehmensumgebungen können dabei ungewollt Änderungen entstehen, die anschließend weitere Probleme verursachen.
Microsoft stellt ein eigenes Reparaturskript bereit
Um Administratoren die Fehlersuche zu erleichtern, hat Microsoft ein spezielles PowerShell-Werkzeug veröffentlicht.
Es trägt den Namen:
Repair-SignedPowerShellUtf8.ps1
Das Skript kann vorhandene PowerShell-Dateien auf mögliche Kodierungsprobleme überprüfen und verschiedene Reparaturmöglichkeiten anbieten.
Besonders praktisch finde ich, dass Microsoft dabei unterschiedliche Betriebsarten vorgesehen hat.
Scan: Betroffene Skripte erkennen
Im Scan-Modus werden Dateien lediglich untersucht.
Das Werkzeug überprüft mögliche Kodierungsprobleme und zeigt den aktuellen Signaturstatus an.
Die Originaldateien werden dabei nicht verändert.
Das ist meiner Meinung nach auch der sinnvollste Einstieg.
Bevor man irgendwelche Reparaturen durchführt, sollte schließlich erst einmal feststehen, welche Dateien überhaupt betroffen sind.
Repair: Bestehende Signatur möglichst erhalten
Mit dem Reparaturmodus versucht das Werkzeug, bestimmte Kodierungsprobleme zu korrigieren, ohne die vorhandene digitale Signatur zu ersetzen.
Dabei wird eine separate Kopie der Datei erstellt.
Allerdings funktioniert diese Methode nicht bei allen Fehlerarten.
Microsoft weist ausdrücklich darauf hin, dass eine erfolgreiche Reparatur nicht garantiert werden kann.
ConvertToUtf8Bom: Datei dauerhaft korrigieren
Eine weitere Möglichkeit besteht darin, das Skript in gültiges UTF-8 mit BOM umzuwandeln.
Auch dabei bleibt die Originaldatei erhalten.
Die bisherige Signatur wird aus der umgewandelten Kopie entfernt.
Anschließend muss die Datei überprüft und mit einem gültigen Code-Signing-Zertifikat erneut signiert werden.
Für eine langfristige Lösung ist das laut Microsoft der bevorzugte Weg.
Das Reparaturwerkzeug sollte entsprechend der Microsoft-Anleitung unter Windows PowerShell 5.1 und mit den erforderlichen Berechtigungen beziehungsweise Sicherheitsfreigaben verwendet werden.
Was sollten Administratoren jetzt überprüfen?
Wer in seiner Windows-Umgebung regelmäßig PowerShell-Skripte einsetzt, sollte nach der Installation der November-Updates besonders auf Signaturfehler achten.
Ich würde dabei vor allem drei Bereiche kontrollieren.
Automatisierte Wartungsskripte: Dazu gehören Aufgaben, die regelmäßig über die Windows-Aufgabenplanung oder andere Verwaltungslösungen gestartet werden.
Softwareverteilung und Anmeldeskripte: Gerade bei Installationen, Benutzeranmeldungen und Gerätekonfigurationen können fehlerhafte Skripte schnell Auswirkungen auf mehrere Computer haben.
Sicherheitsrichtlinien: Unternehmen, die nur digital signierte Skripte zulassen, sollten prüfen, ob alle benötigten Dateien weiterhin als vertrauenswürdig erkannt werden.
Wer keine Fehler feststellt, muss nicht vorsorglich sämtliche vorhandenen Skripte verändern.
Die strengere Überprüfung betrifft schließlich nicht automatisch jede PowerShell-Datei.
Bei auftretenden Problemen empfiehlt sich dagegen zunächst eine Prüfung der digitalen Signatur und der verwendeten Zeichenkodierung.
Erst danach sollte entschieden werden, ob eine Reparatur oder erneute Signierung notwendig ist.
Hat das etwas mit PowerShell 7.7 zu tun?
Interessant ist der Zeitpunkt dieser Änderung.
Erst vor Kurzem hat Microsoft mit PowerShell 7.7 eine neue Version seines Verwaltungswerkzeugs veröffentlicht.
Die neue Version basiert auf .NET 11 und bringt ebenfalls verschiedene Sicherheitsverbesserungen mit.
Allerdings besteht hier ein wichtiger Unterschied.
Die strengere Signaturprüfung ist Bestandteil der Windows-Sicherheitsupdates und keine Neuerung, die ausschließlich durch PowerShell 7.7 eingeführt wird.
Man muss also nicht erst PowerShell 7.7 installieren, um von den Änderungen betroffen zu sein.
Auch vorhandene Windows-PowerShell-Installationen können die Auswirkungen der verschärften Sicherheitsprüfung zeigen.
Das ist besonders für Administratoren wichtig, die bewusst weiterhin Windows PowerShell 5.1 einsetzen.
Sollte man KB5132061 deshalb nicht installieren?
Nein. Davon würde ich grundsätzlich abraten.
KB5132061 gehört zum Microsoft-Patchday vom November 2026 und enthält zahlreiche wichtige Sicherheitskorrekturen.
Die strengere Überprüfung von PowerShell-Signaturen ist dabei ausdrücklich als Sicherheitsverbesserung vorgesehen.
Sie soll verhindern, dass fehlerhaft kodierte Skripte weiterhin unter Umständen als gültig signiert behandelt werden.
Natürlich ist es ärgerlich, wenn dadurch vorhandene Automatisierungen angepasst werden müssen.
Das bedeutet aber nicht, dass die Änderung grundsätzlich falsch ist.
Meiner Meinung nach ist es sinnvoller, betroffene Skripte gezielt zu korrigieren, anstatt auf wichtige Windows-Sicherheitsupdates zu verzichten.
Gerade in Unternehmen sollten solche Änderungen allerdings zunächst kontrolliert getestet werden.
So lassen sich mögliche Probleme erkennen, bevor sie produktive Arbeitsabläufe beeinträchtigen.
Fazit: Mehr Sicherheit, aber möglicherweise zusätzlicher Aufwand
Mit KB5132061 verschärft Microsoft die Sicherheitskontrollen für digital signierte PowerShell-Skripte.
Das ist grundsätzlich eine gute Entscheidung, denn digitale Signaturen sollen zuverlässig erkennen lassen, ob eine Datei unverändert und vertrauenswürdig ist.
Allerdings kann die neue Prüfung dazu führen, dass ältere Skripte mit fehlerhafter Zeichenkodierung plötzlich nicht mehr als gültig signiert erkannt werden.
Besonders Unternehmen mit umfangreichen PowerShell-Automatisierungen sollten deshalb aufmerksam bleiben.
Microsoft bietet mit seiner Dokumentation und dem Reparaturskript bereits konkrete Hilfsmittel an, um betroffene Dateien zu identifizieren und zu korrigieren.
Ich würde die Änderung nicht als Grund sehen, das November-Sicherheitsupdate zu vermeiden. Vielmehr ist sie ein guter Anlass, ältere PowerShell-Skripte und deren Signaturen einmal genauer zu überprüfen.
Denn gerade bei Automatisierungen, die seit Jahren zuverlässig laufen, schaut man häufig erst dann wieder genauer hin, wenn plötzlich etwas nicht mehr funktioniert.
Und manchmal zeigt sich dabei, dass eine kleine technische Anpassung längst überfällig war.
Quellen
Neowin – Ivan Jenic, 11. November 2026
Latest Windows 11 update KB5132061 could break your PowerShell scripts
https://www.neowin.net/news/latest-windows-11-update-kb5132061-could-break-your-powershell-scripts/
Microsoft Support – 10. November 2026
KB5132061 – Windows 11 Sicherheitsupdate
https://support.microsoft.com/de-de/servicing/os/windows-11/2026/11/kb5132061-windows-11-24h2-25h2-26h2-security-update
Microsoft Support – KB5135999
Encoding Guidance for Signed PowerShell Scripts
https://support.microsoft.com/en-us/servicing/os/windows/docs/2026/11/powershell-sip-canonical-repair
Microsoft Support – KB5136213
Sample PowerShell script to repair script-signature encoding issues
https://support.microsoft.com/en-us/servicing/os/windows/docs/2026/11/powershell-sip-repair-script
