Microsoft has confirmed that its August 12, 2025 cumulative updates — most notably KB5063878 for Windows 11 (OS Build 26100.4946) and companion packages for Windows 10 and Windows Server — introduced a UAC-related regression that prevents many non‑administrator users from performing routine installer operations, including launching or installing some MSI‑based applications, and that the behavior stems from a security hardening change tied to fixes for a Windows Installer authentication vulnerability (CVE‑2025‑50173). (nvd.nist.gov)
The August 2025 Patch Tuesday rollup bundled the Latest Cumulative Update (LCU) and a Servicing Stack Update (SSU) into combined packages (KB5063878 for Windows 11 24H2 and corresponding KBs for Windows 10/Server). Microsoft documents the rollout and lists several known issues, including a WSUS/SCCM deployment failure that surfaced as 0x80240069, streaming performance regressions with NDI, and other telemetry noise. The company also published targeted release‑health notes after administrators and independent software vendors (ISVs) reported compatibility problems. Two failure threads emerged after the update:
This is a classic security‑compatibility tension: closing an attack surface (preventing silent or weakly authenticated repair flows) also changes assumptions ISVs and enterprise deployment tools relied upon, particularly the ability to deliver per‑user configuration silently when an application was installed machine‑wide by management software.
Source: Neowin KB5063878: Microsoft confirms bug breaks Windows 11, 10, Server app installs for many users
Background / Overview
The August 2025 Patch Tuesday rollup bundled the Latest Cumulative Update (LCU) and a Servicing Stack Update (SSU) into combined packages (KB5063878 for Windows 11 24H2 and corresponding KBs for Windows 10/Server). Microsoft documents the rollout and lists several known issues, including a WSUS/SCCM deployment failure that surfaced as 0x80240069, streaming performance regressions with NDI, and other telemetry noise. The company also published targeted release‑health notes after administrators and independent software vendors (ISVs) reported compatibility problems. Two failure threads emerged after the update:- Enterprise/managed‑deployment failures where WSUS and Configuration Manager (SCCM/MECM) deployments could fail with 0x80240069, and Microsoft issued an emergency mitigation using Known Issue Rollback (KIR) to unblock deployments.
- A separate, high‑impact compatibility regression that changes how Windows Installer (MSI) repair and active setup flows interact with User Account Control (UAC), causing elevation prompts or outright failures when standard (non‑admin) users launch certain applications for the first time. This second issue is the subject of the confirmed acknowledgment and is what caused broad disruption for apps such as Autodesk AutoCAD, Firefox, SAP client components, and even some Office installer scenarios in standard user contexts.
What exactly is breaking — symptoms and scope
Primary symptoms observed in the field
- UAC credential/consent prompts appear the first time a standard user launches certain apps (for example, AutoCAD) or when the app attempts a per‑user configuration step that previously ran silently.
- If the standard user cancels or cannot provide admin credentials, installers or repairs abort and return MSI error codes such as 1730 (or other MSI‑related failures).
- The problem affects systems running the August 2025 updates (various client and server SKUs), and it specifically impacts scenarios where applications were installed in the system context (for example, deployed via SCCM/ConfigMgr or WSUS) but also perform per‑user configuration on first launch. (windowsforum.com)
Examples and reported cases
- Autodesk (AutoCAD family, Civil 3D, Inventor CAM): Administrators reported that AutoCAD asks for elevated credentials on first launch; Autodesk support confirmed the behavior, recommended running as administrator or uninstalling the update as a temporary measure, and advised Microsoft collaboration.
- Office Professional Plus 2010: Microsoft gave Office Professional Plus 2010 as a concrete example where installing or configuring as a standard user can fail during configuration with Error 1730. This illustrates the problem is not limited to a single vendor or modern SKU.
- Firefox, SAP and other MSI‑deploying applications: Community reports and ISV threads show the problem reproduces in lab environments for apps that rely on MSI advertising/repair for per‑user setup.
Platforms affected
- Microsoft’s advisory covers Windows 11, Windows 10, and Windows Server platforms where the August 2025 cumulative updates or equivalent servicing packages were installed. The regression is behavior‑level in the Windows Installer / UAC interaction and therefore spans client and server builds.
Why this happened — the security trade‑off
Microsoft’s August security packages included a fix for CVE‑2025‑50173, described by NIST/NVD as a Windows Installer weak authentication vulnerability that could allow elevation of privileges if exploited. The security rationale was to harden Windows Installer and prevent unauthorized MSI repair or advertising operations from being abused for privilege escalation. That hardening changed the conditions under which the Installer runs repairs in the context of a standard user, turning previously silent repairs into operations requiring elevation in certain cases. (bleepingcomputer.com)This is a classic security‑compatibility tension: closing an attack surface (preventing silent or weakly authenticated repair flows) also changes assumptions ISVs and enterprise deployment tools relied upon, particularly the ability to deliver per‑user configuration silently when an application was installed machine‑wide by management software.
Official mitigations and Microsoft’s response
Microsoft has taken multiple steps to mitigate the impact and to guide administrators:- Known Issue Rollback (KIR): Microsoft released a KIR policy that administrators could deploy via Group Policy to revert the specific behavioral change for impacted scenarios until a permanent fix is produced. For the WSUS/SCCM installation failures (0x80240069) Microsoft also rolled out specific mitigations and re‑released corrected packages for managed channels. Microsoft’s KB for KB5063878 documents these known issues and the temporary measures.
- Short‑term guidance — run as administrator: For immediate relief on an affected machine, ISVs and Microsoft both suggest launching the affected app or installer with elevated rights (Right‑click → Run as administrator) so the per‑user configuration can complete. This is inconvenient at scale but effective where admin credentials are available.
- Registry / Group Policy workarounds (with security caveats): ISVs (and some published guidance) have pointed to the DisableLUAInRepair policy (registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer, 32‑bit DWORD DisableLUAInRepair = 1) as a workaround to reinstate the pre‑hardening behavior for MSI repair operations. Microsoft and security researchers warn that changing this policy effectively re‑opens the attack surface that the original security fix was designed to close and should be treated as a last‑resort measure only in controlled environments. (applicationreadiness.com)
Step‑by‑step mitigations for admins and power users
The following list prioritizes safety and operational practicality.- Identify impact scope
- Roll out detection quickly: query endpoint logs, MSI repair events, and application helpdesk tickets to map which apps and user populations are affected.
- Prioritize business‑critical apps and shared environments (labs, kiosks, call centers).
- Short‑term, least‑privilege response (recommended first)
- Ask affected users to Run as administrator when launching the app or installer (temporary, manual).
- For managed deployments, consider staging installations from a maintenance window where an admin account can be used to finish per‑user configuration.
- Controlled temporary policy rollback (use only in trusted environments)
- Deploy the Microsoft KIR Group Policy if Microsoft published one that matches the scenario (this reverts the specific change while retaining broader security fixes). Microsoft documents KIR availability and GPO location details for KB5063878. Organizations should audit KIR deployments and plan to remove them when a permanent fix is released.
- Registry workaround (high security risk; avoid unless unavoidable)
- Set DisableLUAInRepair = 1 under:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer - Note: This setting restores legacy behavior but re‑introduces a vector that could be exploited for privilege escalation — only use for tightly controlled lab or test environments, and remove as soon as the upstream patch is available. (applicationreadiness.com)
- Deployment avoidance and rollback planning
- If possible, pause the affected cumulative updates in WSUS/ConfigMgr rings until a full fix is available for your environment. Validate rollback and recovery steps in a test ring before performing wide rollbacks.
- Use the Microsoft Update Catalog / manual installs for unaffected endpoint classes where WSUS issues persist for the 0x80240069 scenario.
- Communicate and coordinate with ISVs
- ISVs (Autodesk, Mozilla, SAP, etc. are tracking the issue and often publish product‑specific guidance. Coordinate with your software vendors for vendor‑provided hotfixes or updated installers that avoid per‑user repair during first launch.
The security implications of the available workarounds
The central security trade‑off deserves explicit emphasis:- Microsoft’s hardening addressed an installer authentication weakness that could lead to local privilege escalation (CVE‑2025‑50173). Reverting or weakening that hardening (for example, via DisableLUAInRepair) restores usability but also re‑exposes endpoints to the original class of risk.
- KIR is the preferred mitigation because it can target a narrow regression while preserving the other security changes in the update; however, KIR still represents a rollback of behavior and should be used as a temporary measure until Microsoft provides an officially sanctioned servicing fix.
- Administrators must perform a risk assessment weighing the operational impact of blocked apps against the elevated attack surface risk if they revert the mitigation. In high‑security environments (finance, healthcare, critical infrastructure), the safer path is to require admin assistance for the short term while coordinating with ISVs and Microsoft for a long‑term fix. (applicationreadiness.com)
Related noise: SSD failure reports and verification status
Shortly after the August updates, a cluster of user reports suggested that KB5063878 or companion updates caused NVMe/SSD drives (some allegedly with Phison controllers or DRAM‑less designs) to disappear or suffer data corruption under heavy write workloads. Those reports gained broad attention in enthusiast communities and some outlets ran cautionary pieces. Microsoft and SSD vendor Phison both stated they could not reproduce widespread drive failures and found no telemetry indicating a link between the August security update and mass SSD bricking. Independent outlets (The Verge, Tom’s Hardware, BleepingComputer, Windows Central) summarized vendor statements and investigations showing no confirmed causal relationship at the time of those follow‑ups. The consensus among vendors and platform telemetry at the time was that the SSD claims remained unproven and required further user‑provided diagnostics to validate. Treat SSD‑bricking claims as unverified early reports unless you have direct vendor confirmation or reproducible lab evidence. (theverge.com, support.microsoft.com, borncity.com, forums.autodesk.com, bleepingcomputer.com, support.microsoft.com, forums.autodesk.com)Source: Neowin KB5063878: Microsoft confirms bug breaks Windows 11, 10, Server app installs for many users
