AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
High 71 Bitcoin

wallet: encrypt the keystore before adding it to db

Public commit record

What the developer wrote

Authored by ThomasV

73/100 · Adequate
wallet: encrypt the keystore before adding it to db

adding keystore to db may result in a disk write, and we should
never write unencrypted keys to disk (except lightning_xprv)
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug where Electrum could write unencrypted private keys to disk while creating or restoring a wallet, even when the user asked for password protection. The change rearranges the wallet setup so that the keystore is encrypted before it is placed into the wallet database, and the database storage is encrypted before any writes happen. It also moves the address-import step to happen after the keystore is saved, reducing the chance of plaintext key material touching disk.

Recommended action

Users who created or restored password-protected Electrum wallets with versions prior to this fix should consider rotating any funds associated with those wallets and, if the wallet file may have been stored on shared or backed-up media, treat the file as potentially containing plaintext key material. Developers should verify that no other code paths persist a keystore before encryption is enabled, and review partial-write behavior of WalletStorage.

Security signals we found

01

Plaintext private key material could be written to persistent storage before encryption was applied

02

Wallet creation and restoration paths reordered to encrypt before database insertion

03

Imported private key path now encrypts keystore before adding derived addresses and saving

04

Assertion added that storage file does not exist too early during restore

05

Lightning xprv now derived with the user password instead of no password in create_new_wallet

Risk score

Why this scored 71/100

Our methodology →
Potential impact 22/30
Exploitability 15/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.