A user on a non-English Windows 11 device installs this month's cumulative update and their custom mouse cursor - the one they picked in Settings, maybe an accessibility-sized pointer or a themed cursor pack - quietly reverts to the plain default arrow. They set it back. It doesn't stick. Nothing in the UI says why, and nothing they try fixes it permanently.
Microsoft has confirmed this is a real, currently-unfixed bug in KB5120998 (released August 27, 2026) - and confirmed something else worth knowing before your help desk spends an afternoon debugging it: it only happens on Windows installed in a language other than English.
KB5120998 breaks mouse cursor personalization - custom cursor schemes and cursor animations get reset to Windows defaults, and manually setting them back again does not fix it - but Microsoft's official investigation says this only affects non-English Windows 11 installations. It's confirmed on both Windows 11 24H2 and 25H2, has no fix yet, and is a genuinely separate bug from the other KB5120998 issue you may already know about (desktop backgrounds turning solid black). This post covers how to tell if your fleet is exposed, how to check a device, and a read-only script that flags which of your managed devices are actually at risk based on installed update and locale.
The problem: a custom cursor that won't stay custom
Microsoft's own description of this, from the Windows release health dashboard, is specific: after installing updates released on or after August 27, 2026, mouse personalization settings get reverted to standard defaults. That covers the cursor scheme itself and any cursor animations selected under Mouse Properties. The part that makes this more than a cosmetic annoyance: manually restoring the settings does not work. The user can go back into Settings, pick their custom cursor again, and it will not persist - the same failure that reset it in the first place stops it from being set correctly at all.
For anyone supporting a help desk: this is the kind of ticket that looks like user error ("I changed my cursor, why didn't it save") until you know the real cause. It's worth briefing your team on this before the tickets start, especially if your organization runs Windows in more than one language.
Why it happens: a settings-loading failure specific to non-English locales
Microsoft's own investigation, published on the release health dashboard, points to a specific and narrow cause: certain code components used specifically in non-English Windows installations. In those affected locales, the mouse personalization settings simply fail to load - and when a setting fails to load, Windows falls back to a default value instead of erroring out. That's why re-applying the setting doesn't help: the value gets saved correctly, but the same loading failure prevents it from being read back and applied the next time it matters.
The practical consequence of "non-English locales only" is that this bug is invisible in most vendor lab testing and most internal IT testing, if your test devices default to English - and very visible the moment it reaches a real non-English-speaking user base. If your organization has offices, contractors, or remote staff running Windows in French, German, Japanese, or any non-English display language, this is relevant to you even if your own admin workstation shows nothing wrong.
How to verify: is a device actually exposed
Two conditions have to both be true for a device to be at risk: it has KB5120998 (or a later cumulative update) installed, and its display language is not English. Neither condition alone tells you the bug is actively happening - Microsoft's wording is that settings "may intermittently revert," not that every affected device is guaranteed to show the symptom right now - but both conditions together tell you which devices are worth watching and which support tickets to take seriously.
If Get-HotFix returns the update and Get-WinSystemLocale shows anything other than an English variant, that device meets both conditions and is worth flagging. This check reads current state only - it doesn't change anything on the device.
The fix: there isn't one yet - here are the real options
Be precise with anyone you tell about this: Microsoft's own advisory does not currently list a fix or an official workaround. The stated next step, as of this writing, is simply that Microsoft is working on a resolution in a future update. That's a materially different situation from most known-issue posts on this site, where a registry change or a Known Issue Rollback is already available - here, neither exists yet.
That leaves genuinely two options, and both carry a real tradeoff:
- Wait for the fix. If the symptom is cosmetic-only for your affected users (a wrong-looking cursor, not a blocking issue), this is the lowest-risk choice - no update to remove, no security patches given up.
- Uninstall KB5120998. This is the workaround reported by affected users and referenced in community troubleshooting, not something Microsoft's own advisory formally recommends. It resolves the symptom because it removes the update that caused it - but it also removes whatever security fixes shipped in that same cumulative update, on that device, until the next update cycle reinstalls it.
To uninstall the update on an individual device: Settings › Windows Update › Update history › Uninstall updates, then select KB5120998 and confirm.
Proof it worked
Since there is no code fix to verify yet, "proof" here means confirming which devices are actually exposed, so you can prioritize communication or a temporary uninstall for the ones that matter - not confirming a resolution that doesn't exist yet.
Illustrative results across a small fleet, showing the three outcomes the script distinguishes between:
Read it the same way the script's summary reads it: FIN-LT-0231 has the update but is running English, so it's outside the documented scope of this bug. SALES-LT-0087 has both conditions Microsoft describes, so it's a genuine candidate for a support conversation or a temporary uninstall. ENG-WS-0012 hasn't even installed the update yet, so it isn't affected regardless of locale.
Here's a genuine, real captured run against a real device - this one happens to come back clean, which is itself a useful confirmation that the check works correctly and doesn't false-flag an unaffected machine:
Exit code 0 here: no KB5120998 yet, and English locale regardless - two independent reasons this device is outside the documented risk, matching exactly what the script's own logic is designed to report.
Script for this post is in Daily-Tasks. Download and run it directly - no sign-in required. It is read-only and makes no changes to any device; validate it in your own environment before running it against a fleet.
References
- Windows 11, version 25H2 known issues and notifications - Microsoft Learn - the official advisory confirming the cursor personalization bug, its root cause, and affected platforms.
- Windows 11, version 24H2 known issues and notifications - Microsoft Learn - the same advisory as it applies to 24H2 devices.
- KB5120998 update history page - Microsoft Support - the originating cumulative update.
Related on EndpointWeekly
- Windows 11 KB5120998 Can Reset Desktop Backgrounds to Black - the separate, similarly-caused known issue from the same update.