CVE-2026-19499 in glibc
Summary
by MITRE • 09/14/2026
Calling strfmon and strfmon_l in the GNU C Library version 2.38 to 2.44 can write past the end of the caller-supplied output buffer when a conversion uses right-justified width padding.
Exploitation requires an application code path that calls strfmon or strfmon_l with right-justified width padding into a destination buffer that is large enough for the padding to succeed but too small for the internal memmove call. The field width or format may be attacker-influenced or a fixed susceptible pattern in the caller.
At the time of publication, no network-facing application impact is known.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/21/2026
The GNU C Library versions 2.38 through 2.44 contain a critical buffer overflow vulnerability within the strfmon and strfmon_l functions, which are responsible for formatting monetary values according to locale-specific rules. This flaw manifests specifically when these functions process format strings that utilize right-justified width padding. The underlying technical defect arises from an incorrect calculation of the required output buffer size during internal memory operations. Specifically, while the initial logic may determine that a destination buffer is sufficiently large to accommodate the final formatted string including any necessary whitespace padding for alignment, it fails to account for the temporary space requirements of an internal memmove call used to shift characters into their correct positions within the buffer. This discrepancy creates a scenario where the function attempts to write data beyond the allocated boundaries of the caller-supplied output buffer, resulting in a classic heap or stack-based buffer overflow depending on how the buffer was allocated by the application.
Exploitation of this vulnerability requires specific conditions that are not universally present in all applications using these functions. An attacker must influence an application code path where strfmon or strfmon_l is invoked with right-justified width padding directed into a destination buffer. The critical constraint for successful exploitation is that the buffer must be large enough to pass initial size checks related to the final output length, yet insufficiently sized to handle the intermediate memory movement operations performed by the library internals. This suggests that the vulnerability may stem from an attacker-influenced field width or format specifier within a user-controlled input stream, or potentially from fixed susceptible patterns in legacy application code that does not adequately validate buffer capacities against internal processing requirements. The presence of this flaw allows for potential out-of-bounds writes which can lead to memory corruption, arbitrary code execution if the overflow targets critical data structures such as function pointers or heap metadata, or denial of service through segmentation faults and crashes.
From a threat intelligence perspective, while no network-facing application impact has been publicly confirmed at the time of publication, the nature of this vulnerability poses significant risks for any software that processes untrusted monetary formatting requests or parses locale-specific data formats. The flaw aligns with CWE-120 Buffer Copy without Checking Size of Input and CWE-787 Out-of-bounds Write in the Common Weakness Enumeration taxonomy. In terms of attack vectors, it relates to ATT&CK technique T1190 Exploit Public-Facing Application if leveraged through network services that accept formatted input data, although currently the primary risk appears localized to applications handling local or internal user inputs rather than direct external network attacks. The lack of known public exploits for network-facing systems suggests that immediate panic is unnecessary, but proactive remediation remains essential due to the severity of potential memory corruption outcomes.
Mitigation strategies should focus on updating the GNU C Library to a version newer than 2.44 where this internal calculation error has been corrected by upstream developers. For applications unable to update immediately, defensive coding practices are recommended as temporary countermeasures. Developers should ensure that all buffers passed to strfmon and strfmon_l are allocated with sufficient headroom beyond the maximum expected output length to absorb any potential miscalculations in internal memory movements. Additionally, input validation mechanisms can be implemented to restrict or sanitize field width parameters derived from untrusted sources, preventing the triggering of right-justified padding scenarios that expose this specific code path. Regular auditing of locale-sensitive formatting functions is also advised to identify other instances where buffer size assumptions might not align with library internal requirements.