Brave update wiped all passwords, history and settings – no warning, locked out of accounts

Browser Support
, ,
1

After updating Brave on Windows 10, all my saved passwords, browsing history and settings disappeared.

The update was downloaded automatically without my consent and applied through the browser interface.
After restarting (following hibernation), Brave created a new profile and encryption key. As a result, my existing data (including the “Login Data” file) is no longer accessible.
There was absolutely no warning that such data loss could occur.
From a user perspective, this is critical:
I am effectively locked out of multiple accounts
Including banking access
All locally stored credentials became unusable overnight
This is not acceptable behavior for a browser that stores sensitive user data.
:red_exclamation_mark: Questions:
Is there any official way to recover passwords if the Local State encryption key has been replaced?
Why does Brave not warn users that automatic updates may invalidate stored credentials?
How can automatic updates be permanently disabled on Windows?
:warning: Additional context:
The data was present and working immediately after the update
It disappeared only after resuming from hibernation
No manual deletion or antivirus action was performed
:red_circle: Conclusion:
Users should not lose access to their own data without warning or recovery options.
This behavior severely undermines trust in the browser.

2

@KK16

Hard lesson that reminds us to back up our user data. My consolidated notes re data loss that include info re maintaining data backups:

‘Brave deleted all my active tabs and favorites - #2 by 289wk’

Note to self: I have suspected that one of the contributing factors, is in the category of > hibernation / low power energy saving settings / sleep:

“After restarting (following hibernation)”

3

Yes, I agree backups are important.

However, this is not just about backups.

The data was working AFTER the update and only disappeared after resuming from hibernation.

This suggests a corruption or key mismatch issue, not user error.

Users should not lose access to their data due to normal system behavior like hibernation.

4

@Mattches

OP: “The data was working AFTER the update and only disappeared after resuming from hibernation”

Brave Browser is placing some info (hereafter, I use “the info”) in cache and/or memory, that Windows over-writes … during:

  • application restart
  • application coming out of hibernation/sleep
  • computer restart

because of where Windows does not expect the browser’s info (the info) to be stored.

The browser, on the other hand, is suspicious because of the loss of the info, and therefore falls back on some routine that substitutes a partially (aka somewhat) restored local state.

Is my guess. Windows, doing its thing, before Brave gets the chance to retrieve the info.

Re “where Windows does not expect the browser’s info (the info) to be stored” ← Windows might perceive something (compositing + GPU) about the browser is “gaming” … and mistakenly “thinks” the info is stored accordingly by the application (browser in this case), and Windows does not expect the info to be stored where the application actually did ← Windows thus over-writing that spot … sometimes, happens by chance of what Windows “thinks” is available space.

Is my present theory.

Updated note to self - because of a parallel:

  • GPU loss race case: Windows reclaims VRAM before Brave flushes → state corruption.
  • DPAPI race case: Windows VaultSvc isn’t ready before Brave decrypts → key mismatch.

During suspend / resume or hibernation sequences, Windows may briefly desynchronize its GPU memory context and its user‑scope encryption service (VaultSvc).

Brave can encounter two separate timing races - one in graphics resources and another in DPAPI initialization (generic Chromium + Windows timing flaw) - leading to the same outcome: partial or total loss of user state.

Three tables follow:

Consider Both 'GPU loss race' and 'DPAPI race':
Race Category Trigger Condition Resulting Symptom Common Thread
GPU loss race Windows resumes or re‑binds VRAM mid‑frame; Brave hasn’t flushed compositions File corruption / partially restored Local State or Preferences OS resets resource before Brave releases it
DPAPI race Brave requests VaultSvc before DPAPI ready Decryption fail → fallback Local State key → password loss App requests service before OS initializes it
Mitigations Brave might consider re 'GPU loss race':
Layer Protective Mechanism Benefit Cost
GPU Broker Keep rendering buffers in shared system RAM until final commit Survives device loss without data loss Slight CPU copy overhead (≈ 2-5 %)
State Shadow Daemon Writes micro‑dumps of Preferences + Local State every ≤ 30 s when GPU busy No catastrophic profile resets Small SSD wear / IO load
Loss Detector Thread Watches DeviceRemoved / DXGI_ERROR_DEVICE_RESET events and triggers immediate state flush Flushes before Windows reclaims VRAM Minor background CPU
Fast Rehydrate Path On restart, rebuilds compositor from shadow buffers in RAM or last micro‑dump Instant visual recovery Slight RAM use
Mitigations Brave might consider re 'DPAPI race':
Layer Fix Benefit Cost
Startup ordering Delay DPAPI init until VaultSvc ready (poll “CryptAcquireContext” success) Eliminates race entirely Adds ~1 s startup delay
Retry logic On decrypt fail, wait 2 s then retry once before regenerating Local State Prevents false “new‑key” generation Minimal
Persistent sym‑key cache Keep a user‑encrypted backup of the DPAPI key under Default\User Data\Backups Recovery without total lockout Slight security trade‑off

