#2964 Add support for apps with a higher integrity level.

[Koj]

Hello,

KeePass (up to v2.60) has a medium integrity level and is therefore unable to interact with applications that have a higher integrity level.

Three prerequisites must be met to enable this:

1. UIAccess must be enabled in the manifest.
2. The app must be digitally signed.
3. The app must be launched from a secure folder such as C:\Program Files (including subdirectories).

KeePass is already signed and stored in a secure folder by default; it simply lacks the UIAccess flag.

Thank you for reading, and best regards.

[Dominik Reichl]

I've experimented with this (on an up-to-date Windows 11 25H2 system). Setting uiAccess="true" does indeed allow KeePass to perform auto-type into applications running with a high integrity level. Unfortunately, we also get massive focus problems.

Here's a KeePass build with uiAccess="true" (based on KeePass 2.60, I've added an application manifest using the latest version of Visual Studio 2022 and changed uiAccess from false to true; no other changes):
https://keepass.info/filepool/KeePass_260128_UIA.zip

When running this build from a non-secure directory, everything works as expected (without the ability to perform auto-type into high integrity applications). If you run it from %ProgramFiles%, auto-type works, but the focus problems occur. Examples:

• Run KeePass using Windows File Explorer (no need to open any database) and then click into the Windows File Explorer window. The expected behavior is that Windows File Explorer is brought to the foreground, which doesn't happen though; the KeePass window remains in the foreground (but without focus).
• While KeePass is running in the background (without being visible and without having the focus), switching between other applications via the taskbar sometimes works, sometimes not. This could indicate a bug in Windows.
• When clicking 'Tools' → 'Options', the options dialog drops behind the main window after half a second.

Without a solution (in KeePass or in Windows) for these problems, setting uiAccess="true" is unacceptable. I've tried adding some more elements in the application manifest, but this didn't have any effect on the problems.

If you or anyone else reading this has any idea how the focus problems could be resolved, please let me know.

Thanks and best regards,
Dominik

PS: If you run KeePass as administrator, performing auto-type into high integrity applications works fine and no focus problems occur.

[Koj]

This is not a Windows issue, the problem lies elsewhere.
I will try using a modified side-by-side manifest with KeePass. I'll let you know if I discover anything interesting.

However I've just created a test app (Delphi) that mimics KeePass, and it runs smoothly with UIAccess enabled.

This demo just sends 1234567890 to any window, including elevated ones.
https://www.swisstransfer.com/d/d4766634-500d-403d-9677-ff31281d7e51

ps: after running the modified KeePass, I had to reboot. The mess remains even after quitting it.

[Arthur]

Looks like UIAccess solved the issue with KeepassXC : https://github.com/keepassxreboot/keepassxc/issues/12956#issuecomment-3915677542

But as you said, secure location is required.

[Dominik Reichl]

Sure, setting uiAccess="true" does allow performing auto-type into applications running with a high integrity level. Like I wrote on 2026-01-28 already, this results in focus problems though, and I'm still experimenting with those.

Best regards,
Dominik

[Dominik Reichl]

I've narrowed down the problem in the meanwhile (or at least one of them). The focus issues occur when all of the following conditions are fulfilled:

1. The application sets uiAccess="true" in the manifest, is digitally signed and is started from a secure directory (e.g. in %ProgramFiles%).
2. The application has a TabControl and sets its ShowToolTips property to true.
3. The application sets the TopMost property of the Form to false.

Here's a small demo application (with source code):
https://keepass.info/filepool/Bug_260222_UIAccess.zip

The demo application is minimal in the sense that if any of the conditions (1. to 3.) is removed, the focus issues do not occur.

I've almost finished implementing workarounds in KeePass in order to avoid this problem and will probably provide a development snapshot for testing here in a few days, unless I encounter more such weird issues caused by UIAccess.

Best regards,
Dominik

[Dominik Reichl]

The workarounds for the problem that I mentioned before seem to be working fine, but unfortunately, setting uiAccess="true" results in more problems.

Here's the latest development snapshot with uiAccess="true":
https://keepass.info/filepool/KeePass_260224_UIAccess.zip

