sed-4.10

[Bruce Dubbs]

New minor version.

[Bruce Dubbs]

• Noteworthy changes in release 4.10 (2026-04-21) [stable]

Bug fixes

sed 's/a/b/g' (and other global substitutions) now works on input lines longer than 2GB. Previously, matches beyond the 2^{31 byte offset would evoke a "panic" (exit 4). [bug present since the beginning]}

'sed --follow-symlinks -i' no longer has a TOCTOU race that could let an attacker swap a symlink between resolution and open, causing sed to read attacker-chosen content and write it to the original target. [bug introduced in sed 4.1e]

sed no longer falsely matches when back-references are combined with optional groups (.?) and the $ anchor. For example, this no longer falsely matches the empty string at beginning of line:

$ echo ab | sed -E 's/^{(.?)(.?).?\2\1$/X/' Xab}

[bug present since "the beginning"]

In --posix mode, sed no longer mishandles backslash escapes (\n, \t, \a, etc.) after a named character class like :alpha:. For example, 's/^{A\n:alpha:\n*/XXX/' would fail to match the trailing newline, treating \n as a literal backslash and an 'n' rather than a newline. This happened when an earlier backslash escape in the same regex had already been converted, shifting the in-place normalization buffer. [bug introduced in sed 4.9]}

sed --debug no longer crashes when a label (":") command is compiled before the --debug option is processed, e.g., sed -f<(...) --debug. [bug introduced in sed 4.7 with --debug]

sed no longer rejects the documented GNU extension 'a**' (equivalent to 'a*') in Basic Regular Expression (BRE) mode. Previously, this worked only with -E (ERE mode), even though grep has always accepted it in BRE mode. [bug present since "the beginning"]

sed no longer rejects "\c[" in regular expressions [bug present since the beginning]

'sed --follow-symlinks -i' no longer mishandles an operand that is a short symbolic link to a long symbolic link to a file. [bug introduced in sed 4.9]

Fix some some longstanding but unlikely integer overflows. Internally, 'sed' now more often prefers signed integer arithmetic, which can be checked automatically via 'gcc -fsanitize=undefined'.

Changes in behavior