(And, I have to repeat to myself: DPAPI - “Data Protection Application Programming Interface”)

5

It’s probably not cache-related.

The Login Data is still present, which suggests the issue is not data loss but decryption failure.

Most likely the encryption key (Local State / Windows DPAPI) becomes invalid or mismatched after hibernation, so Brave cannot access existing credentials and falls back to a reset.

This would explain why everything worked before hibernation and broke immediately after resume.

6

Taking a look here – @KK16 can you confirm that it was only the password data that got cleared out? Everything else – bookmarks, favorites, history, etc. are still present?

7

No, it’s not only passwords.

Passwords are gone.
Browsing history is also gone.

Everything was working after the update, and the issue appeared only after resuming from hibernation.

Login Data file still exists, but Brave cannot access it.

This looks like a profile reset or encryption key mismatch, not just a password manager issue.

8

I personally agree with you. That would be considered unstable by modern development standards. I do have suggestions to apply in the future.

1. Use a password manager extension, rather than the built-in password manager.

2. Use sync, if possible, even if you only have Brave on one device.

3. Use bookmarks as much as possible, and save bookmarks daily (or whenever you add one) to a folder.

4. Additionally, using cloud storage or an external hard drive for saving bookmark files can also help if your device fails.

9

That’s basically the conclusion I’ve come to, but here’s the kicker, it’s not Brave specific. It’s a bug in Chromium, and it’s a race condition between VaultSvc being ready in time. It affects Chrome, and Edge as well.

I’m just a user and have not personally run into this in that I lost my data, but I have lost Sync and had to set it up, and this post-Windows update I think (because I honestly don’t know when sync stopped for me).

It stinks, I know, and I hate it too. But it’s Chromium side, and until someone finds the root cause, there’s no way to even suggest a fix yet.

10

I understand and agree with these suggestions.

However, the main issue here is not about best practices or future prevention.

The problem is that data was working normally after the update and became inaccessible only after resuming from hibernation.

This indicates a failure in how Brave handles profile/encryption state, not user behavior.

Is there any explanation or fix for this specific scenario?

11

This makes a lot of sense.

Given that everything was working before hibernation and broke immediately after resume, a race condition with DPAPI/VaultSvc seems very likely.

However, this raises a serious concern:

Why does Brave reset access to user data instead of retrying when the encryption service becomes available?

This behavior leads to irreversible data loss for the user.

Is there any plan to handle this scenario more safely (e.g. delayed retry instead of immediate reset)?

12

Again it’s Chromium, and it’s important we as users understand that, or we do not understand the product we are using.

Chromium does this because if no valid key can decrypt, it generates a new key, forgets the old one, and somehow Login Data technically remains with old encrypted data.

The only thing I haven’t recommended yet, merely because the last time I used it on Windows ME and XP was, it didn’t work in this regard, but System Restore might be an option.

But in general with most cryptography, if the key is ever corrupt, a new one is always generated, and it stinks.

Again though, we need to be asking Chromium this, not Brave.

This involves knowing what the root cause even is, something seemingly challenging to find. Because of two things:

  1. Most devs, including users never encounter it.
  2. Once encountered, there’s almost nothing left to check, the old key is gone.

What is suspected is that Chromium is checking for VaultSvc far too early because Windows does NOT leave VaultSvc loaded in RAM for obvious security reasons, but everytime Chromium based browsers start, it needs VaultSvc to decrypt, and Chromium just doesn’t seem to want to wait, yet it’s designed TO wait. That’s why no fix or workaround has been produced. It is NOT easy to even figure out where to start if we have no access to test machines.

Shoot, I’m just a user like you, and I have 3 VM’s, an Ubuntu VM, Windows 10 and Windows 11. I’ve been trying for months to trigger this.