Dell Client Platform BIOS contains a Weak Encoding for Password vulnerability

Dell's Client Platform BIOS stores the setup/admin password inside the DVAR region of the SPI flash chip using a repeating 20-byte XOR key applied to a 32-byte field. The first character is stored in the clear, and because the field is null-padded, any password shorter than 12 characters leaks the raw key bytes directly — anything XORed with zero is itself. Passwords longer than 12 chars require testing at most 256 candidate keys. The bug spans a broad set of models (Edge Gateway 3000/5000, Embedded PC 3000/5000, Precision 3630/3930, Latitude 3190/3310/7220/Rugged 5420/5424/7424, OptiPlex 7070 UFF, Precision 5540) plus the researcher-tested Latitude E7250/7490, XPS 15 9560, and Wyse 5070.

Dell's MEDIUM (5.7) rating with AV:P/AC:H is defensible and, if anything, slightly generous. The attack is AV:P — an attacker needs to pop the chassis, land an SPI flash clip on a Winbond/Macronix chip, and dump firmware. That is an evil-maid / lost-device / supply-chain-interception scenario, not something that scales across a 10,000-host estate over the network. The C:H/I:H component is real (BIOS admin password recovery kills pre-boot auth, Secure Boot policy, and unlocks storage on some configs), but the population of realistic attackers is small.

Why this verdict

• Physical access is a hard cap on scale. AV:P means an attacker must be in the room, with tools, with the device open, for every single target. There is no worm, no mass-exploitation path, no internet-reachable population — EPSS at 0.00119 reflects this reality.
• Friction audit — SPI clip and DVAR parsing. Even after physical access, the attacker needs an SPI programmer, must identify the flash chip package, dump firmware, and parse the DVAR record. That is trivial for a competent hardware-security researcher but non-trivial for opportunistic laptop thieves — the vast majority of stolen Dells never get their BIOS password extracted.
• Role multiplier: workstation / user laptop (typical role). Chain succeeds and yields the BIOS setup password. Blast radius = single device. Attacker can disable Secure Boot, boot attacker USB, and attempt to attack the OS. BitLocker with TPM+PIN neutralizes this outcome — the disk stays sealed. Without pre-boot PIN, storage disclosure is likely.
• Role multiplier: Edge Gateway / Embedded PC / Rugged Latitude in field deployments (typical role for these SKUs). Chain succeeds. Blast radius = the field device itself and potentially the OT/network segment it bridges. These devices are more likely to lack BitLocker and more likely to be physically accessible in remote/unattended locations — this is the population that deserves priority.
• Role multiplier: no high-value identity/hypervisor/PAM role. This is client-platform BIOS, not a server, hypervisor, DC, IdP, backup server, or CI/CD host. There is no fleet-scale pivot, no domain compromise path, no supply-chain multiplier. The high-value-role floor does not apply — this vuln does not live in a role-defining component.

Why not higher?

