Dell BIOS Passwords: Weak XOR Encryption Allows Recovery from SPI Flash (CVE-2026-40639) Darren McDonald | 10 July 2026 Craig S. Blackie (MDSec) and Darren McDonald (AmberWolf) | 10 July 2026 A joint discovery, published in parallel on the AmberWolf and MDSec blogs. Summary Dell stores its BIOS administrator and user passwords as XOR-encrypted plaintext in the DVAR (Dell Variable) region of the SPI flash chip, not as a one-way hash. The scheme encrypts a 32-byte password field with a 20-byte key, and the first character is not encrypted at all. For any password up to 12 characters, the unused tail of the field leaks the entire key, so the password can be recovered directly from a flash dump with no brute force and no known plaintext. Longer passwords leave a small blind zone in a single record, which a quirk of the key derivation then closes (more below). Recovery is deterministic and completes in milliseconds. An attacker who can read the SPI flash, which is possible with a clip and a cheap programmer or by booting an operating system they control, can recover the password and gain full BIOS access. We found this jointly by chance while working on something entirely different. The affected scheme is used across a range of older Dell platforms, a large number of which are now near or past end of support, whereas newer platforms have moved to a more secure password-protection mechanism. It is not, however, limited to legacy hardware: it is confirmed on the current-generation Wyse 5070 thin client, which remains supported and unpatched, and it is implemented in the SystemPwSmm SMM driver common to Dell client platforms. Dell tracks it as CVE-2026-40639 (DSA-2026-197). Introduction A BIOS administrator password is supposed to be a meaningful control. It stops someone changing the boot order, disabling Secure Boot, or booting from removable media, which on a well-configured machine is the last line of defence against an attacker with physical access. It is worth recognising up front that there are already well-known ways to bypass or remove a configured Dell BIOS password. Master passwords can be derived using services such as bios-pw.org. Another method involves modifying the BIOS flash to put the device into manufacturing mode, which preserves the settings but lets you set the service and asset tag while removing any password. And in many cases you can simply clear the entirety of NVRAM, reflash the firmware, and remove all settings, including the password, entirely. What is less widely appreciated is that the way certain Dell systems store the password allows recovery of the original clear text password, not just its removal, under the conditions described below. We did not set out to attack that password at all, and this did not begin as a planned research project. It started as two old friends having fun with chip programmers. We had been reproducing existing public research on pre-boot DMA attacks, demonstrated against an HP machine, and were curious whether the same class of weakness applied to Dell UEFI. Answering that meant understanding how Dell stores its BIOS settings on the SPI flash, which we worked out the direct way, by changing a setting, reading the chip back with a clip and a programmer, and seeing which bytes moved. The password was just one of the settings we poked at, and our interest in it was mundane: we wanted to find where it lived so we could try to zero it out and clear it. What we found instead was the password sitting in the flash under a broken XOR cipher, with the key leaking out right next to it. This post explains how the scheme works, why it fails, and how to recover the password from a flash dump, so that other researchers and the administrators running these devices can understand their exposure. The find was joint, and this article appears on both the AmberWolf and MDSec blogs. Finding the vulnerability Getting at that pre-boot DMA question meant first understanding how Dell keeps its BIOS configuration on the SPI flash, so we set about mapping it empirically: change one setting in the BIOS, read the whole flash back over a SOIC clip with a T48 programmer, and diff against the previous read to see which bytes moved. A SOIC-8 clip on the BIOS flash chip, connected to a T48 programmer. This is the whole hardware requirement: no soldering, no board removal. The BIOS password was one of the settings we exercised this way, and our goal with it was not to read it but to delete it. If we could find the exact region that held the password, we could try to zero it out and clear the password entirely, which is a perfectly good physical-access bypass in its own right. So we changed the password, dumped, diffed, and watched where the flash changed. What stood out was that the password region did not simply overwrite in place. New records were being appended each time, which is the log-structured behaviour of Dell’s DVAR store. It was while staring at those records that we realised what we were actually looking at, helped considerably by the password we had set: AAAAAAAA. A single repeated character made it relatively easy to spot. The short password leaves most of the 32-byte record as encrypted null-padding, which is just the key in the clear; the constant plaintext makes the remaining characters fall out by inspection; and the 20-byte key even repeats visibly within the record. The pattern was impossible to miss. The password was not hashed. It was XOR-encrypted, with the key sitting in the same record right next to the ciphertext. A cipher that leaks its own key. We then pulled the relevant SMM driver, SystemPwSmm, into Ghidra to confirm the mechanism. This showed the password is stored more or less as typed, and the routine that writes it skips the very first byte. From there it was just a matter of reading the key out and XORing the password back. How Dell stores the BIOS password Dell BIOS passwords live in the DVAR store, a proprietary variable region on the SPI flash that the recovery tool locates automatically by its four-byte DVAR signature. Each password is held in a 32-byte record with a very simple structure. Byte 0: First character of the password, stored UNENCRYPTED Bytes 1-31: Remaining characters, XOR-encrypted with a 20-byte key Any unused trailing bytes are null-padded before encryption The encryption is a repeating-key XOR: stored [ i ] = password [ i ] XOR key [( i - 1 ) mod 20 ] for i = 1..31 The password field is null-padded out to 32 bytes. For a password of length L, positions 0 to L-1 hold the characters (position 0 in the clear, positions 1 onward encrypted), and positions L to 31 hold null bytes that are then XOR-encrypted along with everything else. Storing the password under reversible encryption rather than a hash is already the wrong choice. Verifying a password never requires recovering it, so there is no good reason for the firmware to be able to turn the stored value back into the original. But the specific way the encryption is implemented turns “wrong choice” into “trivially recoverable”. The XOR scheme and why it fails The key is 20 bytes. The field it encrypts is 32 bytes. That 12-byte mismatch is the whole vulnerability. Anything XORed with zero is itself. When the firmware encrypts the null-padding that follows a short password, each of those null bytes turns into a raw key byte in the stored record: stored [ L ] = 0x00 XOR key [( L-1 ) mod 20 ] = key [( L-1 ) mod 20 ] stored [ L+1 ] = 0x00 XOR key [ L mod 20 ] = key [ L mod 20 ] ... stored [ 31 ] = 0x00 XOR key [ 30 mod 20 ] = key [ 10 ] For an eight-character password, a common case, positions 8 to 31 are null-padding. That is 24 bytes of raw key material in a record protected by a key only 20 bytes long. The entire key is sitting in the stored record. There is no brute force, no known plaintext, and no side channel. You read the key straight out of the tail of the record and XOR the password back. A worked example makes it concrete. This is the stored record for the password “password”, taken straight from an E7250 dump: Stored: 70 14 92 c2 4d 1d 76 50 56 19 3a 1f 3a 2a 8a 18 78 3a a3 cf fb 75 e1 b1 3a 72 04 34 56 19 3a 1f Key: 75 e1 b1 3a 72 04 34 56 19 3a 1f 3a 2a 8a 18 78 3a a3 cf fb The first stored byte, 0x70, is the letter “p” in the clear. The password is eight characters, so bytes 21 to 31 of the stored record are the null region, and they hand us key bytes 0 to 10 directly: 75 e1 b1 3a 72 04 34 56 19 3a 1f. Key bytes 11 to 19 come from positions 12 to 20, which are the tail null bytes for this length. With the full 20-byte key in hand, the rest of the password falls out one XOR at a time: stored [ 1 ] XOR key [ 0 ] = 0x14 XOR 0x75 = 0x61 = 'a' stored [ 2 ] XOR key [ 1 ] = 0x92 XOR 0xe1 = 0x73 = 's' stored [ 3 ] XOR key [ 2 ] = 0xc2 XOR 0xb1 = 0x73 = 's' stored [ 4 ] XOR key [ 3 ] = 0x4d XOR 0x3a = 0x77 = 'w' stored [ 5 ] XOR key [ 4 ] = 0x1d XOR 0x72 = 0x6f = 'o' stored [ 6 ] XOR key [ 5 ] = 0x76 XOR 0x04 = 0x72 = 'r' stored [ 7 ] XOR key [ 6 ] = 0x50 XOR 0x34 = 0x64 = 'd' “password”, recovered exactly, from the stored record alone. Recovery degrades gracefully with length. The table below shows what is recoverable. Table 1: recoverability by password length Password length Key bytes leaked Outcome 1 to 12 characters All 20, from the null region Instant, exact recovery 13 to 31 characters Partial; key bytes 11 to 19 are each used at one position only, which now falls in the password rather than the null pad A blind zone of 1 to 9 characters in the middle, unless the key is recovered another way (see below) 32 characters Full field, no null padding Recoverable when the password is a single repeated character; otherwise partial The cutoff is 12 because key bytes 11 to 19 are each used at only one position in the record (positions 12 to 20). They leak only while that position is still null padding, which holds up to a 12-character password. Plenty of real BIOS passwords are that short, so