wordexp blows the stack, and fopen takes options you never knew about

glibc shipped a nine-CVE patch batch this month. SUSE landed it October 1st. Debian has a proposed update in review. If you run a distro-packaged glibc you will get it through the normal security update channel. If you statically link glibc or ship your own build, check your version.

The CVEs divide into three kinds of thing: the expected wordexp carnage, an obscure fopen extension most people have never heard of, and a buffer overflow in currency formatting that exists to remind you that locale code is a tire fire.

wordexp, again

CVE-2026-6791 is a stack clash in wordexp’s tilde handler. The parse_tilde function uses strndupa to copy a username onto the stack. No bounds check. Feed it a long enough username and you exhaust the thread stack; the process crashes.

This code has been in glibc since version 2.0. The CVE was published August 2026. Affected range is glibc 2.0 through 2.43.

CVE-2026-6368 is an invalid free in the WRDE_APPEND rollback path, also in wordexp.

If you are not familiar: wordexp is the C library function that expands shell-style glob patterns, including tilde substitution and variable expansion, inside a C program. The man page says, directly: “Do not use this function in a privileged program.” It has said this for as long as the function has existed. The bugs keep arriving anyway, because people keep calling it from privileged programs.

fopen takes charset options now. apparently.

CVE-2026-18374 is a heap buffer overflow in fopen. Specifically in the ,ccs= charset extension.

Most people know fopen takes “r”, “w”, “a”, their plus-sign variants, and “b” for binary mode on Windows. What glibc also accepts, documented but obscure, is a charset suffix appended to the mode string: fopen("/tmp/foo", "r,ccs=UTF-8") opens the file with automatic character set conversion to UTF-8 on reads. Pass an effectively empty string for the charset value, as in "r,ccs=", and glibc overflows a heap buffer.

CVSS score is 4.9. Severity is moderate. Exploitation requires attacker-controlled input reaching the mode argument of fopen, which is unusual. Most code hardcodes its mode strings. “Unusual” is not “impossible”, and a standard library call overflowing on bad input is still a bug worth patching.

Affects glibc through 2.45. Fixed in 2.46, backported to distro packages.

If you did not know fopen took charset extensions: you are not alone. The feature is documented in the glibc manual. It has now also appeared in the CVE database, so more people know about it than before.

the currency one

CVE-2026-19499 is a buffer overflow during right-justification padding in currency formatting. CVSS 6.1, somehow rated higher than the fopen heap overflow. If you are formatting monetary values with glibc’s strfmon family and the padding path gets a pathological format string, the buffer math goes wrong. Most applications do not call strfmon at all. The ones that do will want this patch.

CVE-2026-19542 is an out-of-bounds write in tdelete, the BSD-derived tree deletion function. CVE-2026-8674 is a reachable assertion in the resolver’s config update path that a local network attacker can trigger to crash the process. The remaining two CVEs are JISX0213 character encoding state not being reset correctly, which affects Japanese text processing.

what to do

Run your security updates. SUSE shipped October 1st. Debian’s proposed update is in review and will land shortly. Other distros are behind it.

For static-linked binaries: ldd --version tells you the glibc version in the default dynamic linker, but a static binary carries its own copy. strings /path/to/binary | grep 'GLIBC_' will show the minimum glibc version the binary references at link time; if it compiled against a version earlier than 2.46, you need a rebuild.

The same problem applies to any container image that installed glibc outside the base image’s package manager. The OpenSSL EOL post from yesterday covers the same ground for a different library: static and vendored copies do not get patched through package updates.

If you run Alpine or anything based on musl libc, the wordexp bugs do not apply. musl’s wordexp is a minimal stub and does not share the glibc tilde expansion path. The fopen charset extension does not exist in musl either. The August MOTD on musl vs glibc covers the practical differences. musl’s stance is that a lot of glibc’s “extensions” are bugs waiting to happen, and this batch does not argue against that position.

FORTIFY_SOURCE=3, which glibc 2.44 extended last month to catch more buffer overflows at compile time, would not have caught the fopen overflow in glibc’s own internals directly. Worth having anyway. The glibc 2.44 FORTIFY_SOURCE MOTD has the details on what it does and does not cover.