CVE-2026-58014

What it actually does

The flaw is an off-by-one memory access in GLib's key-file parser, specifically in g_key_file_get_locale_string_list() in gkeyfile.c when processing a key file containing an empty value. If an application uses GLib to parse attacker-controlled or untrusted key files, the parser may read or access one byte out of bounds. In most cases this is expected to cause a crash or denial of service; in edge cases, limited adjacent-memory exposure or minor memory corruption effects may be possible, consistent with the CVSS confidentiality, integrity, and availability impact ratings.

Why it matters to the business

Applications and services that rely on GLib to parse configuration, desktop-entry, metadata, plugin, or other key-file-style content could be crashed by a crafted input file. Because GLib is widely used across GNOME/Linux userland and Red Hat Enterprise Linux ecosystems, exposure may be indirect through many applications rather than only through GLib itself. The vulnerability is not currently listed in CISA KEV and EPSS is low, but public exploit availability increases the need to prioritize patching internet-facing or automated file-processing workloads.

How an attack unfolds

An attacker first identifies an application or service that uses GLib's key-file APIs and accepts key-file-like input from an untrusted source, such as uploaded metadata, imported configuration, plugin descriptors, package metadata, desktop-entry files, or network-delivered content. The attacker supplies a crafted key file containing an empty value that reaches g_key_file_get_locale_string_list(). When GLib parses the value, the off-by-one condition causes a one-byte out-of-bounds access. If that access crosses a memory page boundary or triggers memory-safety checks, the process can terminate, causing denial of service. Exploitation is most practical against applications that automatically parse attacker-supplied files without user review, especially long-running services, sandbox helpers, indexers, or batch processors.

How to fix it

Upgrade GLib and any vendor-distributed packages that include GLib to a version containing the vendor fix once available. For Red Hat Enterprise Linux and other distributions, apply the appropriate security errata/backported package rather than relying only on upstream version numbers, since enterprise distributions often patch without changing to the latest upstream release. Where immediate patching is not possible, reduce exposure by preventing untrusted users from supplying key-file-style input to vulnerable applications, disabling automated parsing of untrusted configuration/metadata/plugin files, enforcing file-type validation, running parsers with least privilege, and using service isolation, seccomp/AppArmor/SELinux, and crash-restart rate limits to limit denial-of-service impact.

How to confirm the fix worked

Confirm the installed GLib package is at a vendor-fixed build level using the operating system package manager and vendor advisory metadata. On Linux systems, check package versions for glib2/libglib2.0 packages and verify the installed package changelog or security advisory references the fix for this issue. Validate that applications accepting untrusted key-file-like content have been restarted or rebuilt against the patched library where required. For higher-assurance testing, run a non-production parser or affected workflow against a benign regression test containing empty key-file values and confirm it no longer crashes under normal execution or under AddressSanitizer/Valgrind-style memory checking.

Typical attack path

1. Identify software that uses GLib key-file parsing and accepts externally supplied key-file content.
2. Craft a key file containing an empty value that is processed through g_key_file_get_locale_string_list().
3. Deliver the file through an upload, import, synchronization, plugin, package, metadata, or network-processing path.
4. Trigger parsing by the vulnerable application or service.
5. Cause an out-of-bounds access, resulting in a crash or denial of service, and potentially limited memory-safety side effects depending on process layout and protections.

How to detect it

Look for evidence of crashes or abnormal termination in applications that use GLib shortly after processing uploaded, imported, synchronized, or newly discovered key-file-style content. Relevant log sources include systemd journal, syslog, application logs, crash reporters such as ABRT/apport/systemd-coredump, container runtime logs, EDR process telemetry, and web or file-processing pipeline logs that record submitted filenames and parsing errors. Search for segmentation faults, SIGSEGV/SIGABRT, core dumps, or sanitizer findings involving GLib key-file parsing functions, especially g_key_file_get_locale_string_list or gkeyfile.c. Correlate crash timestamps with inbound file uploads, plugin installations, metadata imports, package processing, desktop-entry parsing, or repeated submissions from the same source. There are no reliable network-only indicators for this vulnerability because exploitation is data-driven and depends on the application path that passes attacker-controlled content into GLib.

• g_key_file_get_locale_string_list
• gkeyfile.c
• GLib-GIO
• GLib-CRITICAL
• GLib-WARNING
• Segmentation fault
• SIGSEGV
• SIGABRT
• core dumped
• systemd-coredump
• Process terminated by signal 11
• heap-buffer-overflow
• global-buffer-overflow
• AddressSanitizer
• runtime error: index out of bounds
• key file
• empty value

What your security team should do

• Inventory systems and applications that use GLib, prioritizing Linux desktop services, file indexers, upload/import pipelines, plugin loaders, package processors, and network-facing services that parse user-supplied files.
• Patch GLib through vendor-supported packages as soon as fixed builds are available, prioritizing internet-facing and automated file-processing systems because exploit code is reported as available.
• Review application input paths for key-file-style formats and restrict or sanitize untrusted empty values until patching is complete.
• Enable process isolation and least-privilege controls for services that parse externally supplied files to reduce the impact of crashes or memory-safety faults.
• Monitor for repeated crashes in GLib-based applications, especially following file uploads, imports, synchronization events, or plugin/metadata processing.
• If crashes are observed, preserve the triggering files, core dumps, application logs, and package versions for forensic review before cleanup.