Microsofts August-Veröffentlichung enthält drei PowerShell-Schwachstellen zu Remotecodeausführung, Umgehung einer Sicherheitsfunktion und Rechteausweitung. Betrieblich entscheidend ist, dass PowerShell 7 unabhängig von Windows PowerShell gewartet wird und mehrfach auf demselben System vorkommen kann. Ein vollständig gepatchtes Betriebssystem beweist nicht, dass jedes von der Automation verwendete `pwsh` aktuell ist.

Bedeutung für den Betrieb

Der Bestand reicht über Admin-Laptops hinaus. Jump Hosts, Task-Server, CI-Runner, Configuration-Management-Nodes, Monitoringserver, Backup-Konsolen, Container-Images und paketierte Werkzeuge können eigene Runtimes enthalten. Erfasst werden Pfad, Version, Architektur, Installationskanal, Dienst- oder Taskreferenzen, Modulpfade und Eigentümer. Eine Suche nur im System-PATH übersieht fixierte oder eingebettete Kopien.

Technische Infrastruktur für PowerShell-Runtime-Patching
PowerShell-Runtime-Patching beginnt mit vollständigem Bestand und klaren Betriebsgrenzen.

Das Runtime-Update benötigt Kompatibilitätstests. Repräsentative Skripte verbinden sich mit Active Directory, SQL Server, VMware, Veeam und weiteren Zielplattformen mit denselben Modulen und Credentials wie in Produktion. Remoting, TLS-Aushandlung, Serialisierung, native Befehle, Fehlerbehandlung, Transcripts und nicht interaktive Ausführung werden geprüft. Ein Sicherheitsupgrade, das im Task Scheduler still stoppt, erzeugt ein neues Risiko.

Servicing-Verantwortung muss eindeutig sein. MSI-Verteilung, Microsoft Update, internes Repository oder kontrolliertes Deploymentskript werden bewusst gewählt. Fixierte Versionen schaffen Reproduzierbarkeit, benötigen aber einen Review-Rhythmus. Modulinventar und Execution Policy ersetzen kein Runtime-Patching, und ein alter Runner bleibt nicht vertrauenswürdig, nur weil seine Skripte signiert sind.

Betriebliche Prüfung für PowerShell-Runtime-Patching
Der Change endet erst nach der Validierung von PowerShell-Runtime-Patching unter realen Bedingungen.

Praktische Konsequenz

Die praktische Konsequenz ist, PowerShell als Anwendungsplattform zu behandeln. Jede Runtime entdecken, über einen verantworteten Kanal patchen, die echte Automation testen und Fehler nach dem Rollout überwachen. Das wichtigste PowerShell-Update erreicht den Host möglicherweise nie über denselben Mechanismus wie das Betriebssystem darunter.