CVE-2026-58015

What it actually does

The flaw is a client-side path traversal in GLib's implementation of the D-Bus DBUS_COOKIE_SHA1 SASL authentication mechanism. During authentication, a D-Bus server supplies a cookie_context value that should identify a cookie file under the user's D-Bus keyring area. Vulnerable clients fail to validate that value, allowing a malicious server to include traversal sequences such as ../ and cause the client to read unintended local files. The attacker does not receive the file directly, but can use the authentication hash response as an oracle to confirm guessed file contents, which can expose sensitive data when target file content is predictable, low entropy, or partially known. Integrity and availability are not directly affected.

Why it matters to the business

An attacker who can cause GLib-based software to connect to a malicious D-Bus server may be able to extract or confirm sensitive local information from affected systems. The practical risk is lower than a straightforward arbitrary file read because exploitation requires control of the server side of the D-Bus authentication flow and content guessing, but GLib is widely used across Linux desktop and server software, including Red Hat Enterprise Linux ecosystems, so exposure can be broad and embedded in many applications. There is currently no CISA KEV listing and EPSS is low, but exploit code is reported available, making timely patching advisable for systems that run GLib clients or connect to remote or nonstandard D-Bus endpoints.

How an attack unfolds

An attacker first positions a malicious D-Bus server where a vulnerable GLib-based client will connect, such as through a spoofed, redirected, or attacker-controlled D-Bus address. When the client begins SASL authentication and offers or accepts DBUS_COOKIE_SHA1, the server sends a crafted cookie_context containing path traversal sequences. The vulnerable client uses that value to construct the cookie file path without sufficient validation and reads a file outside the intended D-Bus keyring location. The client then computes and returns an authentication hash derived from the cookie material and the server challenge. Because the attacker controls the challenge and observes the response, they can test guesses about the target file content offline or through repeated attempts. Successful exploitation is most realistic for files with known structure, limited entropy, or guessable secrets rather than arbitrary high-entropy secrets.

How to fix it

Upgrade GLib packages to vendor-fixed versions as soon as they become available for the affected distribution or product stream. Because no exact fixed versions were provided in the input, use the relevant operating system or distribution security advisory for gnome glib and Red Hat Enterprise Linux package names and versions. Where immediate patching is not possible, reduce exposure by preventing applications from connecting to untrusted or remote D-Bus servers, avoiding untrusted DBUS_SESSION_BUS_ADDRESS or DBUS_SYSTEM_BUS_ADDRESS values, restricting environment variable injection into services, and limiting outbound access to attacker-controlled D-Bus endpoints. Prefer stronger or properly constrained D-Bus authentication mechanisms where configurable, and restart affected applications or reboot hosts after package updates to ensure vulnerable GLib libraries are no longer loaded.

How to confirm the fix worked

Confirm installed GLib packages match the fixed versions from the operating system or vendor advisory. On Linux systems, validate package state with distribution package tooling such as rpm, dnf, yum, apt, or vendor vulnerability scanners, and confirm running processes have been restarted so they are not still mapped to an old libglib or libgio shared library. Test exposure by reviewing whether GLib-based applications can be made to connect to nonstandard or remote D-Bus addresses and whether DBUS_COOKIE_SHA1 is enabled or observed. For defensive testing, a controlled malicious D-Bus server can be used in a lab to verify that traversal values in cookie_context are rejected and do not cause file opens outside the intended D-Bus keyring directory.

Typical attack path

1. Identify software using vulnerable GLib D-Bus client-side authentication.
2. Cause or wait for the client to connect to an attacker-controlled D-Bus server or endpoint.
3. Negotiate or trigger the DBUS_COOKIE_SHA1 SASL authentication mechanism.
4. Send a crafted cookie_context value containing path traversal sequences such as ../ to reference a file outside the intended keyring directory.
5. Receive the client's authentication response generated from the unintended file content.
6. Use the response as a verification oracle to confirm guessed file contents or recover predictable sensitive data through repeated attempts.
7. Use any recovered or confirmed sensitive information for follow-on access, reconnaissance, or credential attacks.

How to detect it

To determine whether exploitation may already have occurred, focus on evidence of vulnerable clients connecting to unexpected D-Bus servers and authentication exchanges using DBUS_COOKIE_SHA1 with traversal-like cookie contexts. Useful sources include systemd journal logs, application debug logs, D-Bus broker or dbus-daemon logs if verbose authentication logging was enabled, shell and service environment captures showing unusual DBUS_SESSION_BUS_ADDRESS or DBUS_SYSTEM_BUS_ADDRESS values, proxy/firewall logs for unexpected D-Bus-over-TCP connections, and endpoint telemetry for file-open activity by GLib-based processes. File access monitoring from auditd, eBPF, EDR, or Sysmon for Linux is especially valuable: look for processes opening files outside the expected ~/.dbus-keyrings directory immediately after connecting to an unusual D-Bus endpoint. Because the attack leaks data through a hash oracle rather than writing files or spawning processes, absence of dropped files does not rule out exploitation. Investigate repeated failed or short-lived D-Bus authentication attempts, hex-encoded traversal sequences in D-Bus auth traffic, and any process whose environment points D-Bus traffic to an untrusted path, abstract socket, or TCP address.

• DBUS_COOKIE_SHA1
• AUTH DBUS_COOKIE_SHA1
• ~/.dbus-keyrings
• /.dbus-keyrings/../
• ../
• ..\\
• 2e2e2f
• 2e2e5c
• DBUS_SESSION_BUS_ADDRESS=tcp:
• DBUS_SYSTEM_BUS_ADDRESS=tcp:
• unix:path=/tmp/
• unix:abstract=

What your security team should do

• Prioritize patching GLib on Linux systems that run desktop sessions, user services, automation agents, or applications that initiate D-Bus client connections.
• Monitor vendor advisories for exact fixed package versions for gnome glib and Red Hat Enterprise Linux, then deploy through normal OS patch channels.
• Inventory systems and containers that include GLib, because the library is commonly pulled in as a dependency even when not directly managed by application teams.
• Restrict opportunities for untrusted D-Bus endpoint selection by hardening service environments and preventing untrusted users or inputs from setting DBUS_SESSION_BUS_ADDRESS, DBUS_SYSTEM_BUS_ADDRESS, or related launch configuration.
• Hunt for unusual D-Bus client connections to nonstandard addresses, especially TCP-based or user-controlled endpoints, and suspicious DBUS_COOKIE_SHA1 authentication attempts containing traversal patterns.
• After patching, restart affected services, user sessions, and long-running applications, or reboot where process-level restart coverage is uncertain.