The IPMI 2

CVE-2013-4786 is a design flaw baked into the IPMI 2.0 specification itself — not a vendor implementation bug. During the RMCP+ Authenticated Key-Exchange Protocol (RAKP) handshake, the Baseboard Management Controller (BMC) returns an HMAC-SHA1 (or HMAC-MD5) value derived from the target account's password in RAKP Message 2, before the requester has authenticated. Any unauthenticated party that can reach UDP port 623 can request this hash for any valid username — ADMIN, root, Administrator — and crack it offline with hashcat mode 7300 or John the Ripper. Every IPMI 2.0 implementation from every vendor — Supermicro, HPE iLO, Dell iDRAC, Lenovo XClarity, IBM IMM, Oracle ILOM, Fujitsu iRMC — is affected. There is no version range to cite because the flaw IS the specification; all firmware versions implementing IPMI 2.0 are permanently vulnerable.

The vendor severity of HIGH (7.5) is an undercount. That score rates only the confidentiality impact of hash disclosure (C:H/I:N/A:N) in isolation, ignoring the downstream blast radius when the hash is cracked. BMCs are not application servers — they are the hardware management plane for every physical server in a data center, including domain controllers, hypervisors, and backup infrastructure. A cracked BMC password yields KVM/SOL console access, BIOS/firmware modification, and a lateral-movement beachhead across the entire out-of-band management network. Factory default passwords on HPE iLO crack in ~32 seconds with 8 GPUs; Supermicro defaults fall in ~1 hour. July 2026 research by Lava Security found 24,650 internet-exposed BMCs actively returning hashes, with over 30% crackable via common wordlists. The JungleSec ransomware campaign and the iLOBleed firmware rootkit both demonstrate that this theoretical chain collapses into reality. The specification will never be patched. This is CRITICAL.

Why this verdict

• Specification-level, permanently unfixable flaw: Unlike implementation bugs, this vulnerability exists in the IPMI 2.0 spec itself. No vendor can issue a patch. Every IPMI 2.0 device deployed today, tomorrow, and until IPMI 2.0 is retired is vulnerable. This permanently shifts risk upward from a typical HIGH.
• Unauthenticated, remote, zero-interaction attack: The CVSS vector (AV:N/AC:L/PR:N/UI:N) is accurate — any party that can send a UDP packet to port 623 can extract password hashes. There is no prerequisite compromise, no phishing, no user click. On internet-exposed BMCs, the attack is fully remote. On internal networks, any host with management VLAN access can execute it.
• Mature, weaponized tooling with trivial operational cost: Metasploit's ipmi_dumphashes has been shipping since 2013. CosmicRakp enables concurrent scanning of entire IP ranges. Hashcat mode 7300 cracks factory-default HPE iLO passwords in 32 seconds. The entire chain from discovery to BMC login can be completed in under 5 minutes against a factory-configured target.
• Role multiplier: BMCs ARE the canonical high-value-role component. A BMC manages the physical server. That server may be (a) a workstation (low value), (b) an app server (medium), or (c) a domain controller, ESXi hypervisor, Veeam backup server, or SIEM collector (fleet-scale blast radius). Over 50% of internet-exposed BMCs are Supermicro, predominantly deployed in data centers hosting production infrastructure. BMC compromise on a domain controller = domain takeover. On a hypervisor = control of all guest VMs. On a backup server = ransomware operators delete recovery capability. The blast radius in high-value roles is fleet-scale to domain-scale, and ≥10% of BMC installs by definition manage high-value servers — the CRITICAL floor applies.
• Active exploitation in real campaigns: JungleSec ransomware (2018) targeted IPMI-exposed servers with default credentials. The iLOBleed rootkit (2021) demonstrated firmware-persistent implants via BMC access. Lava Security (July 2026) observed a live ransom note on an exposed iLO interface. This is not theoretical.
• Massive current exposure surface: 24,650 BMCs actively returning hashes to unauthenticated requesters as of July 2026, with ~60 new ones appearing daily. Over 30% of harvested hashes are crackable with public wordlists and known factory-default formats.

Why not higher?

The score of 9.0 (rather than 10.0) reflects that the CVE itself is an information-disclosure primitive, not direct code execution. The full compromise chain requires an additional offline cracking step that strong, unique passwords can resist. Organizations with robust BMC password policies and proper management-network isolation can meaningfully reduce their exposure, preventing this from being a guaranteed automatic compromise.

Why not lower?

This cannot be rated below CRITICAL because BMCs are a canonical high-value-role component (the management plane for domain controllers, hypervisors, backup servers) where successful exploitation yields fleet-scale compromise. The flaw is permanently unfixable, exploitation tooling is mature and free, and real-world ransomware campaigns have already weaponized it. The 24,650 currently-exposed endpoints and >30% hash-cracking success rate against factory defaults eliminate any argument that friction sufficiently narrows the reachable population.

