What is the CVSS score of CVE-2026-41693?

CVE-2026-41693 has a CVSS 3.1 base score of 8.2 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N. EPSS exploitation probability: 0.0%.

Which versions of i18next-fs-backend are affected by CVE-2026-41693?

CVE-2026-41693 is a critical path traversal vulnerability in i18next-fs-backend that allows unauthenticated attackers to read sensitive files like /etc/passwd or overwrite application files through…. A patch is available.

How to fix or mitigate CVE-2026-41693?

Within 24 hours: Identify all applications using i18next-fs-backend by scanning package.json and npm audit output; immediately disable automatic language detection via query parameters and restrict language selection to a hardcoded whitelist. Within 7 days: Upgrade i18next-fs-backend to version 2.6.4 or later across all affected systems; if upgrade is blocked, implement network-level input validation to reject any language parameter containing '../' or path traversal sequences. Within 30 days: Conduct file access logs review for patterns matching traversal attempts (e.g., 'lng=../../../../'); perform full security audit of i18next configuration to ensure locale files cannot be executable.

i18next-fs-backend CVE-2026-41693

EUVD-2026-28793 HIGH

External Control of File Name or Path (CWE-73)

2026-05-08 GitHub_M

Node.js Information Disclosure

8.2

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.2 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

Low

Availability

None

Lifecycle Timeline

Patch available

May 08, 2026 - 17:02 EUVD

Source Code Evidence Fetched

May 08, 2026 - 16:31 vuln.today

Analysis Generated

May 08, 2026 - 16:31 vuln.today

CVE Published

May 08, 2026 - 15:38 nvd

HIGH 8.2

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

2 npm packages depend on i18next-fs-backend (2 direct, 0 indirect)

Ecosystem-wide dependent count for version 2.6.4.

DescriptionGitHub Advisory

i18next-fs-backend is a backend layer for i18next using in Node.js and for Deno to load translations from the filesystem. Prior to version 2.6.4, i18next-fs-backend substitutes the lng and ns options directly into the configured loadPath / addPath templates and then read / write the resulting file from disk. The interpolation is unencoded and unvalidated, so a crafted lng or ns value - containing .., a path separator, a control character, a prototype key, or simply an unexpectedly long string - allows an attacker who can influence either value to read or overwrite files outside the intended locale directory. When lng / ns are derived from untrusted input (request-scoped i18next instances behind an HTTP layer such as i18next-http-middleware, or any framework that lets the end user pick the language via query string, cookie, or header), a single request such as ?lng=../../../../etc/passwd causes the backend to attempt to read that path. This issue has been patched in version 2.6.4.

AnalysisAI

Path traversal in i18next-fs-backend allows remote unauthenticated attackers to read arbitrary files (including /etc/passwd) or overwrite application files when language/namespace parameters derive from user input. Applications exposing i18next language detection via query strings, cookies, or headers (common with i18next-http-middleware or i18next-browser-languagedetector) are vulnerable to immediate exploitation with zero authentication (CVSS AV:N/AC:L/PR:N/UI:N). GitHub security advisory confirms the vulnerability with proof-of-concept parameter ?lng=../../../../etc/passwd. Fixed in version 2.6.4; vulnerable versions also support eval-based .js/.ts locale loading, creating a code execution chain when traversal targets executable files.

Technical ContextAI

i18next-fs-backend is a Node.js/Deno filesystem persistence layer for the i18next internationalization framework (npm package i18next-fs-backend, CPE 2.3:a:i18next:i18next-fs-backend). The backend interpolates caller-supplied lng (language code) and ns (namespace) parameters directly into loadPath and addPath template strings (e.g., /locales/{{lng}}/{{ns}}.json) without path sanitization or traversal prevention. The interpolate helper in lib/utils.js performs raw string substitution with no encoding-unlike i18next-http-backend's addQueryString which validates URL components. CWE-73 (External Control of File Name or Path) is the root cause: attacker-controlled input dictates filesystem operations. The vulnerability surfaces in three call sites: read() (line 38, loads translation files), removeFile() (line 101), and writeFile() (line 127, for missing-key persistence). When applications use i18next-http-middleware or i18next-browser-languagedetector-which automatically populate lng from ?lng= query parameters, Accept-Language headers, or cookies-the file path becomes fully attacker-controlled with a single HTTP request.

RemediationAI

Upgrade i18next-fs-backend to version 2.6.4 or later immediately. The patch introduces path-component validation in lib/utils.js interpolate() to reject traversal sequences (..), absolute paths, and path separators in lng/ns values before filesystem operations. Install via npm: npm install i18next-fs-backend@2.6.4 or yarn add i18next-fs-backend@2.6.4. Vendor advisory and patch details available at https://github.com/i18next/i18next-fs-backend/security/advisories/GHSA-8847-338w-5hcj. If immediate upgrade is not feasible, implement application-layer input validation: whitelist lng to ISO 639-1 two-letter codes (^[a-z]{2}(-[A-Z]{2})?$) and ns to alphanumeric namespace identifiers (^[a-zA-Z0-9_-]+$) before passing to i18next. This validation must occur before the i18next.changeLanguage() or i18next.t() call-framework-provided language detection middleware alone does not sanitize. Side effect of strict whitelisting: non-standard locale codes (e.g., zh-Hans-CN with multiple hyphens) may be rejected; adjust regex to business requirements while blocking . and / characters. Do not rely on chroot or filesystem permissions as primary mitigation-the writeFile code path can still corrupt application files within the accessible directory tree.