Most of the problems occur when the 'Always on Top' option is activated (which causes the TopMost property of forms to be set to true). For some, I can imagine workarounds (e.g. certain dialogs are displayed in wrong locations, but it's possible to resolve this). However, there also is a significant problem: when the 'Always on Top' option is active, certain controls (list views, combo boxes, buttons, ...) disappear. For example, controls disappear when they are on an inactive tab page and you call the Screen.FromControl method on them (which KeePass uses to get the size of the current monitor, in order to make sure that things fit onto it). Here's a small demo application (with source code):
https://keepass.info/filepool/Bug_260224_UIAccessScreen.zip
(must be started from a secure directory such as %ProgramFiles% in order to see the issue; each of the four tab pages should contain a control of the type mentioned in the tab header).

This isn't the only problem though. For example, buttons disappear when you try to assign a shield icon to them (BCM_SETSHIELD message).

I'll continue experimenting.

Best regards,
Dominik

[Dominik Reichl]

After implementing various workarounds, KeePass finally seems to run fine with UIAccess now.

If you have some free time, it would be great if you could test the latest development snapshot:
https://keepass.info/filepool/KeePass_260318.zip

For UIAccess, KeePass must be started from a secure directory (such as a folder in %ProgramFiles%). Whether it works can be seen by performing auto-type into a 'Windows Security' dialog of an up-to-date Windows 11 system. One way to display such a dialog is via the Control Panel of Windows → 'User Accounts' → 'Manage Web Credentials' → 'SnapshotEncryptionIV' → 'Show'. The development snapshot should be able to perform auto-type into this dialog even when running as standard user only (not as administrator, but from %ProgramFiles%).

While testing it, please especially watch out for focus issues (KeePass dialogs not getting the focus, appearing behind other windows, etc.), missing controls and data transfer issues (auto-type, drag&drop, ...). Most of the workarounds are enabled only when the 'Always on Top' option (in the main menu 'View') is activated (because most of the problems occur only when both UIAccess and 'Always on Top' are active, and the workarounds slow down KeePass slightly), thus it would be good to test KeePass in both modes.

Thanks and best regards,
Dominik

[Dominik Reichl]

A focus issue has been found in the trigger event/condition/action dialogs, for which I've implemented a workaround now.

Here's the latest development snapshot for testing:
https://keepass.info/filepool/KeePass_260325.zip

Thanks and best regards,
Dominik

[Dominik Reichl]

Unfortunately, it has turned out that in the case of KeePass, enabling UIAccess would be a security vulnerability: under certain circumstances, privilege escalation attacks would be possible (a malware running with standard user rights could run code with administrator rights).

Therefore, I've disabled UIAccess again (before releasing KeePass 2.61.1, i.e. there is no stable release with this vulnerability). I'm not planning to provide a variant of KeePass that has UIAccess enabled, and I'm also not planning to develop/promote a separate tool/plugin (e.g. a variant of KPLauncher [1]) that allows running KeePass with UIAccess (neither by me nor by other developers).

In order to make KeePass with UIAccess secure, various basic features (such as opening a database via the command line) would need to be removed or barred with confirmation dialogs, which is unacceptable.

For performing auto-type into a window that has a high UI privilege level, my recommendation continues to be to run KeePass as administrator (which does not allow such privilege escalation attacks) or to use a different data transfer method (clipboard, integration plugin, ...).
https://keepass.info/help/base/autotype.html#req

Best regards,
Dominik

[1] https://keepass.info/plugins.html#kplauncher

[Saiph]

Just this one feature request demonstrates the complexities of maintaining a Windows utility which has to interact with other applications.

Dominik, your detective work here is impressive. It must be a little frustrating when your work leads to a dead-end due to security vulnerabilities, as you've stated above.

I find that Keepass is probably the most valuable piece of software on my PC. It enables me to have different passwords for all my various online activities with my computer, and it enables me to use randomised non-English passwords to help prevent decryption and dictionary attacks.

Thank you so much for all your hard work, keeping us all much safer in the modern world.