CVE-2026-58012: GLib Buffer Over-read in g_regex_replace – MEDIUM Severity
GLib contains a buffer over-read vulnerability in its regex replacement function that occurs when specific compilation flags and string handling options interact. When the `g_regex_replace` function processes matched text with the `G_REGEX_RAW` flag enabled and case-change escape sequences, it attempts to interpret raw byte data as valid UTF-8, leading to reading beyond allocated buffer boundaries. The vulnerability can leak a small amount of adjacent memory and trigger application crashes if the overread crosses memory page boundaries, making it a moderate risk to availability and confidentiality.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
- Weaknesses (CWE)
- CWE-126
- Affected products
- 7 configuration(s)
- Published / Modified
- 2026-06-30 / 2026-08-03
NVD description (verbatim)
A flaw was found in GLib. A buffer over-read can occur in the g_regex_replace function when used with the `G_REGEX_RAW` compile flag and case-change replacement escapes because the string_append function processes matched substrings using UTF-8 functions that assume valid UTF-8 input, even when the string is treated as raw bytes. This vulnerability can cause a minor information disclosure of 1-5 bytes and a denial of service when the buffer over-read crosses a page boundary.
4 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-58012 is a buffer over-read flaw in GLib's regex replacement mechanism. The root cause lies in the string_append function, which applies UTF-8 validation and manipulation functions to matched substrings without accounting for the `G_REGEX_RAW` flag that instructs the regex engine to treat input as raw bytes rather than UTF-8 text. When case-change replacement escapes (e.g., uppercase or lowercase transformations) are combined with this flag, the UTF-8 functions make unsafe assumptions about input validity and advance past the actual end of the matched substring. This over-read can access memory beyond the current allocation. The vulnerability is classified as CWE-126 (Buffer Over-read), indicating unsafe memory access during string processing.
Business impact
Organizations relying on GLib for string processing and regex operations face dual risks: potential disclosure of sensitive data resident in adjacent memory regions (up to 5 bytes per occurrence) and application instability through denial of service when overreads cross page boundaries, forcing a crash. Applications embedding GLib—including many system utilities, development tools, and services—may experience unexpected terminations or leak confidential information if they call g_regex_replace with untrusted regex patterns or input strings. The impact severity is moderated by the requirement for specific flag and escape sequence combinations, which limits broad exploitation but increases risk where those patterns are present in actual code.
Affected systems
GLib itself is affected across versions prior to the fix. Red Hat Enterprise Linux distributions (multiple versions listed) that bundle or depend on the vulnerable GLib version are impacted. Any application or service compiled against or dynamically linking to a vulnerable GLib release is at risk, particularly those executing regex operations on user-supplied or partially-controlled input strings. The vulnerability does not affect systems running patched versions of GLib or distributions that have applied security updates.
Exploitability
Exploitation requires that an application calls g_regex_replace with the `G_REGEX_RAW` compile flag in combination with case-change replacement escapes on attacker-influenced input. This is not a trivial requirement, as the `G_REGEX_RAW` flag is less commonly used in typical regex workflows. An attacker would need to craft a regex pattern or input string designed to trigger the unsafe code path. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U) indicates network accessibility and low attack complexity, but the conditional nature of the vulnerability (specific flag combination required) means real-world exploitability depends on how target applications actually use the regex API. No public exploit code or active exploitation has been documented at this time.
Remediation
Apply security updates from your vendor. Red Hat Enterprise Linux users should install patched GLib packages via yum or dnf from RHEL security advisories. Developers maintaining applications that call g_regex_replace should verify their code does not combine `G_REGEX_RAW` with case-change replacement escapes, or update to a patched GLib version. System administrators should prioritize patching systems that execute untrusted regex patterns or expose regex functionality to user input. If immediate patching is not feasible, disable or restrict regex operations accepting external input patterns until updates are deployed.
Patch guidance
Consult your Linux distribution's official security advisories and repositories for the patched GLib version. Red Hat has released security updates for affected RHEL versions; verify the specific patch version by checking the RHEL Security Advisory corresponding to CVE-2026-58012. Ubuntu, Debian, and other distributions will provide updates through their respective package management systems. Developers should upgrade GLib to the version that fixes this buffer over-read in string_append. After patching, restart affected services or applications to ensure they load the corrected library.
Detection guidance
Look for application crashes or segmentation faults in services using GLib, particularly regex-heavy components. Audit application source code and linked libraries to identify use of g_regex_replace with `G_REGEX_RAW` flag combined with case-change escape sequences. Monitor system logs for unexpected application terminations. Security Information and Event Management (SIEM) systems can flag crashes in services known to use GLib. Verify current GLib versions in production using package management queries (e.g., `dpkg -l | grep libglib` on Debian/Ubuntu, `rpm -qa | grep glib2` on RHEL). Conduct threat modeling on applications that accept user-supplied regex patterns.
Why prioritize this
This vulnerability merits prompt but not emergency attention. The CVSS score of 6.5 (MEDIUM) reflects the dual risk of information disclosure and denial of service. However, exploitation requires specific API usage patterns (G_REGEX_RAW with case-change escapes), which reduces the blast radius compared to more commonly-exploited functions. Organizations should prioritize patching systems that parse or validate untrusted input via regex, handle sensitive data, or face high availability requirements. Less critical development or internal systems can follow a standard change management window.
Risk score, explained
The CVSS 3.1 score of 6.5 balances several factors: the vulnerability permits both confidentiality (L) and availability (L) impact with no integrity risk, network-accessible attack vector, and no authentication or user interaction required. However, the attack complexity is low only if applications actively use the vulnerable code path; the conditional nature of the flaw (specific flag combination) prevents a higher severity score. The score reflects a moderate-risk condition suitable for standard enterprise patching cycles within 30–60 days, depending on asset criticality.
Frequently asked questions
Can this vulnerability be exploited remotely without authentication?
Yes, if an application exposes g_regex_replace functionality over a network interface without authentication, an attacker can send crafted input to trigger the vulnerability. However, the attacker must also ensure the vulnerable code path is active (G_REGEX_RAW flag with case-change escapes), which narrows the attack surface.
Will patching GLib automatically fix my application?
Patching the system's GLib library will protect dynamically-linked applications once they are restarted and load the patched version. Statically-linked applications or those with embedded GLib code will require recompilation against the patched GLib source. Verify your application's linking mode and rebuild as needed.
What is the G_REGEX_RAW flag, and why is it relevant?
The G_REGEX_RAW flag instructs GLib's regex engine to treat input as raw bytes without UTF-8 interpretation. This is useful for binary data or legacy encodings, but the vulnerability arises because the string_append function still applies UTF-8 transformations internally, creating an inconsistency that leads to buffer overreads.
Is this vulnerability being actively exploited in the wild?
As of the last update, CVE-2026-58012 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no public proof-of-concept code has surfaced. However, all organizations should treat it as a priority given the moderate risk profile and the potential for detection evasion in attacks targeting specialized regex usage patterns.
This analysis is based on publicly available information current as of the last update. CVSS scores, severity ratings, and affected product lists are derived from official CVE records and vendor advisories. Specific patch versions and remediation steps must be verified against your vendor's official security bulletin. No exploit code or weaponized proof-of-concept is provided. Organizations should consult their internal risk management policies and vendor guidance before applying patches. This page does not constitute professional security advice; engage qualified security personnel for your organization's vulnerability assessment and remediation planning. Source: NVD (public-domain), retrieved 2026-08-09. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-58010MEDIUMGLib Off-by-One Bounds Check Vulnerability – Information Disclosure and DoS
- CVE-2026-58013MEDIUMGLib Buffer Over-read in Line Terminator Parsing
- CVE-2026-11787MEDIUM389 Directory Server Buffer Over-read in LDAP Filter Parsing
- CVE-2026-12549MEDIUMGNOME libsoup Range Request Regression Leading to DoS and Log Flooding
- CVE-2026-1764MEDIUMGNOME localsearch MP3 Parser Heap Buffer Over-Read Vulnerability
- CVE-2026-1766MEDIUMGNOME Localsearch MP3 Heap Buffer Overflow & Memory Leak
- CVE-2026-1767MEDIUMGNOME Localsearch MP3 Parser Heap Overflow – Patching Guide
- CVE-2026-58011MEDIUMGLib Out-of-Bounds Read in Date-Time Handling (CVSS 6.5)