Send an IPMI authentication request to almost any exposed baseboard management controller and it will hand you a password hash before you’ve proven who you are. That’s not a new bug. It’s baked into the IPMI 2.0 specification ratified back in 2002, and this week’s reporting confirms what researchers have flagged for more than a decade: thousands of internet-facing server management controllers are still sitting there, waiting for someone to run an offline brute-force job against them. It’s a tidy illustration of a problem that shows up constantly in cybersecurity work: the vulnerability isn’t new, the exploit tooling isn’t new, and the only thing that changed is that someone finally pointed a scanner at it and adversaries noticed.

Baseboard management controllers, the little co-processors that let admins power-cycle, reimage, and monitor servers remotely without touching the box, are supposed to be locked away on an isolated management network. In practice, plenty of them sit on the open internet, discoverable with the same tools used to find exposed RDP or SSH. Once found, the RAKP authentication handshake in IPMI 2.0 will happily return a salted password hash to an unauthenticated client, no login required. From there it’s a straightforward offline cracking exercise, and depending on password strength, a trivial one.

The Vulnerability That Never Aged: How IPMI Leaks Credentials by Design

The RAKP hash disclosure issue has a CVE, plenty of conference talks, and a Metasploit module that’s been sitting on shelves for years. What keeps it relevant isn’t novelty, it’s neglect. BMCs ship with default credentials, rarely get firmware updates, and often get deployed by teams who assume “it’s just for management” means “it doesn’t need the same hardening as production.” That assumption is exactly backwards. A compromised BMC gives an attacker console-level access to the server underneath it, bypassing the operating system, its logging, and most endpoint threat detection entirely. You can have a fully patched OS and a locked-down application stack, and still lose the box because the management plane was an afterthought.

Offline Cracking Just Got a Speed Upgrade

Here’s the part that should worry defenders more than the headline. The same week this BMC story broke, Anthropic disclosed that its Claude Mythos Preview model helped derive a full key-recovery attack against the post-quantum HAWK-256 signature scheme, running end-to-end in under four hours on a 96-core server, and produced a 200- to 800-fold speedup against seven-round AES-128. Those are research results against specific cryptographic constructions, not a direct threat to IPMI’s password hashing. But they’re a preview of where the ground is shifting. Attacks that used to require a dedicated cryptography team and months of work are increasingly reachable with AI-assisted analysis and off-the-shelf compute. Offline password and hash cracking, which is exactly what an exposed BMC hands an attacker the raw material for, only gets faster as this tooling matures.

That matters for how you think about security hardening. A password policy that felt adequate against yesterday’s brute-force budgets doesn’t automatically stay adequate. Defense in depth has always meant not betting everything on one control holding forever; it increasingly also means not betting on today’s compute assumptions holding for long either. If your only protection against an exposed management interface is “the hash is salted and the password is decent,” you’re relying on a clock that’s ticking faster than it used to.

Incident Response Playbook: Auditing Out-of-Band Management

The fix here isn’t exotic. It’s the same discipline that’s ignored on management networks over and over: find what’s exposed, take it off the internet, and rotate what might already be compromised. Treat any BMC, iDRAC, iLO, or IPMI interface you can’t immediately account for as an active incident until proven otherwise, not a maintenance backlog item.

• Inventory every BMC, IPMI, iDRAC, and iLO interface on your network and confirm none are reachable from the public internet.
• Move all out-of-band management traffic onto a dedicated, firewall-isolated VLAN with no route to general production or user networks.
• Disable IPMI Cipher Suite 0 and legacy RAKP authentication where firmware allows, and require IPMI 2.0 with strong cipher suites only.
• Rotate default and shared BMC credentials, enforce unique high-entropy passwords per device, and disable any accounts you didn’t provision yourself.
• Apply firmware updates on a real schedule, since BMC firmware tends to get ignored during normal patch cycles for the host OS.
• Add BMC and management-plane logs to your threat detection pipeline instead of leaving them as a blind spot outside normal monitoring.

None of this requires new budget or a new vendor. It requires someone treating the management network with the same suspicion they’d apply to a public-facing web app, and then actually running the scan to confirm it. If you haven’t done that audit in the last year, assume the answer is worse than you’d like.

Why This Keeps Happening

The uncomfortable pattern across both stories this week, an ancient protocol flaw and a frontier AI model accelerating cryptanalysis, is that the gap between “known vulnerable” and “actually fixed” keeps growing even as the tools on the attacker’s side get sharper. Threat protection built around the assumption that old, well-documented flaws are low priority because they’re not new anymore is exactly the assumption that gets organizations breached. IPMI’s RAKP hash leak has been public knowledge since roughly 2013. It’s 2026 and it’s still front-page material. That’s not a technology problem anymore. It’s an operational one, and it’s fixable with an afternoon of network segmentation work and a credential rotation, not a research grant.

Sources

• Flaw From 2002 Exposes Data Centers to Server Takeover
• Claude AI Just Cracked a Post-Quantum Test Scheme and Found a Faster 7-Round AES Attack