1. Block UDP 623 at all perimeter and internal segment firewalls — This is the single most effective control. If UDP 623 is unreachable, the RAKP handshake cannot be initiated. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings. Verify with nmap -sU -p 623 from outside the management segment.
2. Isolate all BMCs onto a dedicated out-of-band management VLAN — BMC traffic should never traverse production networks. Create a physically or logically separate management network with strict ACLs permitting access only from designated jump hosts. This eliminates the attack surface for any host not on the management VLAN. Deploy within 3 days.
3. Rotate all BMC passwords to strong, unique, randomly generated credentials (20+ characters) — Factory defaults and short passwords are crackable in seconds to hours. Use a PAM or secrets vault (CyberArk, HashiCorp Vault) to generate and store unique BMC credentials per server. This makes offline cracking computationally infeasible even if hashes are obtained. Deploy within 3 days.
4. Disable IPMI over LAN where not operationally required — If BMC management is performed exclusively via the web UI (HTTPS) or SSH, disable the IPMI over LAN channel in BMC settings. This prevents the RAKP handshake entirely. Note: this does NOT disable the BMC web interface — only the IPMI protocol on UDP 623.
5. Configure IP-based ACLs on each BMC — Restrict BMC login sources to specific jump-host IPs. Even if hashes are harvested, the attacker cannot authenticate from an unauthorized IP. Most BMC firmware supports IP-based access restrictions in the network configuration.
6. Forward BMC syslog/SEL to SIEM and alert on anomalous logins — BMCs log authentication events in the System Event Log. Forward these to your SIEM and create alerts for logins from unexpected IPs, new user creation, and firmware update events. This provides detection-in-depth for the authentication and post-exploitation steps.

Run from an auditor workstation with network access to the target BMC management segment. Requires ipmitool (install via apt install ipmitool or yum install ipmitool). No special privileges needed. Invoke: bash check_cve_2013_4786.sh 10.0.100.50

#!/usr/bin/env bash
# CVE-2013-4786 - IPMI 2.0 RAKP Hash Disclosure Detection
# All IPMI 2.0 implementations are vulnerable (specification-level flaw).
# Strategy: probe UDP 623 for IPMI 2.0 RAKP response.
# Exit codes: 1=VULNERABLE, 0=PATCHED (not reachable), 2=UNKNOWN

set -uo pipefail
TARGET="${1:?Usage: $0 <target_bmc_ip>}"
TIMEOUT_SEC=10

echo "[*] CVE-2013-4786: IPMI 2.0 RAKP Hash Disclosure Check"
echo "[*] Target: $TARGET (UDP 623)"
echo ""

# Prefer ipmitool (standard BMC management tool)
if command -v ipmitool &>/dev/null; then
    echo "[*] Probing with ipmitool -I lanplus ..."
    # Attempt IPMI 2.0 session with a dummy password.
    # If the BMC responds at all to RAKP, it is vulnerable by specification.
    RESP=$(timeout "$TIMEOUT_SEC" ipmitool -I lanplus -H "$TARGET" \
        -U ADMIN -P __nonexistent_probe__ -C 3 chassis status 2>&1 || true)

    if echo "$RESP" | grep -qiE "RAKP|password|unauthorized|session|privilege|insufficient|Unable to establish IPMI"; then
        # BMC responded to IPMI 2.0 handshake — RAKP hash was transmitted
        echo "VULNERABLE - IPMI 2.0 service responded on $TARGET:623"
        echo "  The RAKP handshake completed; a password-derived HMAC was returned."
        echo "  This is a specification flaw — no patch exists."
        echo "  Verify hash extraction: msfconsole -x 'use auxiliary/scanner/ipmi/ipmi_dumphashes; set RHOSTS $TARGET; run'"
        exit 1
    elif echo "$RESP" | grep -qiE "timed out|No route|Network is unreachable|Connection refused"; then
        echo "PATCHED - IPMI over LAN not reachable on $TARGET:623"
        echo "  UDP 623 is blocked, filtered, or IPMI over LAN is disabled."
        exit 0
    else
        echo "UNKNOWN - Unexpected ipmitool response:"
        echo "$RESP"
        exit 2
    fi
fi

# Fallback: nmap UDP scan (requires root for UDP)
if command -v nmap &>/dev/null; then
    echo "[*] ipmitool not found. Falling back to nmap UDP probe (may need sudo)..."
    NMAP_OUT=$(sudo nmap -sU -p 623 -n --open -T4 "$TARGET" 2>&1)

    if echo "$NMAP_OUT" | grep -q "623/udp.*open"; then
        echo "VULNERABLE - UDP 623 is open on $TARGET (IPMI service detected)"
        echo "  All IPMI 2.0 implementations are affected by CVE-2013-4786."
        echo "  Install ipmitool and re-run for definitive confirmation."
        exit 1
    elif echo "$NMAP_OUT" | grep -qE "closed|filtered"; then
        echo "PATCHED - UDP 623 is closed or filtered on $TARGET"
        exit 0
    else
        echo "UNKNOWN - Unexpected nmap output:"
        echo "$NMAP_OUT"
        exit 2
    fi
fi

echo "UNKNOWN - Neither ipmitool nor nmap found. Install one and retry."
exit 2

Sources

1. Lava Security — BMC Exposure Research (July 2026)
2. The Hacker News — 24,650 Internet-Exposed BMCs Disclose IPMI Password Hashes (July 2026)
3. Rapid7 — A Penetration Tester's Guide to IPMI and BMCs
4. Rapid7 — Metasploit ipmi_dumphashes Module
5. NVD — CVE-2013-4786 Detail
6. CosmicRakp — Go-based IPMI Hash Extraction Tool
7. Tenable — Nessus Plugin 80101: IPMI v2.0 Password Hash Disclosure
8. Dell — Data Domain IPMI v2.0 Password Hash Disclosure Advisory