CVE-2026-41693

What it actually does

The flaw allows path traversal through untrusted i18next language (`lng`) or namespace (`ns`) values. In vulnerable versions of `i18next-fs-backend` before 2.6.4, those values are interpolated directly into filesystem path templates such as `loadPath` or `addPath` without encoding, normalization, or validation. If an application derives `lng` or `ns` from user-controllable input such as query parameters, cookies, headers, or request-scoped localization middleware, an attacker can use values containing `../`, path separators, control characters, prototype-like keys, or very long strings to force the backend to read from or write to files outside the intended locale directory. The primary impact is unauthorized local file read; limited file overwrite may also be possible where save-missing or translation-writing behavior is enabled.

Why it matters to the business

Applications using vulnerable filesystem-backed localization can expose sensitive local files, including configuration files, credentials, tokens, source code, or operating system files, if language or namespace selection is influenced by external users. In configurations that allow translation files to be written, attackers may also overwrite application-accessible files, potentially causing service instability, content tampering, or follow-on compromise. The issue is remotely reachable in common web patterns, requires no authentication, and has a high confidentiality impact, although current public exploit maturity and EPSS likelihood are low and it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies an application that uses i18next with `i18next-fs-backend` and accepts a language or namespace value from the request, such as `?lng=`, `?ns=`, an `Accept-Language`-derived value, or a language cookie. The attacker then supplies traversal sequences such as `../../../../etc/passwd` or encoded variants as the language or namespace. The vulnerable backend substitutes that value into its configured `loadPath` template and attempts to read the resulting path from disk. If the file exists and the application returns translation-loading errors, fallback content, debug output, or localized resources in a way that reflects file contents or metadata, the attacker may retrieve sensitive files. If the application has write behavior enabled through `addPath` or missing-key saving, the attacker may instead craft traversal values that cause writes outside the expected locale tree, subject to process permissions and path construction.

How to fix it

Upgrade `i18next-fs-backend` to version 2.6.4 or later. Where package lockfiles are used, ensure the resolved transitive dependency is also upgraded, not only the top-level package declaration. As defense in depth, restrict accepted `lng` and `ns` values to an explicit allowlist of known locale and namespace names; reject values containing path separators, traversal sequences, control characters, null bytes, prototype keys such as `__proto__`, and excessive length. Avoid deriving filesystem paths directly from request-controlled localization values. Disable missing-key or translation write features unless required, and ensure the application process runs with least-privilege filesystem permissions so it cannot read secrets or write outside intended directories. Consider placing locale files in a constrained directory and validating the final normalized path remains within that directory before any read or write.

How to confirm the fix worked

Confirm that deployed applications resolve `i18next-fs-backend` to version 2.6.4 or later using package manager inspection such as `npm ls i18next-fs-backend`, `pnpm why i18next-fs-backend`, `yarn why i18next-fs-backend`, or equivalent Deno dependency review. Review application code and framework middleware configuration for request-derived `lng` or `ns` values, including query parameters, cookies, headers, and route parameters. Test safely in a non-production environment by sending traversal-like language or namespace values and confirming the application rejects them before filesystem access, returns a controlled validation error, and does not attempt to open paths outside the locale directory. Verify logs do not show attempted reads or writes to paths containing traversal sequences and that normalized path checks constrain access to the configured locale root.

Typical attack path

1. Identify a Node.js or Deno application using i18next with filesystem-backed translation loading.
2. Find a user-controllable language or namespace input, such as a query parameter, cookie, header, route segment, or localization middleware field.
3. Submit traversal payloads in `lng` or `ns`, for example values containing `../`, absolute-path fragments, encoded separators, control characters, or unusually long strings.
4. Observe application responses, errors, logs, timing differences, or returned localization output to determine whether arbitrary filesystem paths are being accessed.
5. Attempt to read high-value local files such as application configuration, environment files, credential files, source files, or operating system account files.
6. If translation writing is enabled, attempt to overwrite files reachable by the application process outside the intended locale directory.

How to detect it

Review HTTP access logs, reverse proxy logs, application logs, i18next debug logs, and error telemetry for suspicious language or namespace values. Focus on requests containing traversal sequences in `lng`, `ns`, locale route segments, language cookies, or language-related headers. Look for attempts to access sensitive files such as `/etc/passwd`, `/etc/shadow`, `.env`, cloud credential files, package manifests, SSH keys, or Windows system paths. Application logs may show filesystem errors such as `ENOENT`, `EACCES`, `EINVAL`, or attempted translation load paths containing `../` or encoded separator variants. If write behavior was enabled, examine locale directories and nearby writable paths for unexpected files, modified translation JSON files, web-accessible artifacts, or files with timestamps corresponding to suspicious requests. Correlate suspicious requests with outbound responses, unusual 200 responses for localization endpoints, spikes in 4xx/5xx errors, and file integrity monitoring events showing reads or writes outside expected locale directories.

• lng=../
• lng=..%2f
• lng=..%2F
• lng=..%5c
• lng=..%5C
• lng=%2e%2e%2f
• lng=%2e%2e/
• lng=....//
• lng=../../../../etc/passwd
• lng=../../../../etc/shadow
• lng=../../../../proc/self/environ
• lng=../../../../app/.env
• lng=../../../../.env
• lng=../../../../root/.ssh/id_rsa
• lng=../../../../home
• lng=C:\\Windows\\win.ini
• lng=..\\..\\..\\Windows\\win.ini
• ns=../
• ns=..%2f
• ns=..%2F
• ns=..%5c
• ns=..%5C
• ns=%2e%2e%2f
• ns=../../../../etc/passwd
• ns=../../../../proc/self/environ
• ns=../../../../app/.env
• ns=../../../../.env
• ns=..\\..\\..\\Windows\\win.ini
• Accept-Language: ../
• Accept-Language: ..%2f
• Accept-Language: ../../../../etc/passwd
• i18next=
• i18next=../
• i18next=..%2f
• ENOENT
• EACCES
• i18next-fs-backend
• /etc/passwd
• /proc/self/environ
• /.env
• ..\\..\\
• ../

What your security team should do

• Inventory applications and services using `i18next-fs-backend`, including transitive dependencies in Node.js and Deno projects.
• Prioritize internet-facing applications where language or namespace is influenced by query strings, cookies, headers, route parameters, or localization middleware.
• Upgrade all affected deployments to `i18next-fs-backend` 2.6.4 or later and redeploy from clean, locked dependency manifests.
• Add strict allowlist validation for supported language and namespace values at the HTTP boundary.
• Disable translation-writing features such as missing-key persistence unless operationally required.
• Harden runtime permissions so the application process cannot read secrets or write outside required application directories.
• Search web, application, and error logs for traversal payloads in localization-related parameters and headers over the period since publication and earlier if the component was previously exposed.
• Add regression tests that verify traversal and malformed localization values are rejected.