I18Next Http Backend
Monthly
Path traversal and URL-structure injection in i18next-http-backend before 3.0.5 let remote unauthenticated attackers who control the lng or ns value reshape the translation-request URL; this is the default exposure when i18next-browser-languagedetector reads ?lng=, cookies, localStorage or request headers. Real impact depends on deployment: file:// or internal loadPath values in server-side rendering can yield arbitrary host file read or SSRF, and prefix-based authorization can be bypassed, while static client-side locale fetching over HTTP usually sees only benign path changes or fragment truncation. No public exploit has been identified at time of analysis; EPSS is 0.05% (15th percentile), it is not in CISA KEV, and the vendor fix is 3.0.5, with a vuln.today priority label of act_now.
Query-parameter injection in i18next-http-backend before 4.0.4 lets attacker-controlled language or namespace values add or override parameters on outgoing translation requests whenever a loadPath or addPath template places {{lng}} or {{ns}} in the query string, such as the multiload shape /locales/resources.json?lng={{lng}}&ns={{ns}}. Server-side deployments using i18next-http-middleware's LanguageDetector are the most exposed case: an unauthenticated visitor supplying ?lng=de%26ns%3Dprivate%26admin%3Dtrue can make the application issue a request to its own translations API as ...?lng=de&ns=private&admin=true&ns=common, leveraging the server's network position and credentials; on the browser side the same crafted link affects the victim's same-origin request. Severity is bounded (CVSS 3.1 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) because exploitation requires both a query-shaped template and attacker control of the language or namespace value, and real impact depends on how the translations API branches on the injected parameters; the default /locales/{{lng}}/{{ns}}.json template and supportedLngs-restricted applications are unaffected, the advisory publishes a proof-of-concept script, and no confirmed active exploitation is reported in the available sources (priority label: monitor).
Protocol-relative URL injection in i18next-http-backend before 4.0.3 lets an attacker who controls an i18next namespace value redirect translation fetches to an attacker-chosen origin when the loadPath/addPath template places {{ns}} directly after a leading slash. The per-value validation added for the earlier GHSA-xvq9-wjp8-hwqf fix rejects '//evil.example' but still permits a single leading '/', which the template's own '/' turns into '//evil.example/en.json' - a URL browsers resolve off-origin, yielding translation content injection and, where translations are rendered as HTML, cross-site scripting. Exploitation requires the non-default template, attacker-controlled namespace input (applications usually set namespaces in code), and a browser context; Node is not affected, the default '/locales/{{lng}}/{{ns}}.json' template is not affected, and the issue is not known to be exploited in the wild. A minimal proof-of-concept is published in the advisory and was re-verified against 4.0.2, and the release 4.0.3 contains the fix.
URL injection and server-side request forgery (SSRF) in i18next-http-backend prior to 4.0.2 allows attacker-controlled language or namespace values to redirect translation resource requests away from the intended origin, but only when the application configures a custom loadPath or addPath template that begins directly with the {{lng}} or {{ns}} placeholder. Because the placeholder must occupy the URL's structural beginning for a colon to form an absolute URL (or, in browsers, a double-slash namespace to form a protocol-relative URL), the default '/locales/{{lng}}/{{ns}}.json' template and any template with a leading path or origin prefix are unaffected; this uncommon configuration and the need to control the language/namespace input drive the High attack complexity rating. Impact is limited to low confidentiality loss (blind SSRF/URL injection with no integrity or availability effect), and all signals indicate a low-priority issue - no public exploit code and no confirmed active exploitation were identified at time of analysis. The issue is fixed in version 4.0.2.
Path traversal and URL-structure injection in i18next-http-backend before 3.0.5 let remote unauthenticated attackers who control the lng or ns value reshape the translation-request URL; this is the default exposure when i18next-browser-languagedetector reads ?lng=, cookies, localStorage or request headers. Real impact depends on deployment: file:// or internal loadPath values in server-side rendering can yield arbitrary host file read or SSRF, and prefix-based authorization can be bypassed, while static client-side locale fetching over HTTP usually sees only benign path changes or fragment truncation. No public exploit has been identified at time of analysis; EPSS is 0.05% (15th percentile), it is not in CISA KEV, and the vendor fix is 3.0.5, with a vuln.today priority label of act_now.
Query-parameter injection in i18next-http-backend before 4.0.4 lets attacker-controlled language or namespace values add or override parameters on outgoing translation requests whenever a loadPath or addPath template places {{lng}} or {{ns}} in the query string, such as the multiload shape /locales/resources.json?lng={{lng}}&ns={{ns}}. Server-side deployments using i18next-http-middleware's LanguageDetector are the most exposed case: an unauthenticated visitor supplying ?lng=de%26ns%3Dprivate%26admin%3Dtrue can make the application issue a request to its own translations API as ...?lng=de&ns=private&admin=true&ns=common, leveraging the server's network position and credentials; on the browser side the same crafted link affects the victim's same-origin request. Severity is bounded (CVSS 3.1 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) because exploitation requires both a query-shaped template and attacker control of the language or namespace value, and real impact depends on how the translations API branches on the injected parameters; the default /locales/{{lng}}/{{ns}}.json template and supportedLngs-restricted applications are unaffected, the advisory publishes a proof-of-concept script, and no confirmed active exploitation is reported in the available sources (priority label: monitor).
Protocol-relative URL injection in i18next-http-backend before 4.0.3 lets an attacker who controls an i18next namespace value redirect translation fetches to an attacker-chosen origin when the loadPath/addPath template places {{ns}} directly after a leading slash. The per-value validation added for the earlier GHSA-xvq9-wjp8-hwqf fix rejects '//evil.example' but still permits a single leading '/', which the template's own '/' turns into '//evil.example/en.json' - a URL browsers resolve off-origin, yielding translation content injection and, where translations are rendered as HTML, cross-site scripting. Exploitation requires the non-default template, attacker-controlled namespace input (applications usually set namespaces in code), and a browser context; Node is not affected, the default '/locales/{{lng}}/{{ns}}.json' template is not affected, and the issue is not known to be exploited in the wild. A minimal proof-of-concept is published in the advisory and was re-verified against 4.0.2, and the release 4.0.3 contains the fix.
URL injection and server-side request forgery (SSRF) in i18next-http-backend prior to 4.0.2 allows attacker-controlled language or namespace values to redirect translation resource requests away from the intended origin, but only when the application configures a custom loadPath or addPath template that begins directly with the {{lng}} or {{ns}} placeholder. Because the placeholder must occupy the URL's structural beginning for a colon to form an absolute URL (or, in browsers, a double-slash namespace to form a protocol-relative URL), the default '/locales/{{lng}}/{{ns}}.json' template and any template with a leading path or origin prefix are unaffected; this uncommon configuration and the need to control the language/namespace input drive the High attack complexity rating. Impact is limited to low confidentiality loss (blind SSRF/URL injection with no integrity or availability effect), and all signals indicate a low-priority issue - no public exploit code and no confirmed active exploitation were identified at time of analysis. The issue is fixed in version 4.0.2.