Dell iDRAC9 Maser Update Weaknesses

Executive summary #

The iDRAC9 BMC serves the Lifecycle Controller/USC "maser" runtime to the host's UEFI environment. Several weaknesses in this runtime can undermine the transport and integrity checks for pre-boot updates: a conditional TLS certificate-verification bypass, acceptance of packages signed with a legacy 1024-bit DSA key, archive extraction vulnerable to path traversal, and update wrappers configured without maser-level signature verification. This vulnerability has an estimated CVSSv3.1 score of CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N (3.1, Low), and is an instance of CWE-295 (Improper Certificate Validation); CWE-347 (Improper Verification of Cryptographic Signature); CWE-1104 (Use of Unmaintained Third Party Components); CWE-327 (Use of a Broken or Risky Cryptographic Algorithm); and CWE-22 (Path Traversal).

Technical details #

The maser runtime is a set of x86-64 EDK2 modules the BMC serves to the host UEFI, from which the host runs the Lifecycle Controller / USC as privileged pre-OS code. Several weaknesses combine:

• The HTTP downloader (HttpApp.efi, ftp_proxy.efi) contains an explicit skipCertVerify branch, driven off a UEFI provisioning variable, plus "continuing anyway" log strings, so under some provisioning flows the downloader proceeds on a failed or absent TLS certificate check.
• It ships a stale (2017-era) Mozilla CA bundle that still trusts distrusted Symantec/VeriSign/thawte/GeoTrust and WoSign/StartCom roots, alongside outdated bundled components (libcurl 7.66, OpenSSL 1.1.1, Libgcrypt 1.8.5, Python 2).
• The package-signing keyring includes a DSA-1024 key created in 2001, below the modern floor, and any package signed by it is accepted.
• The Python 2 extract.py sanitizes tar entry names only with .lstrip('/'), leaving ../ parent-directory traversal sequences in place, so a crafted archive can write outside the target directory.
• Every <Wrapper> in the update table iuconfig.xml is marked digitalSignature="false", so the maser update engine performs no payload signature check itself and defers entirely to downstream FMP-capsule and device verification.

The wrapper and certificate-verification behavior is present in the BMC-served maser volumes:

grep -o 'digitalSignature="false"' maser/iuconfig.xml | sort -u
grep -R -a -E 'skipCertVerify|continuing anyway' maser/HttpApp.efi maser/ftp_proxy.efi

digitalSignature="false"
maser/HttpApp.efi:skipCertVerify is set..
maser/ftp_proxy.efi:error setting certificate verify locations, continuing anyway:
maser/ftp_proxy.efi:SSL certificate verify result: %s (%ld), continuing anyway.

Attacker value #

An attacker on the path of Lifecycle Controller update traffic could, when the certificate-verification bypass is active, substitute content without presenting a trusted server certificate. Because maser does not verify wrapper signatures, that content may proceed to downstream component checks; a crafted archive could also exploit the extraction traversal to write outside its intended directory. If downstream firmware checks do not reject the altered content, this chain could affect code run by the host before the operating system starts. A compromised BMC can also alter the runtime it serves to the host.

Credit #

This issue was discovered by HD Moore with the help of AI tools. Disclosure was coordinated by Tod Beardsley.

Timeline #

• 2026-07-16 (Thu): Initial findings discovered and documented
• 2026-07-21 (Tue): CVE-2026-65186 reserved
• 2026-08-27 (Thu): Vendor notified
• 2026-08-31 (Mon): Vendor acknowledged receipt, reserved CVE transferred
• 2026-10-26 (Mon): This public disclosure