Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The URL-segment check added for GHSA-q89c-q3h5-w34g blocks `?`, `#`, `%`, `:`, `/` and `@` in `lng`, but not `&` or `=`, and the checked value is inserted into the URL without encoding. The README documents a multiload loadPath of the form `/locales/resources.json?lng=de+en&ns=ns1+ns2`. With a template like that, an attacker who controls the language value can add or override query parameters on the request the backend sends. By default the language comes from `?lng=`, a cookie or `Accept-Language`. This is the "query-string injection" impact described in GHSA-q89c; only the `?` form was closed. Server side (Express + i18next-http-middleware, default options), `GET /?lng=de%26ns%3Dprivate%26admin%3Dtrue` makes the application request `…?lng=de&ns=private&admin=true&ns=common` from its own translations API. Details The checks are in `lib/utils.js`. The base check (https://github.com/i18next/i18next-http-backend/blob/v4.0.3/lib/utils.js#L26-L44) rejects: - empty or…
Recommended action: Upgrade to 4.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected versions Verified on 4.0.2 (latest on npm) and on commit 07e0288 (the GHSA-xvq9-wjp8-hwqf fix). Earlier 3.x/4.x versions that allow / in ns are likely affected too. Not verified on them. Impact Same class as GHSA-xvq9-wjp8-hwqf and GHSA-q89c-q3h5-w34g: when an attacker controls the namespace value, the request goes to an attacker-chosen origin. In a browser this loads attacker-controlled translation JSON (content injection into the UI, and XSS where translations are rendered as HTML). The precondition is a template with {{ns}} right after a leading /, for example /{{ns}}/{{lng}}.json. The 4.0.2 maintainer note says templates with a leading / are safe. This case is outside that statement. Root cause isSafeNsUrlSegment rejects any ns containing //, but allows a single leading / (needed for nested namespaces like a/b). Interpolation into /{{ns}}/... puts the template's own / next to the value's /. The result starts with //, which is a protocol-relative URL. The check runs on…
Recommended action: Upgrade to 4.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There is an SSRF vulnerability when using i18next-http-backend. A colon in an attacker-controlled language value can make a custom path template request an unintended origin. This is reachable under the following conditions: Attacker controls i18next language or namespace input that is interpolated into loadPath. Proof of Concept Run: The expected result is: Why the Previous Patch Was Incomplete This vulnerability is caused by an incomplete patch for CVE-2026-41691. The previous patch addressed the following behavior: Original hardening blocks path traversal and selected URL-control characters in lng/ns. The following bypass remains in the current release: lng=http:127.0.0.1:<port with loadPath={{lng}}/{{ns}}.json; colon is not blocked and produces an outbound request. Impact The attacker-controlled language or namespace value can redirect the backend request to an unintended origin, resulting in URL injection and possible SSRF. Recommended Fix Parse the final URL and require it to…
Recommended action: Upgrade to 4.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of i18next-http-backend 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. Affected call sites: - readAny — lib/index.js:64: interpolate(resolvedLoadPath, { lng: languages.join('+'), ns: namespaces.join('+') }) - create — lib/index.js:123 (pre-patch): interpolate(addPath, { lng, ns: namespace }) The helper interpolate (lib/utils.js) previously returned the raw value with no encoding. In contrast, addQueryString already correctly uses encodeURIComponent for each query-string param — only the URL-path substitution was unprotected. Impact An attacker who can influence the…
Recommended action: Upgrade to 3.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.