Is CVE-2024-54085 (AMI MegaRAC SPx Authentication Bypass by Spoofing) being exploited in the wild?

What this CVE means operationally

CVE-2024-54085 is not just a vulnerability to track, it is an indicator that the affected AMI MegaRAC SPx deployment can be reached and abused through the Redfish Host Interface. For that reason, the first operational question is whether the product is present anywhere in your estate, including embedded management paths and vendor-managed hardware where it may not be obvious from the application inventory.

Because CISA has placed it in the Known Exploited Vulnerabilities catalogue, the working assumption should be that exploitation is already a real-world event, not a theoretical concern. For current triage and prioritisation, use the CISA Known Exploited Vulnerabilities Catalog alongside the vendor advisory, and treat the exposure as urgent until you can prove otherwise.

Why authentication bypass by spoofing is especially dangerous here

An authentication bypass by spoofing weakens the trust boundary that should separate an unauthenticated request from a privileged management function. In a BMC or out-of-band management context, that matters because management interfaces often sit outside normal endpoint monitoring and can provide control over power, firmware, boot, and recovery operations.

This is why actively exploited management-plane flaws often become high-impact incidents even when the initial entry path is narrow. If the Redfish interface can be impersonated or accepted as trusted, defenders may lose the ability to rely on ordinary application-layer assumptions about identity, authorization, or session state.

For a broader triage model for actively exploited vulnerabilities, the Zero-Day and Exploited Vulnerabilities Guide is a useful companion for deciding when to move from normal patch scheduling to emergency action.

What to do when remediation cannot happen immediately

If patching or firmware replacement must wait, the practical goal is to reduce reachable exposure and detect misuse quickly. That means identifying every exposed management endpoint, restricting who can reach it, confirming whether the interface is internet-facing or only reachable from an administrative segment, and documenting any compensating controls that actually block unauthorised access.

Where the device supports it, verify the vendor's mitigation guidance, tighten administrative network paths, and review whether remote management is enabled at all on systems that do not need it. If you cannot remove the flaw quickly, NIST Cybersecurity Framework 2.0 is a reasonable way to organise containment, detection, and recovery around the exposed asset.

Do not assume that lack of obvious alerts means lack of compromise. Management interfaces can be abused without generating the same telemetry as a user-facing application, so post-exposure checks should include logs, configuration drift, unexpected management actions, and any signs that the device has been used as a pivot point.

Risk and Threat Considerations

An exploited BMC or server-management interface can become a foothold that is difficult to observe and harder to evict than a normal application compromise. The main risk is not only unauthorised access, but also the attacker obtaining durable control over hardware management functions that sit below the operating system.

Failure mechanism: A spoofed authentication path allows an attacker to bypass the intended trust check, reach privileged Redfish functions, and potentially alter system behaviour, persistence, or recovery settings without using valid credentials.

Impact: Successful abuse can expose administrative control, enable follow-on compromise, and create a recovery problem because the vulnerable management plane may remain reachable even after the OS is rebuilt.

Practitioner Guidance

What to prioritise: Confirm whether any AMI MegaRAC SPx instance exists in production, lab, DR, or vendor-supported hardware first, then determine whether each instance is reachable from any network segment beyond tightly controlled administration paths.

What to verify: Verify the vendor's fix or mitigation status for the exact hardware model and firmware build, and verify that blocking controls apply to the management interface itself rather than only to the main operating system network.

Escalation / exception: If the system is remotely reachable, internet-exposed, or used to manage high-value infrastructure, treat it as an emergency remediation case rather than a routine patch ticket. If remediation must be deferred, record the exception with a short expiry and a concrete containment owner.

Practitioner takeaway: For exploitable management-plane CVEs, remediation is only half the task, because the real control objective is to remove attacker reachability and prove the trusted management path is not silently accepting spoofed access.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2024-54085 (AMI MegaRAC SPx Authentication Bypass by Spoofing)?
• CVE-2024-54085 (AMI MegaRAC SPx Authentication Bypass by Spoofing)
• Is CVE-2024-0012 (Palo Alto Networks PAN-OS Management Interface Authentication Bypass) being exploited in the wild?
• Is CVE-2023-50224 (TP-Link TL-WR841N Authentication Bypass by Spoofing) being exploited in the wild?