Mit dem August-Update 2025 für Windows (KB5063878) und darauffolgenden Patches hat Microsoft das Verhalten von User Account Control (UAC) und Windows Installer grundlegend verschärft. Auslöser ist die Schließung der Rechteausweitung CVE-2025-50173, über die sich authentifizierte Angreifer Systemrechte verschaffen konnten. Seit dem Update verlangen Reparatur- und Self‑Healing‑Routinen von MSI nun explizit Administratornachweise.
UAC- und Windows-Installer-Aenderungen: MSI-Repair benötigt Adminrechte
Um die Ausnutzung von CVE-2025-50173 zu unterbinden, erzwingt Windows für MSI‑Reparaturpfade eine höhere Integrität: UAC fordert Administrator-Credentials bei „Repair“-Operationen und verwandten MSI-Aktionen. Das betrifft auch UI‑lose Szenarien, etwa msiexec /fu oder Reparaturroutinen, die im Rahmen von Active Setup im Benutzerkontext ausgeführt werden.
Startet ein Standardbenutzer eine Anwendung, die still eine MSI‑Reparatur triggert, schlägt der Prozess ohne Elevation fehl. In der Praxis treten Meldungen wie Error 1730 auf, beispielsweise bei der Erstkonfiguration älterer Pakete wie Office Professional Plus 2010 im Benutzerkontext. Dieses Verhalten ist beabsichtigt und folgt dem Prinzip der geringsten Rechte.
Betroffene Windows-Versionen und typische Fehlerbilder
Betroffen sind Benutzer ohne Administratorrechte auf allen aktuell unterstützten Windows-Editionen – Client und Server. Dazu zählen unter anderem Windows 11 24H2/23H2/22H2; Windows 10 22H2/21H2/1809; Windows 10 Enterprise LTSC 2019/2016; Windows 10 1607; Windows 10 Enterprise 2015 LTSB sowie Windows Server 2025/2022/2019/2016/1809/2012 R2/2012 (laut Microsoft Release Notes und Security Update Guide).
In Unternehmensumgebungen zeigen sich wiederkehrende Muster: ConfigMgr-Deployments im Benutzerkontext (advertising) scheitern ohne Elevation; die Interaktion mit UAC Secure Desktop erschwert Benutzerflüsse; und Komponentenreparaturen bei Autodesk‑Produkten wie AutoCAD, Civil 3D oder Inventor CAM lösen UAC‑Prompts aus, wodurch der Startprozess abbricht.
Sicherheitskontext: warum diese Härtung notwendig ist
Das MSI‑„Self‑Healing“ existiert seit Jahren und kann sowohl Benutzer- als auch Maschinenkomponenten nachinstallieren oder reparieren. In Post‑Exploitation‑Ketten nutzten Angreifer solche Mechanismen, um über fehlerhafte KeyPaths, Advertised Shortcuts oder manipulierte Komponenten zu Privilegienerhöhungen zu gelangen. Die nun eingeführte UAC‑Härtung blockiert diese Angriffsfläche systemweit, indem Reparaturen ohne explizite Adminrechte nicht mehr zulässig sind. Der Preis dafür ist mehr Reibung bei stillen Installationen und per‑User‑Konfigurationen – ein sicherheitsgetriebener Trade‑off, der aus Verteidigungssicht sinnvoll ist.
Empfehlungen und Workarounds für IT-Administratoren
Microsoft arbeitet an einer Richtlinienoption, mit der sich definierte Anwendungen für MSI‑Repair ohne zusätzliche UAC‑Prompts erlauben lassen (Ausnahmeregel auf Policy‑Ebene). Bis diese verfügbar ist, empfiehlt es sich, betroffene Anwendungen grundsätzlich mit Administratorrechten auszuführen.
Per‑Machine statt Per‑User deployen. Pakete nach Möglichkeit in den Maschinenkontext verlagern: ALLUSERS=1 setzen und via ConfigMgr im SYSTEM-Kontext („Whether or not a user is logged on“) verteilen, um per‑User‑Repair‑Trigger zu vermeiden.
Advertised Shortcuts und Autorepair deaktivieren. Mit DISABLEADVTSHORTCUTS=1 keine „advertised“ Verknüpfungen erstellen und Self‑Heal‑Szenarien vermeiden; KeyPaths kritisch prüfen, um unbeabsichtigte Reparaturen zu verhindern.
Active Setup minimieren. Benutzerinitialisierung möglichst in maschinenweite Konfiguration verschieben (z. B. HKLM statt HKCU) und Post‑Logon‑Skripte so anpassen, dass keine MSI‑Repair‑Aufrufe im Benutzerkontext entstehen.
Packaging modernisieren. Wo realistisch, Migration zu MSIX oder robusten, per‑Machine‑MSI‑Paketen mit klar getrennten User‑Daten. Signaturen und Integritätsprüfungen durchgängig einsetzen, um Reparaturabhängigkeiten zu reduzieren.
UAC/Sicherheitsrichtlinien validieren. Interaktion mit Secure Desktop testen, AppLocker/WDAC‑Regeln prüfen und Pilotgruppen einsetzen. Begleitdokumentation von Microsoft (Security Update Guide zu CVE‑2025‑50173 und Windows Release Health) im Blick behalten.
Unternehmen sollten kurzfristig Paketierungs- und Deployment‑Standards überprüfen, Pilotrollouts einplanen und Benutzerkommunikation vorbereiten, um Supportaufkommen durch UAC‑Prompts abzufedern. Mittel- bis langfristig lohnt sich die Konsolidierung auf maschinenweite Deployments und die Reduktion von Self‑Healing‑Abhängigkeiten. So bleiben Systeme widerstandsfähig gegen Rechteausweitungen, ohne die Betriebssicherheit unnötig zu beeinträchtigen.
