CVE-2026-58012: Gnome Glib Information Disclosure Flaw

CVE-2026-58012 Overview

CVE-2026-58012 is a buffer over-read vulnerability in GLib, the low-level core library used by GNOME and many Linux applications. The flaw resides in the g_regex_replace function when invoked with the G_REGEX_RAW compile flag combined with case-change replacement escapes. Under these conditions, the internal string_append helper processes matched substrings using UTF-8 aware routines that assume valid UTF-8 input, even though the data is being treated as raw bytes. Attackers who supply crafted input can trigger a 1-5 byte buffer over-read, causing minor information disclosure and, when the read crosses a page boundary, denial of service.

Critical Impact
Remote attackers can trigger memory disclosure and application crashes in any process using GLib regex with raw byte mode and case-change replacement escapes.

Affected Products

GNOME GLib (through 2.88.0)
Red Hat Enterprise Linux 6, 7, 8, 9, and 10
Downstream applications and services linked against vulnerable GLib versions

Discovery Timeline

2026-06-30 - CVE-2026-58012 published to the National Vulnerability Database
2026-07-02 - CVE-2026-58012 record last modified in NVD

Technical Details for CVE-2026-58012

Vulnerability Analysis

The vulnerability is classified as a buffer over-read [CWE-126] in GLib's regular expression engine. GLib exposes Perl-compatible regex functionality through the GRegex API. When callers compile a pattern with G_REGEX_RAW, GLib treats the subject string as a sequence of raw bytes rather than a validated UTF-8 sequence. The replacement path in string_append does not honor this contract. It calls UTF-8 traversal functions that expect valid multi-byte sequences to determine character boundaries during case-change substitution.

When the matched substring contains bytes that look like the start of a multi-byte UTF-8 character, the UTF-8 helper advances past the end of the intended slice. This reads 1 to 5 bytes beyond the allocated buffer. If the buffer lies at the end of a memory page and the next page is unmapped, the process crashes with a segmentation fault, producing denial of service. Otherwise, the extra bytes may be written into the output string, exposing adjacent heap contents to the caller.

Root Cause

The root cause is a mismatch between the encoding contract established by G_REGEX_RAW and the character-processing routines used during replacement. Case-change escape sequences such as \U, \L, \u, and \l in the replacement template trigger the vulnerable code path that indexes past the matched slice using UTF-8 arithmetic.

Attack Vector

Exploitation requires that an attacker control either the regex pattern, the replacement string, or the subject data passed to g_regex_replace in a program that enables G_REGEX_RAW. Because GLib is embedded in many network-facing services, parsers, and desktop components, attacker-supplied data reaching a vulnerable call site can trigger the over-read remotely and without authentication.

No public proof-of-concept exploit has been published. Technical details are tracked in the GNOME GitLab issue #3918 and the Red Hat CVE Advisory.

Detection Methods for CVE-2026-58012

Indicators of Compromise

Segmentation faults or SIGSEGV crashes in processes that link against libglib-2.0 while parsing untrusted input
Anomalous output from services performing regex substitution that includes unexpected binary bytes
Repeated crashes in the same GLib-backed daemon shortly after receiving crafted network payloads

Detection Strategies

Inventory installed GLib packages across Linux hosts and compare against fixed versions distributed by your vendor
Audit application source and dependencies for calls to g_regex_new with the G_REGEX_RAW flag paired with replacement templates containing \U, \L, \u, or \l
Run fuzzing harnesses against services that expose regex functionality to untrusted callers

Monitoring Recommendations

Forward core dump and crash telemetry from Linux endpoints into a centralized data lake for correlation
Alert on repeated crashes of the same GLib-linked binary from a single source address
Track package versions of glib2 through configuration management to detect unpatched hosts

How to Mitigate CVE-2026-58012

Immediate Actions Required

Apply vendor updates for GLib as soon as they are available from your distribution
Identify all applications that call g_regex_replace with G_REGEX_RAW and case-change escapes, and treat them as high priority for patching
Restrict untrusted input from reaching vulnerable regex call sites until patches are deployed

Patch Information

Red Hat is tracking the issue in Bugzilla 2492247 and will publish fixed packages for supported Red Hat Enterprise Linux releases through the Red Hat CVE Advisory. Upstream fixes are being coordinated through GNOME GitLab issue #3918. Consult your distribution's advisories for RHEL 6, 7, 8, 9, and 10 for the specific glib2 package versions that contain the fix.

Workarounds

Remove the G_REGEX_RAW compile flag where the subject data can be validated as UTF-8
Strip or reject replacement templates containing \U, \L, \u, or \l when the pattern was compiled with G_REGEX_RAW
Validate and sanitize untrusted input length and encoding before passing it to GLib regex functions

bash

# Example: check installed GLib version on Red Hat Enterprise Linux
rpm -q glib2

# Example: search a codebase for potentially vulnerable call sites
grep -rnE "G_REGEX_RAW|g_regex_replace" ./src