Introduction
This is a list of all CVEs filed for GNU coreutils and their descriptions.
CVE-2026-56392
In coreutils-9.11, you could cause the size given to
malloc to overflow like so:
$ yes ' ' | tr -d '\n' | LC_ALL=en_US.UTF-8 unexpand -t $(expr $SIZE_MAX / 16 + 1)
Segmentation fault (core dumped) yes ' ' | tr -d '\n' | unexpand -t $(expr $SIZE_MAX / 16 + 1)
It is a real bug, but has no real security impact. I am not sure why it was assigned a CVE. The CVE description says:
When running GNU coreutils unexpand with attacker-provided large tab stop (-t) arguments, this behavior leads to a crash and potentially achieve a heap write primitive depending on memory layout.
This is technically true, but it fails to mention that it also
requires the attacker to control standard input or the file arguments.
Unless you copy and paste obfuscated commands from the internet, this
is a non-issue, since the only method of exploitation would be having
access to your local system to run commands. If that were the case,
there are certainly more productive things they could do than throw
trash at unexpand.
The bug was fixed in commit b60a159fdc5bfcf9988d3a4cb6f53abe8ad5d35d.
CVE-2026-56391
In coreutils-9.5 through coreutils-9.11, you can read past the end of
a heap-allocated buffer with
uniq -w, like so:
$ perl -e 'print(("\360\237\230\200" . "A"x255 . "\n") x 2)' | LC_ALL=en_US.UTF-8 valgrind uniq -w256 2>&1 | grep -F '== Invalid'
==342574== Invalid read of size 8
==342574== Invalid read of size 8
==342574== Invalid read of size 1
==342574== Invalid read of size 1
It is a real bug, but has no real security impact. I am not sure why it was assigned a CVE. The CVE description says:
When running GNU coreutils uniq with attacker-provided arguments, this behavior leads to a crash and potential adjacent heap memory exposure.
This assumes that the attacker can execute the
uniq command on your system, can read its output, and can
read sensitive files that you own. In other words, it requires
complete access to your system. Certainly, if that were the case, they
could find more productive things to do.
The bug was fixed in commit d64e35a8a4c0e4608321433e0d84d917e4e36371.
CVE-2025-5278
In coreutils-7.2 through coreutils-9.7 it was possible to read 1 byte before a heap-allocated buffer, like so:
printf '%s\n' aa bb | _POSIX2_VERSION=200809 valgrind sort +0.${SIZE_MAX}R 2>&1 | grep -F '== Invalid'
==86253== Invalid read of size 1
This is a real bug, but has no security impact at all. I am not sure why it was assigned a CVE. This one commonly shows up on CVE scans, which is mildly annoying.
The bug was fixed in commit 8c9602e3a145e9596dc1a63c6ed67865814b6633.