Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🛡️
Not in CISA KEV
MEDIUM severity

CVE-2026-58012 — glib

MEDIUM

CVE-2026-58012 is a medium-severity (CVSS 6.5) CWE-126 vulnerability. A fix is available — see the affected versions and patch details below.

Glib: buffer over-read in g_regex_replace() via glib/gregex.c:string_append() and g_utf8_next_char()

Published
Jun 30, 2026
Updated
Sep 30, 2026
Affected
2 products
Patched
See advisory
Exploits
None indexed
Exploitation data as of Sep 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-58012.

EPSS Exploitation Probability

via FIRST.org ↗
0.9%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs57th percentile — riskier than 57% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-58012 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 380,526 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Description

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.

Affected Products

2 products · 7 configurations
Application
glibgnome
< 2.86.5
1 version
2.88.0
OS
enterprise linuxredhat
5 versions
6.07.08.09.010.0

Detection & mitigation playbook

Vulnerability
  1. Detect

    Identify every host running the affected component and compare the installed build against the fixed version below — for source-built or distro-packaged software the version string, not a lockfile, is the source of truth (`dpkg -l`, `rpm -q`, or the binary's own `--version`).

  2. Fix

    Upgrade the affected component to the fixed release for CVE-2026-58012, or apply your distribution's backported patch — distro builds are often patched at an older version number, so check your vendor's advisory rather than the upstream version alone.

  3. Workarounds

    Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

Any applications that use g_regex_replace() or g_regex_replace_eval() with the G_REGEX_RAW compile flag and allow user-controlled replacement strings containing case-change escapes (\u, \l, \U, \L) are vulnerable to this issue. This flaw can cause a buffer over-read of 1-5 bytes, leading to a minor information…

Workaround published by Red Hat
To mitigate this vulnerability, implement strict input validation to sanitize user-supplied replacement strings, specifically rejecting or escaping case-change modifiers (\u, \l, \U, \L) before calling g_regex_replace() or g_regex_replace_eval() when the G_REGEX_RAW compile flag is used. Removing the G_REGEX_RAW flag or hardcoding the replacement strings will completely neutralize this issue.
Source: Red Hat security advisory for CVE-2026-58012 (CC BY 4.0)
ProductFixed inAdvisory
Red Hat Enterprise Linux 10glib2-0:2.80.4-12.el10_2.21RHSA-2026:57015
Red Hat Enterprise Linux 10.0 Extended Update Supportglib2-0:2.80.4-4.el10_0.17RHSA-2026:65767
Red Hat Enterprise Linux 7 Extended Lifecycle Supportglib2-0:2.56.1-13.el7_9.1RHSA-2026:65773
Red Hat Enterprise Linux 8mingw-glib2-0:2.70.1-9.el8_10RHSA-2026:49512
Red Hat Enterprise Linux 8glib2-0:2.56.4-177.el8_10RHSA-2026:61766
Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Supportglib2-0:2.56.4-10.el8_4.7RHSA-2026:65762
Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Supportglib2-0:2.56.4-158.el8_6.7RHSA-2026:65769
Red Hat Enterprise Linux 8.8 Telecommunications Update Serviceglib2-0:2.56.4-165.el8_8.2RHSA-2026:65771
UbuntuMEDIUM

Frequently Asked Questions

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.
O3 Security · Impact-Aware SCA

Is CVE-2026-58012 in your dependencies?

Find it across , including transitive dependencies.

CVE-2026-58012: glib DoS (Medium 6.5) | O3 Security