CVE-2026-85504 in FreeIPMI
Summary
by MITRE • 09/04/2026
FreeIPMI before 1.6.19 has a stack-based buffer overflow in _ipmi_sel_oem_fujitsu_get_sel_entry_long_text in libfreeipmi/sel/ipmi-sel-string-fujitsu-irmc-common.c via malformed Fujitsu SEL long-text responses.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified as CVE-2023-48795 represents a critical stack-based buffer overflow within the FreeIPMI software suite, specifically affecting versions prior to 1.6.19. This flaw is located in the function _ipmi_sel_oem_fujitsu_get_sel_entry_long_text, which resides in the source file libfreeipmi/sel/ipmi-sel-string-fujitsu-irmc-common.c. The root cause of this vulnerability stems from insufficient bounds checking when processing System Event Log (SEL) entries provided by Fujitsu Integrated Remote Management Controller hardware. When the application receives a malformed SEL long-text response, it fails to validate the length of the incoming data against the allocated stack buffer size, leading to an overflow condition that can corrupt adjacent memory structures on the call stack.
From a technical perspective, this vulnerability is classified under CWE-121, which denotes a stack-based buffer overflow. The exploitation mechanism relies on crafting specific malicious SEL packets where the long-text field exceeds the expected limit defined by the application logic. Because FreeIPMI operates at a low level to interact with hardware management interfaces such as IPMI and Redfish, it often runs with elevated privileges or within contexts that handle sensitive system configuration data. An attacker who can inject these malformed responses into the communication channel between the management controller and the host operating system can trigger arbitrary code execution by overwriting return addresses or function pointers on the stack. This aligns closely with ATT&CK technique T1203, which covers exploitation for client execution, particularly in scenarios where an adversary leverages trusted software components to gain initial access or escalate privileges within a managed environment.
The operational impact of this vulnerability is severe due to its potential to compromise the integrity and availability of server management infrastructure. FreeIPMI tools are frequently used by system administrators and automated orchestration platforms to monitor hardware health, configure BIOS settings, and manage power states across data center fleets. If an attacker successfully exploits this buffer overflow, they could execute arbitrary code with the privileges of the user running the FreeIPMI utility or daemon. In many enterprise deployments, these tools run as root or within privileged service accounts to access low-level hardware registers. Consequently, successful exploitation could lead to full system compromise, allowing the adversary to install backdoors, exfiltrate sensitive data stored on the managed servers, or pivot laterally across the network using stolen credentials and internal reconnaissance capabilities gained from the compromised management interface.
Mitigation strategies must prioritize immediate patching of the FreeIPMI installation to version 1.6.19 or later, where this bounds checking issue has been resolved by developers implementing proper length validation before copying data into stack buffers. In environments where upgrading is not immediately feasible, network segmentation should be enforced to restrict access to IPMI and Redfish interfaces exclusively from trusted management networks, thereby reducing the attack surface available to potential adversaries. Additionally, deploying intrusion detection systems capable of inspecting BMC traffic for anomalous packet sizes or malformed SEL structures can provide an additional layer of defense against exploitation attempts. Regular auditing of third-party dependencies used in infrastructure automation scripts is also recommended to ensure that vulnerable versions are not inadvertently deployed through package managers or container images without proper verification checks.