CVE-2026-5928

What it actually does

GNU C Library 2.43 and earlier contains a flaw in the wide-character pushback path used by ungetwc(). In _IO_wdefault_pbackfail, glibc may reference the regular byte-stream read pointer instead of the wide-stream read pointer. In programs that call ungetwc() on FILE streams using certain non-Unicode character encodings with overlapping single-byte and multibyte representations, this can cause a read before an allocated buffer or a NULL-pointer-related crash. The practical outcomes are process denial of service and, in narrower conditions, potential disclosure of adjacent heap memory to the affected process or its output path.

Why it matters to the business

Services and command-line tools linked against vulnerable glibc versions may crash when they process specially crafted input through vulnerable wide-character stream handling. The highest business risk is availability loss for exposed parsing, ingestion, gateway, mail, file-processing, localization, or text-conversion workloads that accept untrusted input. Data exposure is possible in constrained circumstances if neighboring heap bytes are surfaced through application behavior, but exploitation depends on application-specific use of ungetwc(), locale/encoding configuration, and how output is handled. This issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS, so remediation should be planned and prioritized based on exposure of externally reachable services and critical workloads rather than treated as confirmed widespread exploitation.

How an attack unfolds

An attacker first needs to reach software that is dynamically or statically linked with an affected glibc version and that processes attacker-controlled text through wide-character FILE stream APIs, specifically a code path that can call ungetwc(). The attacker then supplies input encoded in a character set where single-byte and multibyte sequences can overlap in a way that causes glibc to make a spurious match during wide-character pushback. Because the vulnerable code consults the normal byte-stream pointer instead of the wide-stream pointer, the operation may reference memory before the intended buffer or dereference an uninitialized/NULL pointer. In the common observable case, the target process terminates with a segmentation fault or abort, causing denial of service. In less common application-dependent cases, bytes adjacent to heap allocations may be read and could be exposed if the application subsequently logs, returns, or otherwise emits the affected data.

How to fix it

Upgrade glibc to a vendor-provided version that includes the fix for this issue as soon as it is available for the relevant Linux distribution or appliance platform. Because no fixed upstream version was provided in the input, rely on operating system vendor advisories and package repositories for the corrected glibc build rather than manually replacing libc. After updating glibc, restart affected services and long-running processes, or reboot systems where necessary, because processes already running continue using the old loaded library until restarted. Where immediate patching is not possible, reduce exposure by disabling or restricting untrusted text-processing paths that use wide-character stream APIs, limiting accepted character sets/locales to standard Unicode encodings where feasible, isolating parsers in sandboxed or privilege-reduced workers, applying rate limits to unauthenticated ingestion paths, and using supervisor controls to restart crashed workers without affecting the whole service.

How to confirm the fix worked

Confirm package inventory shows glibc at a vendor-fixed build rather than version 2.43 or earlier without backported patches. Use distribution-specific package metadata, security advisories, and changelogs to verify the CVE is addressed, because enterprise distributions may backport the fix without changing the upstream version number. Confirm all affected services were restarted after the update by checking process start times against the glibc package update time. Where source or binary review is feasible, identify applications that call ungetwc(), fgetwc(), getwc(), or related wide-character FILE APIs and verify they are no longer linked to a vulnerable libc build. For exposure testing, use a controlled non-production harness that exercises ungetwc() under relevant non-Unicode locales and verify the process no longer crashes or reads outside the intended buffer under memory-safety tooling such as AddressSanitizer or Valgrind.

Typical attack path

1. Identify an application or service running on a Linux system using GNU glibc 2.43 or earlier.
2. Confirm or infer that the application processes untrusted text using wide-character stream functions and locales/encodings outside standard Unicode paths.
3. Craft input using a character encoding with overlapping single-byte and multibyte representations to trigger erroneous wide-character pushback behavior.
4. Send the crafted input to the exposed parser, service endpoint, file-ingestion path, or batch-processing workflow.
5. Trigger ungetwc() on the crafted stream, causing a buffer under-read condition or process crash.
6. Observe service interruption, repeated worker crashes, malformed output, or possible leakage of adjacent heap contents depending on the application.

How to detect it

Look for evidence of process crashes or abnormal terminations in applications that process untrusted text, especially when crash timing correlates with specific requests, uploaded files, messages, or batch jobs using unusual character encodings or locale settings. Useful sources include systemd journal logs, syslog, kernel logs, container runtime logs, application error logs, web/API access logs, mail or file-ingestion logs, crash reporters, coredumpctl/systemd-coredump records, and EDR telemetry. In core dumps or stack traces, prioritize crashes that include glibc wide-character stream functions such as _IO_wdefault_pbackfail or ungetwc. Investigate repeated SIGSEGV/SIGABRT events in the same service after receiving malformed or non-Unicode encoded input. If core dumps are available, examine whether the faulting instruction is in libc/libio wide-character handling and whether the input source can be tied to the crash. There are no public exploit-specific network indicators from the provided data, so detection should focus on behavioral evidence: repeated parser crashes, libc stack traces, suspicious character-set headers or file metadata, and anomalous inputs immediately preceding failures.

• ungetwc
• _IO_wdefault_pbackfail
• libio/wgenops.c
• SIGSEGV
• segmentation fault
• Segmentation fault
• systemd-coredump
• core dumped
• libc.so.6
• fgetwc
• getwc
• _IO_read_ptr
• _wide_data->_IO_read_ptr

What your security team should do

• Inventory Linux systems, containers, appliances, and base images using GNU glibc 2.43 or earlier, including statically linked or embedded copies where applicable.
• Prioritize remediation for externally reachable services, file-ingestion systems, text parsers, mail/content gateways, localization-heavy applications, and workloads accepting user-supplied encoded text.
• Track operating system vendor advisories for the fixed glibc package and deploy the vendor update when available; restart services or reboot hosts after patching.
• Search application code and third-party components for use of ungetwc() and related wide-character FILE stream functions to identify the most plausible exposure points.
• Constrain accepted encodings/locales for untrusted input to standard Unicode encodings where operationally feasible, especially until patching is complete.
• Add monitoring for unexplained crashes in services that process text input, particularly segmentation faults in libc wide-character handling paths.
• Treat repeated crashes triggered by similar input sources as potential exploitation attempts and preserve core dumps, request samples, and process logs for investigation.
• Because the issue is not in KEV and has low EPSS with no reported exploit maturity, schedule broad fleet remediation through normal vulnerability management while expediting fixes for internet-facing or business-critical parsers.