CVE-2023-37295 is a high severity heap memory corruption (CVSS 8.3) in the BMC firmware of AMI MegaRAC SPx12 and SPx13, reachable from an adjacent network. AMI lists SPx_12.7 and SPx_13.6 as the fixed versions, so ask your hardware vendor for matching firmware.
What's affected
- Product: AMI MegaRAC SPx, baseboard management controller (BMC) firmware, in the SPx12 and SPx13 lines.
- Fixed versions: SPx_12.7 and SPx_13.6, per AMI security advisory AMI-SA-2023010, first published on 9 January 2024 and revised on 11 January 2024.
- Severity: High, CVSS 8.3, vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. The advisory table gives the same score.
- Exploited in the wild: the record's CISA KEV flag is false.
The advisory describes a vulnerability in the BMC where an attacker may cause heap memory corruption via an adjacent network, and says a successful exploit may lead to loss of confidentiality, integrity and availability. It gives no further technical detail, and this post does not add any.
How to check if you're exposed
BMC firmware is separate from the server operating system, so package managers on the host will not show it. Check it in one of these ways:
- The BMC web interface, which normally shows a firmware version on its dashboard or firmware update page.
- Your server vendor's management tooling or inventory console.
- The firmware inventory your vendor provides for the server model.
If the vendor build is based on AMI MegaRAC SPx12 or SPx13 and predates SPx_12.7 or SPx_13.6, treat it as affected. Server makers repackage BMC firmware under their own version numbers, so the version you see may not read as SPx_12.7. Ask the vendor which AMI release a given build contains.
What to do now
- List servers and appliances with a BMC, and note the vendor and model of each.
- Ask each vendor whether their firmware includes AMI MegaRAC SPx12 or SPx13, and which build contains the SPx_12.7 or SPx_13.6 fix.
- Schedule the firmware update. BMC updates usually need a maintenance window and a reboot of the controller.
- Keep BMC interfaces on a dedicated management network, not on general user or server segments. The vector says the attacker needs adjacent network access, so network placement matters directly here.
- Review who can reach the management network, and remove anything that does not need to be there.
Why it matters
The weakness is a memory error in firmware: heap memory corruption. In this class of bug, the code writes more data into a buffer than it holds, or otherwise corrupts memory it should not touch. In a BMC, that is serious because the controller runs independently of the host and has deep control over the machine.
The record scores the scope as changed. That means a compromise of the BMC can affect resources beyond the component itself, such as the server it manages. Adjacent access limits who can try it, so a flat network where management ports are visible to many machines is the main risk factor. A segmented management network is the strongest practical control.
Safeguard can help with the inventory side of this work. The free in-browser dependency scan at gold.safeguard.sh/scan checks the packages in a manifest against known CVEs, and the Gold directory keeps a page per CVE and per weakness class so you can see related issues in one place. Reachability analysis then helps you separate a package that is merely present from one your code actually calls.
Quick check
Can this be attacked from the internet?
The vector is adjacent network, so the attacker needs access to the same network segment as the BMC. Keeping the management interface off shared and internet-facing networks is the key control.
Which firmware fixes it?
AMI lists SPx_12.7 for SPx12 and SPx_13.6 for SPx13. Your server vendor may use its own version numbers, so ask which build includes the fix.
Sources
Last reviewed: 19 October 2026.
