i18next-fs-backend EUVD-2026-28793

Exploitation requires the application to pass user-controlled input (HTTP query string, cookie, or header) into the lng or ns parameters of an i18next translation call without prior validation. Specifically: (1) Application uses i18next-fs-backend as the translation storage backend. (2) Application exposes language selection to end users via i18next-http-middleware, i18next-browser-languagedetector, or custom middleware that populates i18next language from request data. (3) No application-layer input validation restricts lng/ns to safe character sets (default i18next configurations perform no path sanitization). The vulnerable code path activates on every translation lookup (i18next.t() call) when these conditions are met-no non-default configuration, admin access, or special features required. Most i18next web deployments meet all three conditions by design: language detection from Accept-Language headers or ?lng= query parameters is the documented standard setup. Limiting factors: Server-side i18next only (browser-side i18next uses different backends); requires Node.js or Deno runtime (not applicable to Java/Python i18next ports); read impact limited by parser's tolerance for non-JSON content (YAML parsers more permissive than strict JSON); write impact limited by filesystem permissions of the Node.js process user.

Real-world risk is HIGH despite 8.2 base score, driven by trivial exploitation requirements and deployment prevalence. CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N confirms zero-authentication network attack with low complexity-a single GET request exploits vulnerable instances. The 'affected only when user input reaches lng/ns' condition is met by default in most i18next web deployments: i18next-browser-languagedetector (22M weekly npm downloads) and i18next-http-middleware automatically parse ?lng from query strings, making the vulnerable code path the standard configuration rather than an edge case. EPSS data not provided but expected high given: (1) publicly documented GitHub security advisory with POC, (2) trivial one-request exploitation, (3) no authentication barrier, (4) massive install base (i18next ecosystem has 50M+ weekly downloads). Impact extends beyond information disclosure (C:H/I:L): the writeFile code path enables arbitrary file overwrite, and the documented .js/.ts locale eval feature creates a remote code execution chain when traversal targets executable content. CISA KEV status not provided-if absent, likely indicates targeted rather than mass-scan exploitation. Primary risk driver is the mismatch between developers' mental model (language codes are benign two-letter strings like 'en'/'fr') and reality (they are filesystem path components subject to traversal when derived from HTTP input).

Attacker identifies a web application using i18next with default i18next-browser-languagedetector configuration (common in React/Vue/Angular SPAs with i18n). They craft a GET request: https://target.example.com/?lng=../../../../etc/passwd&ns=translation. The i18next-http-middleware populates req.language from the query parameter with no validation. Backend code calls i18next.t('key', { lng: req.language }), triggering i18next-fs-backend's read() function. The interpolate() helper substitutes lng into loadPath /locales/{{lng}}/{{ns}}.json, yielding /locales/../../../../etc/passwd/translation.json (/etc/passwd/translation.json after normalization). Backend attempts fs.readFile on that path; if the YAML parser is configured, /etc/passwd content surfaces as a translation resource in the API response. For write exploitation, attacker supplies ?lng=../../../app/config&ns=database to overwrite /app/config/database.json with missing-key payloads, corrupting application state. GitHub advisory (GHSA-8847-338w-5hcj) provides working POC demonstrating /etc/passwd read via query parameter.