CVE-2026-58011

What it actually does

This flaw is a small out-of-bounds read in GLib's GDateTime handling. An invalid GDateTime object can be produced by g_date_time_add_full and later processed by g_date_time_get_ymd in glib/gdatetime.c, causing a 2-byte read outside the expected object bounds. The most likely technical outcomes are corrupted date values, incorrect downstream logic decisions, assertion failures, crashes, or denial of service in applications that rely on GLib date/time arithmetic. The flaw does not directly provide code execution based on the current description, and the stated impact is limited to integrity and availability.

Why it matters to the business

Applications, daemons, desktop components, and services built on GLib may become unreliable if they process attacker-controlled or malformed date/time values. In affected applications, this could cause service interruptions, incorrect scheduling or expiration logic, failed jobs, or crashes. The CVSS score is moderate at 6.5, EPSS is low at 0.0036, it is not listed in CISA KEV, and no public exploit maturity is currently reported, so broad emergency response is not indicated; however, GLib is widely used as a foundational Linux and GNOME ecosystem library, so fixes should be prioritized through normal operating system and application dependency patch cycles.

How an attack unfolds

An attacker would need to reach an application or service that accepts date/time-related input and uses GLib GDateTime APIs internally. The attacker supplies input or triggers workflow conditions that cause the application to call g_date_time_add_full in a way that creates an invalid GDateTime object. If the same object is later passed to g_date_time_get_ymd, GLib can read 2 bytes beyond the valid object boundary. The read may corrupt the returned year, month, or day values, which can then cause the application to make incorrect decisions or encounter an error condition. In vulnerable code paths, repeated triggering can be used to crash the process or degrade availability. There are no currently identified threat actors, ransomware campaigns, or public exploitation reports associated with this CVE in the provided data.

How to fix it

Apply the GLib update supplied by the operating system vendor, Linux distribution, application vendor, or upstream GLib project once available. Because no exact fixed versions were provided, track vendor advisories for GLib packages and update all affected runtime and development packages, including common package names such as glib2, libglib2.0-0, libglib2.0-bin, libglib2.0-dev, and equivalent distribution-specific packages. Restart services and applications that dynamically link to GLib after patching; in some environments, a full reboot is the safest way to ensure all long-running processes load the patched library. For statically linked applications or bundled runtimes, rebuild or replace the application package with a version that includes the corrected GLib code. Where immediate patching is not possible, reduce exposure by validating date/time inputs, rejecting extreme or malformed date arithmetic values, disabling untrusted scheduling/date-processing features where feasible, and applying rate limits to unauthenticated endpoints that exercise date/time parsing or recurrence logic.

How to confirm the fix worked

Confirm the installed GLib package version against the fixed version published by the relevant operating system or application vendor. Use package-manager queries such as rpm -q glib2, dpkg -l 'libglib2.0*', apk info glib, or equivalent tooling to verify the patched build is installed. Confirm running processes have reloaded the patched library by restarting affected services or checking open library mappings with tools such as lsof, /proc/<pid>/maps, or distro-provided needs-restarting utilities. If source-level validation is available, confirm the GLib gdatetime.c fix is present and that tests covering invalid GDateTime results from g_date_time_add_full followed by g_date_time_get_ymd no longer crash or return corrupted values. Application-level validation should include fuzz or boundary testing of date/time, duration, recurrence, timezone, and scheduling inputs that previously reached GLib GDateTime code paths.

Typical attack path

1. Identify an exposed application, service, or component that uses GLib date/time processing.
2. Find an input path or workflow where untrusted date, time, duration, timezone, recurrence, scheduling, or expiration data is processed.
3. Submit crafted or boundary-case date/time values that cause g_date_time_add_full to produce an invalid GDateTime object.
4. Trigger a later code path that calls g_date_time_get_ymd on that invalid object.
5. Cause corrupted date output, application logic errors, process instability, or denial of service.
6. Repeat the request or workflow to sustain disruption if the vulnerable code path is remotely reachable.

How to detect it

To determine whether this was already exploited or triggered, review application logs, service manager logs, crash reports, core dumps, endpoint telemetry, and observability traces for crashes or exceptions in GLib-linked processes involving GDateTime functions. Relevant log sources include systemd journal, syslog, application error logs, container stdout/stderr, Kubernetes pod restart history, crash reporters such as ABRT, apport, systemd-coredump, macOS or desktop crash logs where applicable, and EDR process-crash telemetry. Look for stack traces referencing g_date_time_get_ymd, g_date_time_add_full, gdatetime.c, libglib-2.0, or GLib assertions shortly after requests or jobs containing unusual date/time, timezone, duration, recurrence, scheduling, or expiration values. Network and application telemetry should be reviewed for repeated requests with extreme years, negative or very large durations, malformed timezone offsets, unusual recurrence intervals, or boundary date values immediately preceding process crashes. Because this is a memory-safety read with no provided public exploit signature, reliable detection is most likely through crash correlation, stack traces, sanitizer findings, and repeated triggering patterns rather than a single definitive network IOC.

• g_date_time_get_ymd
• g_date_time_add_full
• glib/gdatetime.c
• gdatetime.c
• libglib-2.0
• GLib-GDateTime
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: global-buffer-overflow
• runtime error: load of address
• systemd-coredump
• Process dumped core
• Segmentation fault
• SIGSEGV
• g_date_time_get_ymd()
• g_date_time_add_full()

What your security team should do

• Inventory systems and applications that include GLib, especially internet-facing services, automation platforms, scheduling systems, message processors, and applications that accept user-controlled date/time input.
• Monitor vendor advisories for exact fixed GLib versions and deploy updates through standard patch management once available.
• Prioritize patching for externally reachable services and high-availability systems where a process crash or incorrect date logic would cause operational impact.
• Restart or reboot patched systems to ensure long-running processes are no longer using vulnerable GLib library mappings.
• Ask application owners to identify externally reachable workflows that process dates, durations, timezones, recurrence rules, certificates, token expirations, scheduling metadata, or calendar-like input through GLib-backed components.
• Add regression and fuzz testing for edge-case date/time arithmetic in products or services that directly use GLib GDateTime APIs.
• Enable crash monitoring and alerting for GLib-linked services, especially repeated crashes containing g_date_time_get_ymd, g_date_time_add_full, or gdatetime.c in stack traces.
• Because EPSS is low, the issue is not in CISA KEV, and no known exploit maturity is reported, handle this as a normal-priority dependency remediation unless the vulnerable code path is exposed to untrusted network input or supports critical operations.