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.
CVE-2024-0684
CVE-2017-18018
CVE-2016-2781
CVE-2015-4042
CVE-2015-4041
CVE-2015-1865
CVE-2014-9471
CVE-2013-0223
CVE-2013-0222
CVE-2013-0221
CVE-2009-4135
This was an interesting security issue since it only affected people
running make distcheck in GNU Coreutils. This rule is
created by GNU Automake so that maintainers can check that their
package tarball is self-contained before making a release. However,
Automake allows maintainers to extend the checks using the
distcheck-hook, as GNU coreutils did with its
my-distcheck rule. Therefore, only the maintainers of GNU
Coreutils and perhaps some curious people who built it from source
were affected.
The issue was that the my-distcheck rule would create a
directory at $(TMPDIR)/$(PACKAGE)/test in which the
checks were performed. The TMPDIR variable, if unset, as it commonly
is, would default to /tmp. Aside from being left behind,
an unprivileged user on your local system could create a symbolic link
here pointing to some other location on your file system. If you, a
privileged user, were to subsequently run the rule, that symbolic link
would be followed and the checks would be performed there, even if the
unprivileged user did not have access to the location.
The bug was fixed in commit ae034822c535fa5168069a75fb5e1c58f93a7834.