MEDIUM would require either a scalable attack vector (there isn't one — AV:P is definitional) or a role multiplier into identity/hypervisor/backup (this is client BIOS, not server or infrastructure). Physical-access flaws with AV:P/AC:H in the CVSS vector realistically live in the LOW-to-MEDIUM band, and the friction audit pushes this to the lower half.

Why not lower?

IGNORE is wrong because the confidentiality impact is real for field-deployed Edge Gateway / Rugged Latitude fleets where BitLocker+PIN is often absent, and because public MDSec research plus trivial exploit implementation will produce community tooling. For a security team handling lost/stolen laptop response and OT field devices, this is worth backlog attention, not zero attention.

1. Enforce BitLocker (or LUKS) with TPM+PIN on every affected client — Recovering the BIOS setup password does not unlock the disk if pre-boot authentication requires a user PIN in addition to the TPM seal. This is the single highest-value compensating control. Deploy across affected fleet within the noisgate mitigation window — since verdict is LOW there is no mitigation SLA, but treat as 365-day remediation hygiene.
2. Turn on chassis intrusion detection where supported — Precision, OptiPlex, and some Latitude models expose a chassis-intrusion event that surfaces to Dell Command | Monitor / WMI. Alert on it via your EDR or MDM. Won't stop the attack but shortens dwell time and gives you a signal on returned devices.
3. Set BIOS admin passwords ≥13 characters — The XOR-key leak collapses trivially for passwords ≤12 chars. At 13+ the attacker still recovers the password but must test 256 candidates — a marginal delay, but combined with rotation post-recovery it raises cost. Not a substitute for patching.
4. Prioritize BIOS updates on field-deployed Edge Gateway, Embedded PC, and Rugged Latitude SKUs first — These are the SKUs most likely to be physically accessible to attackers (unattended field sites, industrial floors, vehicles). Push DSA-2026-197 BIOS updates via Dell Command | Update or your existing firmware management pipeline. Verdict LOW means no mitigation SLA; use the noisgate remediation SLA of 365 days as your ceiling but move faster on OT/edge devices.
5. Update lost/stolen device runbook — Any Dell device on the affected list reported lost/stolen should trigger BIOS password rotation across shared administrative pools, not just AD account disablement. Update your IR playbook now.

Run on the target Dell client as Administrator to check installed BIOS version against the DSA-2026-197 fixed-version table. Invoke as: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-40639.ps1. Requires local admin for WMI access to Win32_BIOS.

#Requires -RunAsAdministrator
# Check-CVE-2026-40639.ps1
# Verifies Dell Client Platform BIOS against DSA-2026-197 fixed versions.
# Exit: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=NOT_AFFECTED_MODEL

$ErrorActionPreference = 'Stop'

$fixedVersions = @{
    'Edge Gateway 3000'      = '1.26.0'
    'Edge Gateway 5000'      = '1.36.0'
    'Embedded Box PC 3000'   = '1.32.0'
    'Embedded Box PC 5000'   = '1.33.0'
    'Precision 3630 Tower'   = '2.40.0'
    'Precision 3930 Rack'    = '2.43.0'
    'Latitude 3190'          = '1.44.0'
    'Latitude 3190 2-in-1'   = '1.44.0'
    'Latitude 3310'          = '1.33.0'
    'Latitude 3310 2-in-1'   = '1.32.0'
    'Latitude 7220 Rugged Extreme Tablet' = '1.51.0'
    'Latitude 5420 Rugged'   = '1.42.0'
    'Latitude 5424 Rugged'   = '1.42.0'
    'Latitude 7220EX Rugged Extreme Tablet' = '1.51.0'
    'Latitude 7424 Rugged Extreme' = '1.42.0'
    'OptiPlex 7070 Ultra'    = '1.36.1'
    'Precision 5540'         = '1.43.0'
}

try {
    $cs   = Get-CimInstance -ClassName Win32_ComputerSystem
    $bios = Get-CimInstance -ClassName Win32_BIOS
} catch {
    Write-Output 'UNKNOWN: WMI query failed'
    exit 2
}

$model  = $cs.Model.Trim()
$vendor = $cs.Manufacturer
$biosV  = $bios.SMBIOSBIOSVersion

if ($vendor -notmatch 'Dell') {
    Write-Output "NOT_AFFECTED_MODEL: vendor=$vendor"
    exit 3
}

$match = $null
foreach ($k in $fixedVersions.Keys) {
    if ($model -like "*$k*") { $match = $k; break }
}

if (-not $match) {
    Write-Output "UNKNOWN: model '$model' not in DSA-2026-197 table (may still be affected; check Dell advisory)"
    exit 2
}

$fixed = $fixedVersions[$match]
try {
    $installed = [Version]($biosV -replace '[^0-9\.].*$','')
    $required  = [Version]$fixed
} catch {
    Write-Output "UNKNOWN: cannot parse BIOS version '$biosV'"
    exit 2
}

if ($installed -ge $required) {
    Write-Output "PATCHED: $model BIOS $installed >= $required"
    exit 0
} else {
    Write-Output "VULNERABLE: $model BIOS $installed < $required (CVE-2026-40639)"
    exit 1
}

Sources

1. Dell DSA-2026-197 advisory
2. GBHackers technical write-up
3. CybersecurityNews — SPI flash recovery in milliseconds
4. Cyberpress coverage
5. CVEFeed entry
6. CWE-261: Weak Encoding for Password
7. MDSec research portal