Question CyberLock: How to exclude Bitwarden's Browser Extension "desktop_proxy.exe" from VoodooAI prompts in Brave?

[acyclovir]

Hi everyone, Hi (@danb)

I'm experiencing persistent VoodooAI "Allow/Deny" prompts for desktop_proxy.exe every time I launch Brave Browser. This executable is the Native Messaging host for the Bitwarden extension.
I have already taken the following steps to stop the prompts, but they haven't worked:

1. Whitelist: I have already marked desktop_proxy.exe as "Allow" in the Whitelist/Application Control list.
2. VoodooAI Rule: I created a rule: Allow items in the folder BITWARDEN when CyberLock is ON, OFF, or AUTOPILOT, if VoodooAI is less than or equal to 6

Despite these settings, VodooAI continues to prompt for action on every browser start.

Is there a way to globally trust this specific interaction between Brave and Bitwarden? Or is there a specific "Parent/Child" process rule I should be looking at to stop VoodooAI from re-evaluating this file?

Thanks for your help!

 

[Bot]

Hi everyone, Hi (@danb)

I'm experiencing persistent VoodooAI "Allow/Deny" prompts for desktop_proxy.exe every time I launch Brave Browser. This executable is the Native Messaging host for the Bitwarden extension.
I have already taken the following steps to stop the prompts, but they haven't worked:

1. Whitelist: I have already marked desktop_proxy.exe as "Allow" in the Whitelist/Application Control list.
2. VoodooAI Rule: I created a rule: Allow items in the folder BITWARDEN when CyberLock is ON, OFF, or AUTOPILOT, if VoodooAI is less than or equal to 6

View attachment 295300

Despite these settings, VodooAI continues to prompt for action on every browser start.

Is there a way to globally trust this specific interaction between Brave and Bitwarden? Or is there a specific "Parent/Child" process rule I should be looking at to stop VoodooAI from re-evaluating this file?

Thanks for your help!

This behavior is usually caused by VoodooShield/CyberLock not “binding” your allow decision to the exact instance that is being launched (most commonly because the path changes between launches/updates, or because VS is evaluating the Brave → native-messaging chain rather than only the file itself).

What to check first (quick, low-risk)

• Verify the exact path in the prompt matches the one you whitelisted/rule-targeted. With Bitwarden, the native host is sometimes installed under a versioned subfolder (common with Electron apps), so after an update you may end up with something like …\app-XXXX\desktop_proxy.exe, which looks “new” to the rule if your rule points to a different folder level.
• Verify the digital signature shown in the prompt details. Ideally it should be signed by Bitwarden (publisher/certificate). If it’s unsigned or sitting in an unusual user-writable location (Temp, Downloads, random AppData subfolder), don’t globally trust it—reinstall Bitwarden from the official source and re-check.

Most reliable fix: trust by signer/publisher (handles updates)
If VoodooShield/CyberLock supports it in your build, the cleanest way to stop repeat prompts for an app that may update/move is:

• Create an allow rule based on the signing certificate / publisher (e.g., “Allow files signed by Bitwarden…”), rather than only by filename/path.
• Alternatively, add Bitwarden to a Trusted Publishers-style list (if available) so new signed builds don’t get re-evaluated each time.

This avoids the “new path/new hash after update = new prompt” loop.

If it’s really about the interaction: parent/child (Brave → desktop_proxy.exe)
In some configurations the prompt keeps returning because the policy is applied to the process relationship (browser spawning a helper) rather than the binary alone. If your prompt dialog offers options like “always allow this from this parent” (wording varies), use a rule that effectively means:

• Allow desktop_proxy.exe
• Only when spawned by brave.exe (and optionally only from the expected Bitwarden install folder)

That is safer than a blanket “allow anywhere” rule and typically stops re-prompts on each browser start.

If it still prompts: common gotchas

• Multiple copies of desktop_proxy.exe: One from the Bitwarden Desktop install and another from a different install context (per-user vs per-machine) can cause repeated prompts. Only one is whitelisted, but Brave calls the other.
• Rule scope mismatch: Folder rule not including subfolders, or pointing at a “BITWARDEN” folder name that isn’t the one actually used on disk.
• Cache/state issue: Some builds keep a decision cache separately from the whitelist entry. A “reset decisions / rebuild whitelist” type option (if present) can help after you correct the path/signer rule.

Safe verification step (recommended before globally trusting)
If you haven’t already, calculate the file hash (SHA-256) for the exact desktop_proxy.exe that is being prompted, and submit it to VirusTotal for a second opinion. Don’t assume it’s good purely because the name matches; confirm it’s the expected signed Bitwarden component.

Next step
If you can post (from the prompt details) the full file path, signer/publisher, and the parent process shown (Brave or something else), other members can tell you which rule type (path vs signer vs parent/child) will actually stick in your specific setup.

 

[acyclovir]

Technical Details from Logs:​

• Full File Path: c:\users\mamgm\appdata\local\programs\bitwarden\desktop_proxy.exe
• Signer / Publisher: NONE (The file is NOT digitally signed).
  
  
  
  
  
• Parent Process: c:\program files\bravesoftware\brave-browser\application\brave.exe
• File Rating: Safe (Score 1)
• CyberLock Status: User Allowed

Steps Taken (Failed to stop the prompts):​

1. Whitelisting: The file is already marked as "User Allowed" in the File List.

The Issue:​

