CVE-2025-71450 in inih
Summary
by MITRE • 11/02/2026
inih before r63 contains a one-byte stack buffer under-read in ini_parse_stream() in ini.c that allows attackers to read abyss[-1] via an embedded NUL byte after an overlong line. Attackers can supply an INI file or string with a line of at least INI_MAX_LINE-1 bytes followed by a NUL byte, causing undefined behavior reported by memory sanitizers.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The vulnerability identified in the inih library prior to revision r63 represents a critical stack-based buffer under-read condition located within the ini_parse_stream function of the ini.c source file. This flaw stems from an off-by-one error during the parsing logic that processes input streams, specifically when handling lines that approach or exceed the defined maximum line length constant INI_MAX_LINE. The root cause lies in how the parser manages memory pointers and boundary checks while iterating through characters to identify section headers, key-value pairs, or comments. When a line is constructed with a length of at least INI_MAX_LINE minus one bytes followed immediately by a NUL byte, the internal pointer arithmetic fails to account for the end-of-string condition correctly in all code paths. This miscalculation results in the program attempting to access memory address abyss[-1], which refers to an invalid location just before the allocated buffer or stack frame boundary. Such behavior is classified as undefined behavior according to C language standards, meaning the outcome can vary wildly depending on compiler optimizations and runtime environment conditions.
From a technical perspective, this vulnerability aligns with CWE-125, Out-of-bounds Read, specifically manifesting as an under-read where the memory access occurs below the valid buffer range rather than above it. The presence of the embedded NUL byte after an overlong line acts as the trigger for this specific execution path. In many implementations, string processing functions rely on finding a NUL terminator to determine string length or end-of-line boundaries. If the parser logic assumes that a certain number of characters precede the current position without verifying that those positions are within valid stack memory limits, it will dereference an invalid pointer. Memory sanitizers such as AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan) readily detect this condition because they monitor for accesses to unmapped or guard pages adjacent to allocated buffers. The detection of abyss[-1] indicates that the program is attempting to read from a memory address that has been explicitly marked as inaccessible, typically placed by sanitizers to catch buffer overflows and underflows during development and testing phases.
The operational impact of this vulnerability extends beyond simple crashes or denial-of-service scenarios. While immediate exploitation for arbitrary code execution may be difficult due to the nature of an under-read rather than a write operation, reading from invalid memory can still lead to significant security compromises. The data retrieved from the stack location immediately preceding the buffer might contain sensitive information such as return addresses, saved frame pointers, or other local variables that were pushed onto the stack during function invocation. If this leaked data is predictable or contains cryptographic keys and session tokens stored in adjacent stack frames, an attacker could potentially reconstruct critical application state. Furthermore, undefined behavior introduces non-determinism into the application's execution flow. This unpredictability can be leveraged to bypass security controls that rely on consistent program states or to trigger crashes that disrupt service availability for legitimate users. In environments where ini files are processed from untrusted sources, such as user-uploaded configuration files in web applications or embedded systems, this vulnerability provides a reliable vector for information disclosure and stability degradation.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation is to upgrade the inih library to version r63 or later, where the developers have addressed the boundary check logic within ini_parse_stream to ensure that pointer arithmetic never results in accessing memory below the allocated buffer space. For organizations unable to immediately update dependencies, implementing input validation at the ingestion layer can provide a temporary shield. This involves enforcing strict length limits on incoming INI content before it is passed to the parsing function and rejecting any lines that exceed the expected maximum size without proper handling of line continuations or escaping mechanisms. Additionally, enabling compiler flags such as -fstack-protector-strong and linking with sanitizers during testing phases can help detect similar issues in other parts of the codebase early in the development lifecycle.
From a threat intelligence standpoint, this vulnerability maps to MITRE ATT&CK technique T1082, System Information Discovery, specifically under sub-techniques related to memory scraping or stack inspection if the leaked data is utilized for further exploitation. It also relates to CWE-754, Improper Check for Unusual or Exceptional Conditions, as the parser fails to properly validate input conditions that deviate from expected norms, such as lines nearing the maximum length limit. Security teams should prioritize patching systems where inih is used in contexts involving untrusted input, particularly in network-facing services or privileged processes. Regular auditing of third-party library usage and maintaining an up-to-date software bill of materials are essential practices to ensure that known vulnerabilities like this one do not persist in production environments. By addressing the root cause through version updates and reinforcing input validation layers, organizations can effectively neutralize the risk posed by this stack-based under-read vulnerability.