The editorial argues this isn't just root on the OS — it's 'root under the server.' The BMC is a separate ARM SoC with its own CPU, RAM, and network stack that runs whether the host is powered on or off, sees everything on the PCIe bus and system memory, and survives OS reinstalls, making code execution there the closest you can get to being physically in the data center.
Argues that ops teams mentally model their servers as 'the OS' and treat everything underneath as trustworthy hardware, when in reality the BMC is a general-purpose Linux computer running a 2016-era kernel with a web server, IPMI stack, and Redfish API — often with default credentials sitting on the network. This mental model gap is why BMCs remain the single most neglected attack surface.
Reports that while AMI has shipped upstream patches, the per-vendor integration, QA, and signed-image release process historically takes months per vendor and years to land in production. Notes that previous MegaRAC bugs from the same disclosure chain remain unpatched on servers in the wild four years after disclosure, suggesting the patch pipeline is structurally broken for firmware at this layer.
By surfacing this story to HN's front page with 155 points, the submitter amplifies the framing that this is a planet-scale server threat where the patch distribution lag is the central problem, not the vulnerability's technical novelty.
Researchers at Eclypsium disclosed a critical remote code execution flaw in AMI's MegaRAC baseboard management controller firmware — the software stack that ships inside the BMCs of servers from Dell, HPE, Lenovo, Supermicro, ASUS, Gigabyte, and essentially everyone else who sells x86 iron. The bug, tracked as part of the ongoing MegaRAC vulnerability chain that security teams have been grinding through since 2022, allows unauthenticated attackers who can reach the BMC's management interface to execute arbitrary code with the privileges of the BMC itself.
That's not root on the server. That's root under the server. The BMC is a separate ARM SoC with its own CPU, RAM, network stack, and persistent flash. It runs whether the host is powered on or off, sees everything on the PCIe bus and system memory, and is specifically designed to survive OS reinstalls. Code execution there is the closest thing to physical possession of the box you can get without being in the data center.
AMI has shipped patches. Vendors are now in the familiar scramble of integrating the upstream fix into their own BMC firmware builds, QA'ing them, and getting them out as signed images — a process that historically takes months per vendor and years to actually land in production fleets. Ars Technica's reporting notes that previous MegaRAC bugs from the same disclosure chain are still unpatched on servers in the wild, four years in.
The BMC threat model is the one almost nobody draws correctly on their whiteboard. Most ops teams think of their server as "the OS" and treat anything underneath as hardware — static, trustworthy, out of scope. In reality, the BMC is a general-purpose Linux computer, usually running a 2016-era kernel, with a web server, an IPMI stack, and a redfish API, sitting on your network with its own IP address and often default credentials. It is the single most under-audited attack surface in a modern data center.
The reason this specific class of bug matters more than yet-another-CVE is persistence. An attacker who gets code execution in the BMC can flash the BMC's own firmware, implant below the host OS, and survive you nuking the drives and reinstalling from scratch. They can read host RAM via DMA. They can quietly man-in-the-middle the serial console an on-call engineer uses to debug a "weird" box. Detection tooling almost universally lives on the host side of that boundary and can't see any of it.
Compare the response surface to a typical kernel RCE. For a Linux CVE you `apt upgrade`, reboot, done — maybe an afternoon across a fleet with good automation. For a BMC RCE you need a vendor-signed firmware image for your exact SKU and board revision, a flashing procedure that often requires the host to be rebooted or powered off, and a plan for what to do about the servers whose vendors have EOL'd the model and will never ship a fix. Hyperscalers who treat BMCs as a managed fleet (Meta's OpenBMC, Google's custom stacks) handle this in days. Everyone running a mixed fleet of Dell/HPE/Supermicro gear from the last six years is looking at a quarters-long remediation project, if they do it at all.
The community reaction on Hacker News leaned, correctly, toward exasperation. The MegaRAC codebase has had an uninterrupted stream of pre-auth RCEs since 2022's "BMC&C" disclosure. The pattern — closed firmware, shared across vendors, with QA that treats "it boots" as the acceptance criterion — is structurally the same as the one that produced a decade of consumer router bugs, except the install base is every rack in every colo on the planet. OpenBMC exists and is open source, but adoption outside hyperscalers is a rounding error.
First, inventory. Right now, today, run something that enumerates every BMC IP in your environment and the firmware version it reports. If you don't have a BMC inventory, your remediation plan can't exist. Redfish's `/redfish/v1/UpdateService/FirmwareInventory` endpoint will give you this on most modern gear; `ipmitool mc info` works on older stuff.
Second, network posture. Your BMC management network should not be reachable from your production VLAN, your corporate VLAN, your VPN, or the internet — full stop. If you can `curl` your BMC's web UI from a developer laptop, you have already lost the only reliable defense you had against this bug and the next ten like it. A dedicated out-of-band management network with jump-host-only access is the control that actually works; everything else is a mitigation at best. Check your cloud provider's defaults here too — bare-metal offerings on AWS, OCI, and Equinix all expose BMC-equivalent surfaces, and the sharing model varies.
Third, patch cadence. Build BMC firmware updates into your regular maintenance window the same way you handle BIOS and NIC firmware. Most shops update the BMC once in the server's lifetime — at provisioning — and never again. That is the policy that keeps vulnerabilities from 2022 alive on production fleets in 2026. If your vendor's firmware release notes are opaque about security content (and they will be), subscribe to Eclypsium's and Binarly's advisory feeds and cross-reference.
Fourth, if you're building anything new that will live for five-plus years: ask your vendor about OpenBMC support. The answer will usually be no, but asking is how that changes. The economics of a shared, auditable BMC stack get better every time a MegaRAC bug drops.
The uncomfortable truth is that firmware is now the slowest-moving layer of the stack and the one with the worst security hygiene, and it sits underneath everything else you spend money defending. Until BMCs are either airgapped by default or built on auditable open-source firmware with a real patch pipeline, every one of these disclosures is a free Tuesday for a motivated attacker. The hyperscalers already figured this out and moved. The rest of the industry is going to spend the back half of the decade catching up, one firmware flash at a time.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.