GNU C Library EUVD-2026-114247

Exploitation requires all of the following concrete conditions, per the description: (1) the target program uses gettext and runs WITHOUT AT_SECURE - i.e. not setuid/setgid - because setuid/setgid programs reject LANGUAGE entries containing '/' or equal to '..'; (2) the attacker can set the LANGUAGE environment variable across a trust boundary (the cited example is an SSH server using the AcceptEnv directive to accept LANGUAGE and LANG from clients, with the account restricted to a forced command); (3) the attacker can also select an installed non-trivial LC_MESSAGES locale (via LANG or LC_ALL) that is not 'C', 'C.<encoding>' or 'POSIX', since LANGUAGE is ignored for those; and (4) the attacker can place a crafted .mo file in a filesystem location readable by the target program. Limiting factors: these multiple simultaneous prerequisites (trust-boundary env passthrough, a selectable installed locale, and a writable/readable file location) are why attack complexity is high and why default, non-env-forwarding deployments are not exposed.

This is a genuine but conditional risk rather than a drop-everything emergency, and the signals are internally consistent. The vendor-supplied CVSS vector (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, 7.0 HIGH) describes a local attack vector with high attack complexity, low privileges required, and no user interaction, yielding high confidentiality, integrity and availability impact - the high impact comes from potential arbitrary code execution, while AC:H and AV:L reflect the several prerequisites that must align. No EPSS score, no CISA KEV entry, and no PoC/exploit reference were provided in the input, so exploitation remains theoretical: no public exploit identified at time of analysis. The vuln.today decision label is 'this_week', which aligns with a patch-available, high-impact-but-constrained issue - a priority to remediate on a normal patch cycle rather than an active-exploitation fire drill. The core value here is architectural: this is a bypass of the CVE-2014-0475 fix, which rejected '..' in locale names from setlocale/LC_*/LANG but never covered the LANGUAGE variable that gettext reads directly, so defenders who assumed CVE-2014-0475 closed this class of path-traversal should note the gap. Missing data to flag explicitly: EPSS probability is absent (cannot quantify likelihood), and KEV status is not confirmed (treat as not known-exploited, not as proof of safety).

An attacker with a restricted SSH account (locked to a forced command) connects to a server whose sshd uses AcceptEnv to pass LANGUAGE and LANG from the client. The attacker sets LANGUAGE to a path-traversal value and LANG to an installed non-C locale, causing a gettext-using program to load a crafted .mo file the attacker planted in a readable location; a format-directive mismatch in that catalog triggers undefined behaviour in the printf family, potentially yielding code execution with the program's privileges and escaping the forced-command restriction. No public exploit code was identified in the provided sources, so this scenario is grounded in the description rather than a verified working exploit.