Description

i18next-http-backend is a backend layer for i18next that loads translation resources in Node.js, browsers, and Deno. Prior to 4.0.2, attacker-controlled language or namespace values interpolated into a custom loadPath or addPath that begins directly with {{lng}} or {{ns}} can make colon-based input become an absolute URL or, in browsers, make a double-slash namespace become a protocol-relative URL. The resulting request can leave the intended origin and cause URL injection or server-side request forgery. The default /locales/{{lng}}/{{ns}}.json template and templates with a leading path or origin are not affected because the placeholder does not occupy the URL's structural beginning. This issue is fixed in version 4.0.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-10-06T15:17:17.173Z",
  "pubdate": "2026-10-06T15:17:17.173Z",
  "executiveSummary": "A URL injection and Server-Side Request Forgery (SSRF) vulnerability exists in i18next-http-backend versions prior to 4.0.2.\nThe vulnerability occurs due to improper handling of interpolated values within the loadPath or addPath configurations when these paths commence directly with the {{lng}} or {{ns}} placeholders.\nAn attacker can supply malicious language or namespace inputs containing colon-based characters or double-slashes to manipulate the intended request URL.\nThis allows the client or server to initiate requests to arbitrary origins, effectively bypassing intended resource retrieval boundaries.\nThe vulnerability affects both browser and Node.js environments utilizing custom path templates where placeholders are positioned at the start of the URI string.\nImpact includes SSRF, unauthorized data access, and potential exfiltration of sensitive internal network information.\nExploitation requires the application to permit user-controlled input to influence the language or namespace parameters used in translation loading requests.\nDefault configurations using static prefixes like '/locales/' are unaffected as the placeholders do not occupy the structural beginning of the path.",
  "technicalDetails": "The root cause of this vulnerability lies in the path interpolation logic within i18next-http-backend. The library dynamically constructs network requests by replacing {{lng}} and {{ns}} placeholders with user-supplied parameters.\nWhen a developer defines a custom configuration where the loadPath or addPath begins directly with these placeholders (e.g., '{{lng}}/{{ns}}.json'), the library fails to sanitize or validate the interpolated values against structural URI delimiters.\nIn browser environments, an attacker providing a namespace input containing a double-slash (e.g., //attacker.com) results in a protocol-relative URL injection. This causes the browser to fetch translation resources from an external, attacker-controlled origin instead of the intended backend.\nIn Node.js or browser environments, providing a value containing a colon (e.g., 'http://evil.com/path') allows an attacker to transform a relative path into an absolute URL. Because the placeholder is at the beginning of the string, the resulting concatenated string is interpreted as a fully qualified URI by the underlying request library.\nThe attack flow proceeds as follows: 1) The application initializes i18next-http-backend with an insecure custom loadPath template starting with a placeholder. 2) The application accepts user-supplied locale or namespace input (e.g., via URL parameters or header values). 3) The attacker submits a crafted string containing colon or double-slash characters. 4) The backend library interpolates the malicious string at the start of the URI. 5) The network request is dispatched to the injected origin.\nThis behavior facilitates Server-Side Request Forgery (SSRF) when performed on the server side, as the application can be forced to make requests to internal services or infrastructure that would otherwise be protected by network boundaries. In the browser, this constitutes a Cross-Origin Request vulnerability, potentially leading to unauthorized data exposure if the malicious server returns crafted JSON responses.\nThe vulnerability is limited to configurations where placeholders occupy the beginning of the URI structure, as the concatenation logic relies on the prefix to maintain structural integrity. Configurations employing hardcoded base paths act as a natural mitigation by constraining the relative path within the defined origin.\nAffected versions include all releases prior to 4.0.2. No authentication is required to trigger this, provided the attacker can influence the language or namespace values processed by the backend."
}