CVE-2024-54085

What it actually does

This is a critical remote authentication-bypass vulnerability in AMI MegaRAC SPx baseboard management controller (BMC) firmware. The flaw is reachable through the Redfish Host Interface and can allow an unauthenticated attacker to access BMC management functions without valid credentials. Because BMCs operate below the host operating system and provide out-of-band management capabilities, successful exploitation can affect confidentiality, integrity, and availability, including exposure of hardware/firmware configuration, unauthorized management actions, host power control, virtual media abuse, firmware changes, or persistence at the management-controller layer.

Why it matters to the business

Compromise of a BMC can give an attacker powerful control over server infrastructure even if the operating system appears healthy. Business consequences may include server outages, tampering with hardware or firmware settings, unauthorized access to sensitive operational data, difficult-to-detect persistence, delayed recovery, and potential disruption across data centers or hosted services. The issue is listed in CISA KEV with a remediation due date of 2025-07-16, has active in-the-wild exploitation, and has a high EPSS score, so organizations should treat exposed or reachable affected BMC interfaces as urgent risk.

How an attack unfolds

An attacker first identifies systems exposing an AMI MegaRAC SPx BMC Redfish Host Interface or management network path. If the vulnerable firmware is present, the attacker sends crafted Redfish Host Interface requests that spoof or bypass the expected authentication path. After gaining unauthenticated access, the attacker can enumerate BMC configuration, create or modify management access, issue Redfish/IPMI-style management actions, alter boot or virtual media settings, power-cycle hosts, collect sensitive inventory or configuration information, and potentially stage deeper persistence through BMC or firmware-level changes. Because exploitation targets the management controller rather than the operating system, normal endpoint controls on the host may not observe the initial compromise.

How to fix it

Apply vendor-provided BMC firmware updates that remediate CVE-2024-54085 for all systems using affected AMI MegaRAC SPx firmware. Because fixed versions were not provided in the input, obtain the corrected firmware from the server/OEM vendor or AMI advisory channel for each hardware model, and verify the installed BMC firmware build against the vendor’s fixed release notes. Until patching is complete, restrict BMC and Redfish access to dedicated, isolated management networks; block Redfish Host Interface access from untrusted networks; enforce firewall allowlists and VPN/jump-host access; disable unused Redfish/IPMI services where operationally possible; rotate BMC credentials after remediation; review and remove unauthorized BMC users or API tokens; and rebaseline BMC configuration, boot order, virtual media settings, and firmware integrity.

How to confirm the fix worked

Confirm exposure by inventorying servers with AMI MegaRAC SPx-based BMC firmware and checking BMC firmware versions against OEM or AMI fixed-version guidance. Validate that Redfish endpoints are not reachable from untrusted networks by scanning only approved ranges and confirming management-plane segmentation. After applying firmware updates, verify the BMC reports the expected fixed firmware version, reboot or reset the BMC as directed by the vendor, and retest that unauthenticated Redfish Host Interface requests are rejected. Also confirm that BMC accounts, roles, network settings, remote media settings, boot configuration, and audit logging match the approved baseline.

Typical attack path

1. Scan for reachable BMC management services or Redfish endpoints associated with AMI MegaRAC SPx.
2. Confirm Redfish Host Interface behavior and firmware exposure without needing valid BMC credentials.
3. Send crafted requests that exploit the authentication-bypass condition.
4. Use the resulting unauthenticated BMC access to enumerate users, hardware inventory, network settings, firmware versions, and host state.
5. Modify BMC configuration, add or abuse management access, mount virtual media, change boot order, or issue power-control operations.
6. Use BMC control to disrupt services, support lateral movement, or maintain stealthy persistence outside the host operating system.

How to detect it

Review BMC, Redfish, web server, and management-plane network logs for evidence of unauthenticated or anomalous access to Redfish Host Interface endpoints. Prioritize logs around first internet exposure, unusual management-network traffic, and the period before remediation. Look for Redfish API requests from unknown IP addresses, repeated HTTP 401/403 followed by successful 200 responses, requests to Redfish session, account, update, virtual media, boot, reset, and power-control resources without corresponding approved administrative activity. Examine BMC audit logs for new or modified users, role changes, password changes, token/session creation anomalies, firmware update attempts, virtual media mount/unmount actions, boot-order changes, configuration exports, and host reset/power actions. Correlate with network telemetry for unexpected connections to BMC TCP management ports, especially HTTPS/Redfish, from non-management subnets. Because host-based EDR may not observe BMC compromise, rely on BMC audit logs, network flow records, firewall logs, management jump-host logs, configuration baselines, and OEM management-console records. If threat-actor or campaign labeling appears in threat intelligence feeds as AMI MegaRAC SPx authentication bypass by spoofing, enrich searches with observed source IPs and HTTP request patterns from those feeds.

• /redfish/v1/
• /redfish/v1/SessionService/Sessions
• /redfish/v1/AccountService/Accounts
• /redfish/v1/Managers
• /redfish/v1/Systems
• /redfish/v1/UpdateService
• /redfish/v1/Managers/*/VirtualMedia
• /redfish/v1/Systems/*/Actions/ComputerSystem.Reset
• /redfish/v1/Managers/*/Actions/Manager.Reset
• /redfish/v1/Systems/*/Boot
• GET /redfish/v1/
• POST /redfish/v1/SessionService/Sessions
• POST /redfish/v1/AccountService/Accounts
• PATCH /redfish/v1/AccountService/Accounts
• POST /redfish/v1/Systems/
• POST /redfish/v1/Managers/
• VirtualMedia.InsertMedia
• VirtualMedia.EjectMedia
• ComputerSystem.Reset
• Manager.Reset
• UpdateService.SimpleUpdate
• AccountService/Accounts
• HostInterface
• Redfish Host Interface
• AMI MegaRAC SPx

What your security team should do

• Prioritize remediation for any internet-reachable or broadly network-reachable BMC management interfaces because the vulnerability is in CISA KEV and is actively exploited in the wild.
• Create or update an asset inventory of AMI MegaRAC SPx/OEM-derived BMC firmware across all server platforms, including firmware version, management IP, network segment, and business owner.
• Obtain fixed BMC firmware from the relevant OEM/AMI source and schedule emergency or accelerated maintenance for exposed/high-value systems.
• Immediately restrict Redfish and BMC management access to trusted management networks only; block access from user, production application, and internet-facing networks.
• Enable and centralize BMC/Redfish audit logging where supported, and preserve logs before BMC resets or firmware updates.
• Hunt for suspicious Redfish requests, unauthenticated access attempts, new BMC users, unexpected privilege changes, virtual media usage, boot-order changes, and unexplained host power events.
• After patching, rotate BMC credentials and API secrets, remove unknown accounts, and compare BMC configuration against known-good baselines.
• For systems with signs of compromise, treat the BMC as potentially persistent infrastructure: collect firmware/configuration evidence, consider vendor-assisted firmware reflash, and validate host integrity before returning to service.