In the default C locale, diagnostics now quote 'like this' (with apostrophes) instead of `like this' (with a grave accent and an apostrophe). This tracks the GNU coding standards.

'sed --posix' now warns about uses of backslashes in the 's' command that are handled by GNU sed but are not portable to other implementations.

Build-related

builds no longer fail on platforms without the <getopt.h> header or getopt_long function. [bug introduced in sed 4.9]

[Bruce Dubbs]

Fixed at commit bdd621f288.

[Douglas R. Reno]

From oss-security:

Hi,

Jim kindly brought the below to linux-distros last month (thank you,
Jim!), but seems to have failed to bring it to oss-security on the
public disclosure date as required.  I only discovered this now while
processing the distros list statistics for April.

Gentoo and Amazon failed to stay on top of this, even though that was
their contributing-back task.  We already figured this out with Gentoo
in context of another issue, but I am yet to hear from Amazon.

Also, in the brief discussion on linux-distros and with Jim we did
realize this may need to have been on the full distros list rather than
just linux-distros, as GNU sed exists e.g. in pkgsrc, which is a member
of the full distros list.  However, we decided that this time the issue
was too minor, so noted this for next time.

I now see that Jim indeed made public announcements - just not here:

https://lists.gnu.org/archive/html/info-gnu/2026-04/msg00009.html
https://lists.gnu.org/archive/html/sed-devel/2026-04/msg00012.html

> * Noteworthy changes in release 4.10 (2026-04-21) [stable]
>
> ** Bug fixes

>   'sed --follow-symlinks -i' no longer has a TOCTOU race that could let
>   an attacker swap a symlink between resolution and open, causing sed to
>   read attacker-chosen content and write it to the original target.
>   [bug introduced in sed 4.1e]

Also listed are many other bug fixes that are not considered security.

There's also:

https://cert.pl/en/posts/2026/04/CVE-2026-5958/

> Vulnerability in GNU sed software
> 20 April 2026 | CERT Polska | #vulnerability, #warning, #cve
>
> CVE ID 	CVE-2026-5958
> Publication date 	20 April 2026
> Vendor 	GNU
> Product 	sed
> Vulnerable versions 	From 4.1e below 4.10
> Vulnerability type (CWE) 	Time-of-check Time-of-use (TOCTOU) Race Condition (CWE-367)
> Report source 	Report to CERT Polska
>
> Description
>
> CERT Polska has received a report about vulnerability in GNU sed
> software and participated in coordination of its disclosure.
>
> The vulnerability CVE-2026-5958: When sed is invoked with both -i
> (in-place edit) and --follow-symlinks, the function open_next_file()
> performs two separate, non-atomic filesystem operations on the same
> path: 1. resolves symlink to its target and stores the resolved path for
> determining when output is written, 2. opens the original symlink path
> (not the resolved one) to read the file. Between these two calls there
> is a race window. If an attacker atomically replaces the symlink with a
> different target during that window, sed will: read content from the new
> (attacker-chosen) symlink target and write the processed result to the
> path recorded in step 1. This can lead to arbitrary file overwrite with
> attacker-controlled content in the context of the sed process.
>
> This issue was fixed in version 4.10.
>
> Credits
>
> We thank Michał Majchrowicz and Marcin Wyczechowski (AFINE Team) for
> the responsible vulnerability report.

and NIST NVD lists this score:

> CNA:  CERT.PL
> CVSS-B 2.1 LOW
> Vector:  CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Alexander

----- Forwarded message from Jim Meyering <jim@meyering.net> -----

From: Jim Meyering <jim@meyering.net>
To: linux-distros@vs.openwall.org
Subject: [vs-plain] GNU sed: CVE-2026-5958: TOCTOU race in sed -i --follow-symlinks
CC: Michał Majchrowicz <mmajchrowicz@afine.com>,
 Paul Eggert <eggert@cs.ucla.edu>
Date: Fri, 10 Apr 2026 18:40:17 -0700

A TOCTOU race in GNU sed allows an attacker to cause sed -i
--follow-symlinks to read attacker-controlled content and write it to
an unintended file. This can lead to arbitrary file overwrite as the
sed process's user when a privileged process (e.g., root) runs sed on
a path the attacker can influence.

CVE: CVE-2026-5958
CWE: CWE-367 (Time-of-Check Time-of-Use Race Condition)
Affected: GNU sed 4.1e through 4.9 (all current releases with --follow-symlinks)
Severity: Moderate: requires privileged sed invocation on an
attacker-influenced path; a survey of Debian and GitHub shows
--follow-symlinks is overwhelmingly used on root-owned paths

Bug: follow_symlink() resolves the symlink via readlink(), then
ck_fopen() reopens the original symlink path. Between these two
syscalls, the symlink can be swapped, causing sed to read from one
file and write to another. Reproduces reliably in ~14 attempts.

Fix: One-line change -- open the already-resolved path instead of
re-traversing the symlink:

--- a/sed/execute.c
+++ b/sed/execute.c
@@ -562,7 +562,7 @@ open_next_file (const char *name, struct input *input)
       if (follow_symlinks)
         input->in_file_name = follow_symlink (name);

-      if ( ! (input->fp = ck_fopen (name, read_mode, false)) )
+      if ( ! (input->fp = ck_fopen (input->in_file_name, read_mode, false)) )
         {
           const char *ptr = strerror (errno);
           fprintf (stderr, _("%s: can't read %s: %s\n"), program_name,

Proposed disclosure date: 2026-04-19. I plan to push the fix and
release GNU sed 4.10 on that date. If someone would like an extra
week, that's fine, too. Let me know.

Credit: Micha?? Majchrowicz and Marcin Wyczechowski (AFINE Team).

Jim Meyering
GNU sed maintainer

----- End forwarded message -----

[Douglas R. Reno]

SA-13.0-068 issued