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

CVE-2026-41691 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. EPSS exploitation probability: 0.1%.

Is there a patch available for CVE-2026-41691?

Yes, a patch is available for CVE-2026-41691. Update the affected software to the latest version immediately.

i18next-http-backend CVE-2026-41691

EUVD-2026-28438 MEDIUM

Path Traversal (CWE-22)

2026-05-07 GitHub_M

Path Traversal I18Next Http Backend

6.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:L/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:L/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

None

Lifecycle Timeline

Patch available

May 07, 2026 - 22:02 EUVD

Source Code Evidence Fetched

May 07, 2026 - 21:00 vuln.today

Analysis Generated

May 07, 2026 - 21:00 vuln.today

CVE Published

May 07, 2026 - 20:09 nvd

MEDIUM 6.5

Blast Radius

ecosystem impact

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

9 npm packages depend on i18next-http-backend (5 direct, 4 indirect)

Ecosystem-wide dependent count for version 3.0.5.

DescriptionGitHub Advisory

Copilot said: i18nextify is a JavaScript library that adds i18nextify is a JavaScript library that adds website internationalization via a script tag, without source code changes. Versions prior to 3.0.5 interpolate the lng and ns values directly into the configured loadPath / addPath URL template without any encoding, validation, or path sanitisation. When an application exposes the language-code selection to user-controlled input (the default - i18next-browser-languagedetector reads ?lng= query params, cookies, localStorage, and request headers), an attacker can inject characters that change the structure of the outgoing request URL. This is a single URL-injection vulnerability. The attacker-controlled value is neutralised before it is used as part of an output URL string; the attack shape covers both path traversal and broader URL-structure injection - both are closed by the one interpolateUrl sanitisation fix. This issue has been fixed in version 3.0.5. If users cannot upgrade immediately, they can work around the issue by sanitising lng / ns before they reach i18next (strip .., /, \, ?, #, %, whitespace, and control characters; cap the length).

AnalysisAI

Path traversal and URL injection in i18next-http-backend prior to version 3.0.5 allows remote attackers to manipulate request URLs by injecting unsanitized language (lng) and namespace (ns) parameters, potentially leading to server-side request forgery (SSRF), path-based authorization bypass, or arbitrary file reads in SSR deployments. The vulnerability affects all applications using the library with user-controlled language selection via query parameters, cookies, localStorage, or request headers-the default configuration. Vendor-released patch: version 3.0.5.

Technical ContextAI

i18next-http-backend is a JavaScript library that loads translation files dynamically by interpolating user-controlled language and namespace values into URL templates (loadPath and addPath). The core issue stems from the interpolate() function in lib/utils.js, which previously returned raw values without URL encoding, validation, or path sanitization. Unlike the addQueryString() helper which correctly used encodeURIComponent() for query parameters, the URL-path substitution was completely unprotected. When i18next-browser-languagedetector (the default language detector) reads lng from query parameters (?lng=), cookies, localStorage, or HTTP headers, an attacker can inject path-traversal sequences (../, ..), URL-structure characters (?, #, %), percent-encoded bypasses (%2F for /), or control characters to alter the request URL structure. The root cause is insufficient input validation at the point where user-controlled strings are interpolated into URL templates (CWE-22: Improper Limitation of a Pathname to a Restricted Directory).

RemediationAI

Upgrade i18next-http-backend to version 3.0.5 or later immediately. The patched version introduces the isSafeUrlSegment() validator that refuses to build request URLs when lng or ns values contain path-traversal sequences (.., /, \), URL-structure injection characters (?, #, %, @), whitespace, control characters (CR/LF/NUL/C0/C1), prototype pollution keys, or exceed 128 characters. The fix is permissive for legitimate language codes (BCP-47 format, underscores, hyphens, dots, plus-separated multi-language lists). For immediate mitigation without upgrading, implement server-side input sanitization before values reach i18next: strip or reject .., /, \, ?, #, %, @, whitespace, and control characters; enforce a maximum length of 128 characters on lng and ns parameters. Additionally, ensure loadPath and addPath URLs do not use file:// schemes in production (use http:// or https://), validate and restrict the URL schemes accepted by the backend, and do not embed basic-auth credentials in loadPath/addPath URLs (the patch also redacts credentials from error messages). Apply the patch as the primary remediation-workarounds are incomplete and error-prone. See GitHub advisory at https://github.com/i18next/i18next-http-backend/security/advisories/GHSA-q89c-q3h5-w34g for the full fix details.