Even with these rules, CyberLock shows the "Safe" prompt on every launch. Since the file is unsigned and resides in AppData, VoodooAI seems to override my manual "Allow" decision because of the Brave ->; CMD ->; Proxy execution chain.

How can I permanently trust this unsigned binary or this specific parent/child relationship so VoodooAI stops re-evaluating it? desktop_proxy.exe file is essential for the "Unlock with Windows Hello" feature from browser extension in Bitwarden, the Windows Store version is not an option as it lacks this specific functionality

Thanks in advance

 

[danb]

Thank you for letting me know!

A couple of things... the CyberLock Settings almost never need to be changed from the default settings, so if you have changed any setting from the default, please change them back to the default setting and it will probably work properly. Also, new rules almost never need to be created.

Can you please email the following log to support at cyberlock.globa? C:\ProgramData\CyberLock\DeveloperLog.log

I have tried to reproduce the block by installing the Bitwarden desktop app and the Brave extension, but so far I have not been able to reproduce the block. If the above suggestions do not work, can you please list the steps to reproduce the block so I can invstigate?

Thank you!

 

[acyclovir]

Hi Dan,

Thanks for the follow-up! I have just sent the DeveloperLog.log to the support email.

Regarding the reproduction of the block, the key is the "Unlock with Windows Hello" feature. You likely couldn't reproduce it because this specific integration is only available in the standard desktop installer from the Bitwarden website; the Windows Store version does not support Windows Hello for browser extensions.

Steps to reproduce:

1. Install the Bitwarden Desktop App using the web installer (not the Windows Store version).
2. In the Desktop App settings, enable "Unlock with Windows Hello" and "Allow browser integration."
3. In the Brave extension settings, enable "Unlock with Windows Hello."
4. Close Brave completely and relaunch it.

Every time the browser starts, the extension attempts to validate the session with the desktop app via desktop_proxy.exe. This is the exact moment VoodooAI triggers the "Safe" prompt, even when the file is already in the "User Allowed" list.

I will follow your advice and revert my settings to default to see if that changes the behavior while you review the logs.

Best regards!

 

[danb]

Very cool, thank you for the log... that helps a lot! Yeah, I was using Copilot to help me reproduce the block and it told me to install the web installer, so that is what I did. I think the reason I cannot reproduce the block is because I am using a VM and Windows Hello is not available... just a guess.

But this is kind of a fun one... we have not had a block like this in 4-5 years, so this will be fun to figure out.

If setting to all defaults does not fix the block, please send me this file and it should tell us why it is being blocked: C:\ProgramData\CyberLock\whitelist.db

Thank you!

 

[acyclovir]

I have tried reverting all CyberLock settings to their defaults as you suggested, but unfortunately, the issue persists. VoodooAI still triggers the "Safe" prompt for desktop_proxy.exe every time I launch Brave.

I have already emailed the whitelist.db file to your support address. I'm glad to hear this is an interesting case!

Thanks!

 

[danb]

Sounds great, thank you. One other thing you might try is in CyberLock settings, go to the Whitelist tab and in the search bar at the top, enter: desktop_proxy, then delete any entries that are listed. Then reproduce the block again, and you will need to click Allow, hopefully one last time, and then hopefully the block will be resolved. I am not sure if this will fix it or not, but it is worth a try.

If that does not work, we have to somehow figure out how to reproduce this block on our end, then it will be a super simple fix. So if the above fix does not help, if you can think of any way I can manually trigger desktop_proxy, that would be cool. I am just not at all familiar with Bitwarden, so it is hard for me to figure out how to trigger desktop_proxy. Thank you!

 

[acyclovir]

I gave your suggestion a try, deleted all desktop_proxy entries from the Whitelist tab and reproduced the block to click "Allow" again. Unfortunately, it didn't do the trick; the VoodooAI prompt continues to appear on every launch.

 

[danb]

Very cool, I am able to reproduce the block now, and I have identified the issue. The issue is that when desktop_proxy.exe is spawned by Brave, the digital signature somehow magically disappears, and your prompt above confirms this. But when I scan desktop_proxy.exe manually, there is not an issue getting the digital signature, so there must be some kind of protection mechanism that is blocking another process from reading the digital signature of the desktop_proxy.exe file. This is very odd, and something we have never seen before. There are several ways to fix this, but we first need to figure out why we are not able to get the digital signature of the desktop_proxy.exe file, so I will email Bitwarden and see what they say. We could fix this in a different way, but since we have never seen anything like this, I think this is the best place to start.

The great news is that CyberLock is working exactly how it is supposed to be working. In other words, since it was not able to verify the signature of a whitelisted child process, it blocked it.

Thanks again for finding this, it is extremely interesting!

 

[danb]

Thanks again for reporting this issue, it should be fixed in the 8.48 version below

It turns out this was a bug from some experimental code I added about 8 months ago, and I even commented in the code that I was not sure if it was a good idea or not. Looking back, I can see why I was undecided on these 2 lines of code, but now it is crystal clear, and the good news is that it is a small bug that only appears in extreme edge cases, so we are good to go.

CyberLock 8.48

https://www.cyberlock.global/downloads/InstallCyberLock848.exe

SHA-256: b1aac91a9e05fa79ff1e0b575a14b3163793bea425ce51a3c34dc3566599b67e

 

[acyclovir]

Confirmed! The persistent VoodooAI prompt for desktop_proxy.exe has finally disappeared when I launch Brave.

It’s a relief to have the Bitwarden "Windows Hello" integration working smoothly again without manual interruptions. I really appreciate your effort,

Thanks!