CVE-2026-5450

What it actually does

GNU C Library versions 2.7 through 2.43 contain a one-byte heap buffer overflow in the scanf-family parsing path when a format string uses the GNU malloc-allocation modifier with a character conversion, such as %mc, and an explicit field width greater than 1024. When a vulnerable application parses attacker-controlled input through scanf, fscanf, sscanf, vscanf, or related functions using this pattern, glibc can allocate an undersized heap buffer and write one byte past the allocation. Depending on heap layout and application behavior, this can cause process crashes, memory corruption, or potentially arbitrary code execution in the context of the affected process.

Why it matters to the business

Because glibc is a foundational runtime library used across Linux systems, the flaw has broad potential exposure, but practical risk depends on whether an application actually uses the vulnerable scanf pattern with attacker-controlled input. Internet-facing parsers, daemons, file-processing services, and network services that rely on vulnerable formats could be crashed or potentially taken over. The CVSS score indicates severe worst-case impact, but current exploitation signals are low: EPSS is low, the issue is not listed in CISA KEV, no ransomware association is reported, and no public exploit maturity is indicated. Organizations should still prioritize inventory and patch planning because glibc is widely deployed and often embedded in downstream products, containers, appliances, and Linux distributions.

How an attack unfolds

An attacker first needs to reach an application that uses an affected glibc version and calls a scanf-family function with a format containing %mc, or an equivalent malloc-allocation character conversion, with an explicit width greater than 1024. The attacker then supplies input designed to satisfy that conversion and reach the vulnerable allocation path. When glibc parses the input, it allocates heap memory for the matched character data but can write one byte beyond the allocated buffer. In simple cases, this corrupts adjacent heap metadata or application data and causes a crash, producing a denial of service. In more favorable conditions for the attacker, repeated attempts may be used to shape heap layout, influence the overwritten byte, and convert the memory corruption into control-flow hijacking or code execution under the privileges of the vulnerable process. Exploitability is highly application-dependent and requires the vulnerable scanf format to be reachable with attacker-controlled input.

How to fix it

Upgrade glibc through the operating system or distribution vendor as soon as a fixed package is available. No exact fixed upstream or per-package versions were provided in the input, so remediation should track vendor advisories for GNU C Library releases newer than the affected 2.7 through 2.43 range and distribution-specific backports. Because glibc fixes are commonly backported without changing the upstream version number, rely on package changelogs and vendor security errata rather than version strings alone. Restart affected services after updating glibc, and schedule reboots where necessary to ensure long-running processes are no longer mapped to the vulnerable library. For application owners, review source code for scanf-family formats using %mc or equivalent malloc-allocation character conversions with explicit widths greater than 1024. Replace vulnerable parsing patterns, cap widths at 1024 or lower where safe, or use explicit allocation and bounds-checked parsing routines instead. Where immediate patching is not possible, reduce exposure by disabling or restricting affected parsers, limiting untrusted input paths, applying service isolation, enabling hardening features such as ASLR and seccomp where appropriate, and placing vulnerable services behind authentication or network access controls.

How to confirm the fix worked

Confirm exposure by checking glibc package status on Linux systems and containers, then mapping running processes to the patched libc after updates. Use distribution package tools such as rpm, dpkg, apk, or vendor scanners to identify installed glibc packages and confirm whether the vendor security advisory for this issue is applied. For source-level validation, search application code and third-party components for scanf-family calls using patterns such as %mc with widths greater than 1024. For runtime validation, restart or reboot after patching and verify that processes are not using deleted or old libc mappings, for example by inspecting /proc/<pid>/maps or using tools such as lsof to find deleted libc.so mappings. Where a reproducer is available from a trusted vendor, run it only in a controlled test environment to confirm that the vulnerable parsing path no longer crashes or triggers memory-safety tooling. In CI/CD, add static-analysis or grep checks for scanf format strings containing %[0-9]+mc where the width exceeds 1024.

Typical attack path

1. Identify a Linux application or service using GNU C Library versions 2.7 through 2.43.
2. Determine whether the application parses attacker-controlled data using scanf-family functions.
3. Find a reachable format string using the GNU %m allocation modifier with the c conversion and an explicit field width greater than 1024, such as %2048mc.
4. Send crafted input that reaches the vulnerable parser and triggers the oversized character match.
5. Cause a one-byte heap overflow during glibc input conversion.
6. Observe denial of service through crashes, or attempt repeated inputs to manipulate heap state for more advanced exploitation.
7. If exploitation is successful, execute code or alter application behavior with the privileges of the affected process.

How to detect it

There are no universal network indicators or payload signatures because exploitation depends on the specific application format string and input protocol. To assess whether exploitation may already have occurred, focus on application and system evidence of abnormal crashes in services that parse untrusted input. Review system journals, syslog, application logs, container logs, kernel logs, core-dump records, and EDR telemetry for heap-corruption messages, segmentation faults, aborts from glibc malloc checks, or repeated crashes after unusually large input records. Investigate services that show crashes in or near scanf, __vfscanf_internal, __isoc99_scanf, __isoc99_sscanf, __isoc99_fscanf, or related libc parsing functions. Examine core dumps, crash backtraces, and sanitizer output for one-byte heap overflows or heap metadata corruption originating from scanf-family functions. Correlate crash timestamps with inbound requests, uploaded files, message queues, or other untrusted input sources containing large fields around or above 1024 bytes. If threat hunting at source or binary level, search for format strings matching %[0-9]+mc with widths greater than 1024, especially in network-facing or file-ingestion components. Because the issue is not currently in KEV and no mature public exploit is reported, detection should emphasize anomaly-based crash investigation and vulnerable-code discovery rather than fixed IOC matching.

• %mc
• __vfscanf_internal
• __isoc99_scanf
• __isoc99_sscanf
• __isoc99_fscanf
• malloc(): corrupted top size
• malloc(): invalid size
• malloc(): memory corruption
• free(): invalid next size
• free(): invalid pointer
• corrupted size vs. prev_size
• double free or corruption
• munmap_chunk(): invalid pointer
• Segmentation fault
• Aborted (core dumped)
• libc.so.6

What your security team should do

• Inventory Linux hosts, containers, appliances, and base images that include GNU C Library versions 2.7 through 2.43.
• Track operating-system and distribution advisories for the glibc fix and prioritize patching internet-facing systems, parsers, file-ingestion services, and privileged daemons.
• Ask application teams to search for scanf-family usage with malloc-allocation character conversions such as %mc and explicit widths greater than 1024.
• Patch or rebuild container images and redeploy workloads; do not rely only on host-level glibc patching for containerized applications.
• Restart affected services or reboot systems after glibc updates so running processes load the fixed library.
• Monitor crash logs and core-dump telemetry for heap corruption in services that parse untrusted input.
• Treat confirmed crashes in reachable parsers as potentially security-relevant even though current EPSS is low and no KEV exploitation is reported.
• Add secure-coding checks to prevent future use of unsafe scanf parsing patterns with large explicit widths.