CVE-2026-86469

What it actually does

A race condition in GLib2's g_file_replace() when G_FILE_CREATE_REPLACE_DESTINATION is set. If creation of the .goutputstream-XXXXXX temporary file fails, the library unlinks the intended destination and recreates it without exclusive creation (O_EXCL) or symlink/hard-link protections. A local attacker who can write to the destination directory can win that window and redirect the subsequent write to an attacker-chosen path, yielding unauthorized file overwrite (integrity) and possible disruption of the target file or process (availability). Confidentiality is not affected. Attack complexity is high (timing-dependent local race) and requires local privileges plus write access to the directory.

Why it matters to the business

Applications and desktop stacks that use GLib for atomic file replacement (configuration, caches, state, or user data) can have attacker-chosen files overwritten, leading to corrupted configs, broken services, or local integrity loss. GLib2 is foundational on Linux desktops and many server-side tools, so exposure can be broad even though this is a local, high-complexity issue. CVSS 5.3 (medium), EPSS ~0.0014 and flat over 30 days, not listed in CISA KEV, no known ransomware use, and exploit maturity reported as none at ~26 days after publication—so operational urgency is lower than remotely exploitable or actively weaponized flaws, but still material wherever untrusted local users share writable directories with privileged GLib consumers.

How an attack unfolds

A local attacker who can write to a directory where a GLib-using process calls g_file_replace() with G_FILE_CREATE_REPLACE_DESTINATION waits for (or induces) failure of the .goutputstream-XXXXXX temp-file create. After GLib unlinks the destination and before it recreates the file without exclusive/symlink-safe flags, the attacker plants a symlink or otherwise redirects the path so the write lands on a different file they could not otherwise modify. Success depends on winning a short race; there is no public exploit maturity and no named threat-actor attribution. Impact is integrity of the redirected file and possible local availability loss, not remote code execution.

How to fix it

Upgrade GLib2 to a vendor- or distribution-patched release that restores exclusive creation and symlink/hard-link protections on the fallback recreate path after temp-file failure. If a fixed package is not yet available, mitigate by ensuring destination directories are not group- or world-writable (sticky bit on shared dirs such as /tmp), running GLib consumers with least privilege, avoiding G_FILE_CREATE_REPLACE_DESTINATION where the fallback path is reachable, and restricting local untrusted users on hosts that perform privileged GLib file replacement. Apply distribution security updates for glib2/libglib2.0 as they land; no specific upstream version numbers were provided with this advisory.

How to confirm the fix worked

Inventory installed GLib2 packages (glib2, libglib2.0-0, or equivalent) and confirm they match a patched vendor build. Search application and system code for g_file_replace() with G_FILE_CREATE_REPLACE_DESTINATION. After patching, regression-test the replace path including forced temp-file creation failure and confirm the destination is recreated with exclusive, non-following flags (no symlink clobber). Verify shared writable directories used as replace targets are not writable by untrusted local users. Re-scan hosts after the next glib2 update cycle.

Typical attack path

1. Gain local access as a low-privileged user who can write to a directory used as a g_file_replace() destination by a more privileged or different-context process.
2. Identify or trigger a GLib consumer that calls g_file_replace() with G_FILE_CREATE_REPLACE_DESTINATION.
3. Cause or wait for creation of the .goutputstream-XXXXXX temporary file to fail so GLib falls back to unlink-and-recreate.
4. Win the race after unlink and before recreate by replacing the destination path (e.g., symlink) so the write is redirected.
5. Leave a modified or corrupted target file; optionally repeat against other destinations in the same writable directory.

How to detect it

This is a local, high-complexity race with no public exploit maturity and no named actors, so pre-exploitation network IOCs are unlikely. Hunt on endpoints: auditd/sysmon-equivalent logs for unlink followed immediately by creat/open of the same path without O_EXCL from GLib-linked processes; look for .goutputstream-* temp files in application data dirs; correlate symlink creation (symlinkat) in those directories around file-replace activity; review unexpected content changes to configs or state files written by GLib apps. Sources: audit logs (unlink, open, symlink, rename), file integrity monitoring, process-file access telemetry, and package/version inventory. Absence of these artifacts does not prove non-exploitation given the short race window.

• .goutputstream-
• g_file_replace
• G_FILE_CREATE_REPLACE_DESTINATION
• symlinkat
• type=PATH name=*.goutputstream-*
• open.*O_CREAT.*without O_EXCL after unlink of destination

What your security team should do

• Prioritize inventory of GLib2 versions and of processes that call g_file_replace() with G_FILE_CREATE_REPLACE_DESTINATION, especially those running as root or other privileged users.
• Apply vendor glib2/libglib2.0 security updates as soon as they are published; this is not KEV and EPSS is low, so schedule with other medium local-integrity patches rather than emergency remote-RCE response.
• Harden destination directories: remove group/world write, use sticky bits on shared temp dirs, and separate untrusted local users from privileged GLib writers.
• Add detection for unexpected overwrites of sensitive files co-located with GLib replace targets and for .goutputstream-* temp files in unusual directories.
• Track distribution advisories until an exact fixed GLib version is named; re-validate after upgrade.