CVE-2026-5958

What it actually does

This is a local time-of-check/time-of-use race condition in GNU sed when it is run with both in-place editing (-i) and --follow-symlinks. sed resolves a symlink target for the destination path, then separately opens the original symlink path for input. If an attacker can replace the symlink between those operations, sed can read attacker-controlled content from one file while writing the transformed output to the previously resolved target. The result is arbitrary file overwrite, limited to files writable by the sed process and to content that can be produced through the sed expression being executed.

Why it matters to the business

Systems and automation that run sed with -i --follow-symlinks on paths located in attacker-writable directories can be abused to overwrite files with the privileges of the process running sed. In practice, the highest-risk scenarios are privileged maintenance scripts, package hooks, CI/CD jobs, provisioning tools, or cron jobs that edit files in directories where less-trusted users can create or replace symlinks. Successful exploitation could corrupt configuration, weaken security controls, disrupt services, or in some cases enable privilege escalation if a sensitive writable target is overwritten with useful content. The public exploitation signal is currently low, with low EPSS, no known KEV listing, and no known ransomware association, but the flaw is still important because it affects a common Unix utility often embedded in automation.

How an attack unfolds

An attacker first identifies a workflow where sed is invoked with both -i and --follow-symlinks against a symlink path they can influence. The attacker prepares two symlink targets: one target that sed will resolve during its initial check and another attacker-chosen target that will be swapped in immediately afterward. During the narrow race window between symlink resolution and file open, the attacker atomically replaces the symlink, commonly using rename-style operations. sed then reads content from the attacker-selected replacement target but writes the edited result to the original resolved destination path. If the sed process has sufficient permissions, this can overwrite a file the attacker could not normally modify directly. Exploitation reliability depends on timing, filesystem behavior, the sed command being run, and whether the attacker can repeatedly trigger or race the vulnerable operation.

How to fix it

Upgrade GNU sed to version 4.10 or later wherever sed may be used with in-place editing and symlink-following behavior. If immediate upgrade is not possible, avoid using -i and --follow-symlinks together, especially on paths under directories writable by non-administrative users. Refactor automation to edit regular files only, validate that target paths are not symlinks before modification, use secure temporary files in trusted directories, and perform file replacement with safe ownership and permission checks. Remove attacker write access to directories containing symlink targets used by privileged maintenance scripts. For privileged automation, prefer explicit resolved paths in trusted directories and fail closed if a target is a symlink or changes during processing.

How to confirm the fix worked

Confirm the installed sed version reports 4.10 or later using `sed --version` where GNU sed is present. Review package manager inventory to verify the fixed package is deployed across images, hosts, containers, build runners, and administrative tooling environments. Search scripts, cron jobs, systemd units, CI/CD definitions, configuration management recipes, and package hooks for sed invocations that combine `-i` with `--follow-symlinks`. For mitigation validation, test that workflows no longer edit symlink paths in writable directories and that privileged jobs fail when a symlink target is replaced during execution. Where audit logging is available, verify monitoring can capture sed executions with these flags and filesystem rename/symlink activity around the same paths.

Typical attack path

1. Find a script, service, cron job, build step, or administrative command that runs sed with both -i and --follow-symlinks.
2. Confirm the sed target path is a symlink located in a directory where the attacker can create, delete, or replace entries.
3. Prepare an original symlink that points to the intended overwrite destination and a replacement symlink that points to attacker-controlled input content.
4. Trigger or wait for the privileged sed process to begin operating on the symlink path.
5. Race the operation by atomically replacing the symlink after sed resolves the target but before it opens the path for reading.
6. Cause sed to read attacker-controlled content and write the processed output to the previously resolved target file.
7. Use the overwritten file to corrupt application behavior, alter configuration, disrupt service, or potentially gain further privileges depending on the target file and sed expression.

How to detect it

Look for evidence that sed was run with both in-place editing and symlink following, then correlate with rapid symlink replacement or rename activity on the same path. Useful sources include Linux auditd process execution logs, endpoint detection telemetry, shell history, sudo logs, systemd journal entries, cron logs, CI/CD runner logs, package manager hook logs, and file integrity monitoring. Search for command lines containing `sed` with `--follow-symlinks` and `-i`, including variants such as `-i''`, `-i.bak`, or combined short options. Investigate executions by privileged users or automation accounts where the target file resides in a writable directory such as `/tmp`, application upload/work directories, shared build workspaces, or group-writable deployment paths. On systems with auditd or EDR filesystem telemetry, correlate sed execution with `rename`, `renameat`, `renameat2`, `symlink`, `symlinkat`, or `unlink` operations against the same path immediately before or during the sed process lifetime. Post-exploitation signs are target files overwritten at the time of a sed invocation, unexpected file ownership or content changes, modified security or service configuration, and repeated failed or rapid symlink-swap attempts. There are no universal network indicators because exploitation is local and depends on host filesystem access.

• sed -i --follow-symlinks
• sed --follow-symlinks -i
• --follow-symlinks
• -i --follow-symlinks
• --follow-symlinks -i
• sed -i'' --follow-symlinks
• sed -i.bak --follow-symlinks
• renameat2
• renameat(
• rename(
• symlinkat
• symlink(
• unlinkat
• sed: couldn't open temporary file
• sed: cannot rename

What your security team should do

• Prioritize upgrading GNU sed to 4.10 or later on systems where privileged automation uses sed or where untrusted users can write to directories processed by scripts.
• Inventory all uses of `sed -i --follow-symlinks` across scripts, CI/CD pipelines, containers, cron jobs, systemd units, and configuration management code.
• Treat privileged sed invocations against symlinks in world-writable or group-writable directories as high-risk even though broad exploitation activity is not currently known.
• Add detections for sed command lines containing both in-place editing and `--follow-symlinks`, especially when executed by root, service accounts, package managers, or automation runners.
• Harden file permissions so less-trusted users cannot replace symlinks or path components consumed by privileged maintenance jobs.
• Where upgrade is delayed, remove `--follow-symlinks`, avoid `-i`, or rewrite workflows to copy to trusted temporary files and replace only verified regular files.
• Investigate unexpected modifications to sensitive configuration files that coincide with sed execution and symlink rename activity.