Bug Report: Chromium browsers hang on WebAuthn under containment on Windows 11 25H2
Summary
Chromium-based browsers (tested: Brave, Edge) hang with a black screen when any WebAuthn-enabled page attempts platform credential enumeration, when the browser is running under Comodo containment on Windows 11 25H2. Firefox under identical containment settings works correctly. The same Comodo configuration on Windows 10 works correctly with Chromium.
Environment
- OS: Windows 11 25H2 (Build 26200.8457)
- Comodo Internet Security: 12.3.4.8162 (Cruelsister config, HIPS disabled)
- Browsers tested:
- Brave (last several releases) — hangs ✗
- Microsoft Edge (last several releases) — hangs ✗
- Firefox (last several releases) — works ✓
- Reproduction URL: webauthn.io
- Same configuration on Windows 10 — Chromium works ✓
Containment levels tested
- Fully Virtualized (via Run Virtual shortcut) → hangs ✗
- Partially Limited (via manual Auto-Containment rule) → hangs ✗
- Limited → hangs ✗
- Untrusted → browser UI fails to paint (unusable) ✗
- No containment → works ✓
Symptoms
Browser window goes black and becomes unresponsive as soon as a WebAuthn-enabled login field is focused or credential enumeration is triggered. No credential UI appears. The hang occurs before any user interaction with an authenticator. Killing the browser process recovers it.
Diagnostic findings
Process Monitor captured the following call stack inside the browser process at the point of hang:
RegLoadAppKeyW
AppContainerDeriveSidFromMoniker
WebAuthNGetPlatformCredentialList
WebAuthNIsUserVerifyingPlatformAuthenticatorAvailable
The identical stack was captured in both Brave and Edge. The hang occurs inside webauthn.dll during platform credential enumeration, before any credential is returned or any UI is shown.
Analysis
Windows 11 25H2 routes WebAuthn platform credential enumeration through AppContainer-isolated registry hives (loaded via RegLoadAppKeyW) and a COM/RPC broker channel to the WebAuthn service hosted in svchost.exe. Comodo containment appears to intercept or block this cross-process COM/RPC call at all tested restriction levels, causing the browser thread to hang indefinitely waiting for a response that never arrives.
Firefox working under identical containment settings confirms this is specific to Chromium’s WebAuthn IPC implementation. Firefox does not use the same WebAuthNGetPlatformCredentialList / AppContainerDeriveSidFromMoniker call chain.
Windows 10 not exhibiting the issue confirms this is a regression introduced by changes to the Windows 11 WebAuthn/AppContainer stack.
The fact that the hang reproduces across all tested containment levels (Fully Virtualized, Partially Limited, Limited) rules out containment level as a workaround variable. Untrusted breaks browser UI rendering entirely, making it unusable as an alternative.
Request
Please investigate whether Comodo containment can be made to allow the WebAuthn COM/RPC broker channel (specifically the cross-process calls from a contained Chromium process to the Windows WebAuthn service in svchost.exe) without requiring HIPS to be enabled for a granular IPC rule.
Current workaround
Using contained Firefox for WebAuthn sites while keeping contained Chromium for general browsing.