The Supply Chain Nightmare Hiding in Your Baseboard Management Controller

TLDR: Researchers recently uncovered a critical command injection vulnerability in the Redfish service of AMI MegaRAC BMCs, tracked as CVE-2022-40259. This flaw allows remote, post-authenticated attackers to execute arbitrary code with root privileges, effectively granting them persistent control over server infrastructure. Because this vulnerable firmware is embedded across countless hardware vendors, the impact is systemic and difficult to remediate without a comprehensive Software Bill of Materials (SBOM) strategy.

Firmware security is the industry’s blind spot. While developers obsess over patching web applications and securing cloud APIs, the foundation of the computing stack—the Baseboard Management Controller (BMC)—often remains a black box. The recent research into AMI MegaRAC BMCs proves that when a vulnerability exists at the hardware management layer, it doesn't just affect one server; it compromises the entire fleet. We are talking about a scenario where an attacker can gain persistent, root-level access to a server, bypass OS-level security controls, and remain invisible to standard EDR solutions.

The Anatomy of the MegaRAC Vulnerability

At the heart of this research is a command injection flaw within the Redfish service, which is the standard API for managing server hardware. The vulnerability, CVE-2022-40259, exists because the BMC fails to properly sanitize user input before passing it to the underlying operating system.

In the demonstration, the researchers showed how an attacker with minimal-level access—specifically, the "callback" role intended for server monitoring—could inject arbitrary commands into the URL path. Because the BMC runs these services as the root user (UID 0), the impact is immediate and total. The device does not perform URL decoding on the input, allowing an attacker to use techniques like $(IFS) to inject spaces and bypass filters.

# Conceptual payload structure for command injection
GET /redfish/v1/Systems/1/$(command_here) HTTP/1.1
Host: bmc-ip-address
Authorization: Basic [base64_encoded_credentials]

This is not a theoretical bug. It is a classic Injection vulnerability, but it is weaponized against the very hardware that is supposed to provide out-of-band management and recovery. Once the attacker executes their payload, they can implant persistent backdoors in the BIOS, smuggle out KVM images to monitor administrator actions, or move laterally across the management network to compromise other BMCs.

Why This Matters for Pentesters

If you are conducting a red team engagement or a penetration test, the BMC is now a primary target. During a typical internal network assessment, we often see BMC interfaces exposed on management VLANs. If you find an AMI MegaRAC interface, you are not just looking at a server management console; you are looking at a potential root-level entry point.

The research highlights that these devices often ship with default credentials or weak password hashing mechanisms, such as MD5 with a global salt or SHA-512 with per-password salts, as seen in CVE-2022-40258. When you combine these authentication failures with the command injection flaw, the barrier to entry is non-existent. You do not need to be a nation-state actor to exploit this; you just need a scanner like Shodan to find exposed interfaces and a basic understanding of the Redfish API.

The Supply Chain Problem

The most alarming aspect of this research is the propagation of the vulnerability. AMI provides the firmware, but that firmware is then rebranded and distributed by dozens of hardware vendors. When a bug is found in the base firmware, it doesn't get fixed everywhere simultaneously. It creates a massive, fragmented disclosure process where vendors must wait for the upstream provider to issue a patch, then integrate it, test it, and push it to their customers.

This is why the industry is pushing for SBOMs. Without a clear inventory of the components inside our firmware, we are flying blind. We cannot patch what we do not know we have. If you are a security researcher, start looking at the firmware images of the hardware you test. Use tools to extract the filesystem and search for hardcoded credentials or insecure API endpoints. The "install patches" advice is becoming obsolete because the patch cycle for firmware is fundamentally broken.

Moving Forward

Defenders need to treat BMCs as high-value assets. If you cannot isolate your management network, you must at least implement strict access controls and monitor for anomalous traffic originating from your BMCs. For the research community, the takeaway is clear: the next frontier of offensive security is not in the application layer, but in the silicon and the firmware that manages it.

Stop assuming the hardware is secure. Start auditing the management interfaces as rigorously as you audit your production web applications. The next time you are on an engagement, don't just look for the low-hanging fruit in the web app; check the BMC. You might find that the entire server is already yours.