On 8 September 2026 Ubuntu published USN-8737-1, a security notice for the GNU C Library covering six CVEs. USN-8737-2 followed on 10 September with the same fixes for Ubuntu 24.04 LTS. Several upstream advisories were published between 10 August and 15 September, so this notice bundles fixes that landed over about five weeks.
None of the six is a drop-everything remote code execution bug. Each needs an application to call a specific libc function with attacker-influenced input. The reason it still matters to platform teams is that libc6 sits in almost every image you build, and fixing the host does nothing for a container that still carries the old package.
What's affected
The notices list three Ubuntu releases and the fixed libc6 source package version for each:
| Release | Notice | Fixed glibc version |
|---|---|---|
| Ubuntu 22.04 LTS (jammy) | USN-8737-1 | 2.35-0ubuntu3.15 |
| Ubuntu 24.04 LTS (noble) | USN-8737-2 | 2.39-0ubuntu8.9 |
| Ubuntu 26.04 LTS (resolute) | USN-8737-1 | 2.43-2ubuntu2.4 |
The six CVEs, with the descriptions Ubuntu and the upstream CVE records give:
| CVE | Function | What goes wrong |
|---|---|---|
| CVE-2026-19499 | strfmon, strfmon_l | Write past the end of the output buffer with right-justified width padding. Glibc 2.38 to 2.44, so Ubuntu 26.04 only. |
| CVE-2026-19542 | tdelete | One-pointer write past a stack array. Needs a very deep tree, so in practice it is a crash risk. |
| CVE-2026-6368 | wordexp with WRDE_APPEND | Invalid memory returned in we_wordv, which can abort the process on wordfree. |
| CVE-2026-6791 | wordexp | Stack overflow when expanding a path that starts with a tilde followed by a very long username. |
| CVE-2026-77117 | SHIFT_JISX0213 converter | Converter stops making progress, so the calling application hangs. |
| CVE-2026-80489 | EUC_JISX0213 converter | Same hang, in the other Japanese character set converter. |
The two converter bugs are reachable through iconv in glibc 2.3 to 2.44. The CVE record says the input must be attacker controlled and the caller must use an output buffer small enough to split a two-code-point sequence. Upstream scores them as availability-only issues (CVSS 3.1 vector with A:H and no confidentiality or integrity impact).
The strfmon record states that "at the time of publication, no network-facing application impact is known."
How to check if you're exposed
On a host or in a container, read the installed package version and compare it to the table:
dpkg-query -W libc6
ldd --version | head -1
To check images without starting your app, override the entrypoint:
docker run --rm --entrypoint dpkg-query myorg/api:latest -W libc6
For a fleet, loop over the image list you already have:
for img in $(cat images.txt); do
printf '%s ' "$img"
docker run --rm --entrypoint dpkg-query "$img" -W libc6 2>/dev/null || echo "no dpkg"
done
Images based on Alpine or distroless variants without dpkg will print "no dpkg". Those need a different check, and Alpine uses musl rather than glibc.
Then ask which of your programs call the risky functions. This is the part that decides priority:
grep -rnE "wordexp|strfmon|tdelete|iconv_open|iconv\(" src/ vendor/ 2>/dev/null
Shell-out helpers, git hooks, build tools and anything that expands user-supplied paths are the usual wordexp callers. iconv is common in mail, text-conversion and import pipelines.
What to do now
- Update the host:
sudo apt update && sudo apt install --only-upgrade libc6. Restart long-running services afterward, since processes keep the old library mapped until they restart. - Rebuild images that use an Ubuntu base and run
apt-get upgradeor pull a fresh base tag first. Then re-run thedpkg-querycheck above against the new digest. - Pin your base image by digest in CI and bump it on a schedule, so the next libc update reaches you without a manual hunt.
- Run the
grepabove across your own code and prioritize services that accept input from outside your network and useiconvorwordexp. - For Debian, RHEL and Alpine bases, check your distribution's own tracker for these CVE IDs. Fixed versions and backport status differ per distribution, and a version string alone can mislead.
A rebuild step you can keep
If your Dockerfile starts from an Ubuntu tag, make the update explicit so a cached layer cannot hide an old libc6:
FROM ubuntu:24.04
RUN apt-get update \
&& apt-get install -y --only-upgrade libc6 \
&& rm -rf /var/lib/apt/lists/*
Then add a CI step that fails the build when the installed version is older than the one in the notice. Compare with dpkg --compare-versions:
v=$(dpkg-query -W -f='${Version}' libc6)
dpkg --compare-versions "$v" ge 2.39-0ubuntu8.9 || { echo "libc6 $v is too old"; exit 1; }
Change the version string per base release. The check costs a second and tells you the truth about the image you are about to ship, not the one you meant to build.
Why it matters
Library CVEs in libc rarely get a name or a headline, and the ones in this notice are quiet. That is exactly why they pile up in container fleets. A scanner will flag libc6 on every image, and the fix is the same each time: rebuild.
Reachability is what separates the noise from the work. A hang in a Japanese character converter matters to an email importer and not at all to a service that never calls iconv. Safeguard does reachability analysis for application dependencies, which answers the same question for libraries you call from code.
Try it yourself
Scan one image from your registry for OS packages and see whether libc6 is listed as outdated.
Click through it at your own pace, or open it full screen.
Quick check
You patched the host with apt. Are your containers fixed?
No. Each container image carries its own libc6. Rebuild the image from an updated base and verify with dpkg-query -W libc6 against the new image.
Which of the six CVEs only affects Ubuntu 26.04?
CVE-2026-19499, the strfmon buffer overflow. Ubuntu's notice states that this issue only affected 26.04 LTS.
Why check your own code for wordexp and iconv?
Four of the six bugs sit behind those functions. They only matter if your software calls them with input an attacker can influence.
