CVE-2026-58010

What it actually does

The flaw is an off-by-one bounds-check error in GLib's GVariant serialization validation logic, specifically in gvs_tuple_is_normal in glib/gvariant-serialiser.c. When GLib checks alignment padding for a tuple, it uses an incorrect comparison that can permit a one-byte out-of-bounds read. In most cases this results in a very small information disclosure of adjacent memory; if the read lands across an unmapped page boundary, the process using GLib can crash, causing denial of service. Impact depends on which application, daemon, or service parses attacker-controlled GVariant data through the vulnerable GLib code path.

Why it matters to the business

Organizations running software built on vulnerable GLib versions may be exposed to crashes or limited memory disclosure when network-facing or message-processing applications parse malicious serialized data. The most likely operational consequence is service instability or denial of service in applications that consume untrusted GVariant inputs, including components using D-Bus-style messaging or GLib serialization. Although the disclosed memory is limited to one byte and no known exploitation is reported, GLib is widely embedded across Linux desktop, server, and middleware stacks, so exposure may exist indirectly through dependent software.

How an attack unfolds

An attacker needs a path to provide crafted serialized GVariant data to an application or service linked against a vulnerable GLib version. The attacker constructs a tuple payload with alignment padding arranged so the flawed normal-form validation reaches the boundary condition where the code permits a one-byte read beyond the valid buffer. If the adjacent byte is mapped and readable, the process may disclose or internally use one byte of unintended memory, depending on the caller and error-handling behavior. If the byte lies across a page boundary into unmapped memory, the process can fault and terminate. Practical exploitation is therefore most relevant against services that accept untrusted serialized GLib/GVariant data over a network, IPC boundary, file import path, plugin interface, or message bus endpoint.

How to fix it

Upgrade GLib packages to the vendor-provided fixed release for each affected operating system or distribution as soon as updates are available. Because no exact fixed versions were provided in the input, use distribution security advisories and package repositories to identify the patched glib2/libglib package version for each platform. Rebuild or redeploy statically linked applications that embed GLib rather than dynamically linking to the system package. Where immediate patching is not possible, reduce exposure by blocking untrusted GVariant input, restricting access to services that parse GLib serialized data, validating message/file inputs before passing them to GLib, and applying process isolation, sandboxing, and restart limits to reduce denial-of-service impact.

How to confirm the fix worked

Confirm remediation by inventorying GLib versions on affected systems and verifying that installed packages match the fixed versions from the relevant Linux distribution or software vendor advisory. For dynamically linked software, confirm applications resolve to the patched system GLib library using package manager queries and runtime linker inspection. For containers and appliances, rebuild base images and rescan to ensure vulnerable GLib packages are no longer present. For statically linked binaries, confirm the application was rebuilt with a patched GLib source. Where safe and appropriate in a test environment, run a regression or proof-of-concept malformed GVariant input against representative services to verify the process no longer crashes and the vulnerable code path is patched.

Typical attack path

1. Identify an application, daemon, or service that uses GLib GVariant parsing and accepts attacker-controlled serialized data.
2. Determine whether the target is linked against a vulnerable GLib build.
3. Craft a malformed GVariant tuple that triggers the off-by-one alignment padding check in gvs_tuple_is_normal.
4. Deliver the payload through the exposed input path, such as a network protocol, IPC/message-bus interface, file parser, or API endpoint.
5. Trigger GLib normal-form validation or deserialization of the crafted tuple.
6. Cause either a one-byte out-of-bounds read or a process crash if the read crosses into an unmapped page.

How to detect it

To determine whether exploitation already occurred, review crash telemetry, core dumps, application logs, system journals, and monitoring alerts for processes linked against GLib that terminated during GVariant parsing. Focus on services that accept untrusted serialized data, message-bus traffic, imported files, or network requests. Useful log sources include systemd journal, syslog, application-specific logs, crash reporters such as ABRT/apport/systemd-coredump, container runtime logs, endpoint detection telemetry, and reverse proxy or API gateway logs for malformed request bursts preceding crashes. Investigate crashes with stack traces referencing gvs_tuple_is_normal, g_variant_is_normal_form, g_variant_get_normal_form, or glib/gvariant-serialiser.c. Correlate crash times with unusual client IPs, repeated malformed payload submissions, IPC/message-bus errors, or repeated restarts of the same service. There are no widely published exploitation artifacts, actor-specific indicators, or ransomware associations for this vulnerability in the provided data, so detection should rely on behavioral evidence of malformed GVariant parsing and process crashes rather than fixed network signatures.

• gvs_tuple_is_normal
• g_variant_is_normal_form
• g_variant_get_normal_form
• glib/gvariant-serialiser.c
• GLib-GIO
• GLib-CRITICAL
• GLib-ERROR
• systemd-coredump
• segfault
• SIGSEGV
• core dumped
• gvariant-serialiser

What your security team should do

• Prioritize patching systems where GLib is used by network-facing services, message-processing daemons, IPC brokers, file import services, or automation that handles untrusted data.
• Track vendor and Linux distribution advisories for the exact patched GLib package versions and apply them through normal package management channels.
• Inventory containers, appliances, embedded Linux images, and statically linked applications because they may not inherit the host operating system's patched GLib library.
• Monitor for unexpected crashes in applications linked to GLib, especially crashes involving GVariant parsing or the gvs_tuple_is_normal function.
• Restrict unauthenticated or untrusted access to services that accept serialized GVariant or D-Bus-like messages until patches are deployed.
• Because the issue is not in CISA KEV and has low EPSS at the time of assessment, treat it as routine-to-expedited patching unless exposed in a critical or internet-facing parser.