What happened
On 21 August 2026 Electrum merged two small changes to the code that reads an extended key: one rejecting a private extended key whose key field does not begin with a zero byte (commit ea285d5e), the other rejecting a master key that carries a parent fingerprint or a child number (commit afb5c7ad). Both cases come straight out of BIP-32, whose fifth set of test vectors exists for exactly this purpose: "These vectors test that invalid extended keys are recognized as invalid."
What it changes
An extended key is 78 bytes wrapped in base58check, and the layout is fixed: four bytes of version, one of depth, four of parent fingerprint, four of child number, thirty-two of chain code, and thirty-three of key. In a private key those last thirty-three are a zero byte followed by the 32-byte secret. In a public one they are a compressed point, which starts with 0x02 or 0x03. Two of the fields are decided by construction rather than by choice: a master key has no parent, so its depth is zero and both its parent fingerprint and its child number must be zero too.
Electrum read the fields and did not check them. For a private key it took the last
thirty-two bytes of the record and used them as the secret, whatever the byte in front of them
said. The consequence is visible in the vector BIP-32 labels "prvkey version / pubkey
mismatch": its key field is a compressed public key, 0x03 followed by an x-coordinate, sitting
under an xprv header. Decode it and the old parser skips the 0x03, takes the 32 bytes after
it, and builds a wallet whose private key is a number published in the string itself. The two
other vectors in that group put 0x04 and 0x01 in the same position, and were read the same
way.
The master-key check is quieter and worth understanding. The
seed at the root of a wallet derives one extended key with no
parent, so the fingerprint and child number slots have nothing to describe. BIP-32's vectors
fill them with 0x01010101 and expect the key to be refused. A parser that accepts them lets
one key have many different strings that all decode to it: same chain code, same key material,
different text. Setting up a multisig means copying extended
keys between wallets as text, and wherever a comparison is made on that text, two spellings of
one key are two keys.
Neither check is new information. Both were written into the standard's own test list so that implementations could find out whether they agreed, which is the point of publishing invalid vectors alongside valid ones.
What it does not change
Nobody's coins were at risk while this was missing. You do not encounter a malformed extended key by using a wallet normally; you encounter one because something handed it to you, and the old behaviour turns a bad string into a wallet that appears to work rather than an error message. That is the failure this closes: garbage in, plausible wallet out.
It does not make the parser complete either. The two checks account for seven of the sixteen entries in BIP-32's invalid list: the three private keys with a wrong prefix byte and the four master keys carrying parent metadata. The other nine meet the length check, the base58 checksum, the version header or the key constructor instead. And none of it says anything about a key that is well formed and simply is not yours.
The new test for the private-key case is also thinner than it looks. It lists three vectors, but the first two string literals have no comma between them, so Python joins them into one 222-character string that fails on its checksum long before the new check is reached. Two of the three cases are exercised. The check itself covers all three.
And nothing installed carries it. Electrum's most recent release, 4.8.1, is from 10 August 2026, before both commits; these are on the development branch.
Context
Extended keys are the format every other piece of wallet plumbing moves around: descriptors, co-signer setup, a hardware wallet telling a laptop what it can watch. That is why the question of what a wallet accepts keeps coming back in small pieces. Core added an RPC for handing out an xpub at a chosen path this month, and a fix landed for a merge that could write the same xpub record twice in a partially signed transaction.
The pattern in all three is the same. The cryptography is not where the trouble is. The trouble is in the bookkeeping around the cryptography: which bytes mean what, which fields are allowed to vary, and whether two things that look the same are the same. The list of invalid keys was added to BIP-32 in a commit titled added invalid extended keys vectors, written in May 2020 and committed that November, and the strings in it have not changed since. Six years later they are still finding parsers.