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.
Impact i18next-http-middleware ≤ 3.9.6's missingKeyHandler blocked the literal request-body keys proto, constructor, and prototype (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as "proto.polluted". Downstream backends that split the missing-key string on a configured keySeparator (notably i18next-fs-backend ≤ 2.6.5) hand these keys to an unguarded setPath() walker that writes to Object.prototype. Applications that expose missingKeyHandler to untrusted input AND use i18next-fs-backend ≤ 2.6.5 are directly exploitable for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. Patches Fixed in i18next-http-middleware 3.9.7. A new utils.hasUnsafeKeySegment(key, keySeparator) helper is now used…
Recommended action: Upgrade to 3.9.7 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-middleware prior to 3.9.3 pass the user-controlled lng and ns values from getResourcesHandler directly into i18next.services.backendConnector.load(languages, namespaces, …) without any sanitisation. Depending on which backend is configured, the unvalidated path segments enable one of two attacks: - Filesystem path traversal when the middleware is paired with i18next-fs-backend (or any backend that interpolates lng / ns into a filesystem path). - Server-Side Request Forgery (SSRF) when the middleware is paired with i18next-http-backend (or any backend that interpolates into an HTTP URL). Example request: with i18next-fs-backend reads the attacker-chosen file from disk; with i18next-http-backend reshapes the outgoing URL to target an internal service. Impact - Arbitrary file read via fs-style backends — any file the Node process can read becomes reachable (source, configuration, .ssh keys, .env, Docker secrets, etc.). - SSRF via http-style backends —…
Recommended action: Upgrade to 3.9.3 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-middleware prior to 3.9.3 wrote user-controlled language values into the Content-Language response header after passing them through utils.escape(), which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older i18next (< 19.5.0) that still exercised the backward-compatibility fallback at LanguageDetector.js:100 or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled lng parameter reached res.setHeader('Content-Language', ...) verbatim. Impact Two concrete outcomes depending on the Node.js version: - Node.js < 14.6.0 — HTTP response splitting. An attacker crafting a request like GET /?lng=en%0d%0aX-Injected%3A+malicious could inject arbitrary additional HTTP response headers, enabling: - Session fixation via an injected Set-Cookie - Cache poisoning (injecting Location, Content-Type, etc.) - Reflected XSS in controlled response bodies -…
Recommended action: Upgrade to 3.9.3 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-middleware prior to 3.9.3 pass user-controlled lng and ns parameters to two internal paths that use them in ways that enable prototype pollution and, depending on the configured backend, path traversal or SSRF. The vulnerable entry points are unauthenticated HTTP handlers that are part of the middleware's public API: - getResourcesHandler — reads lng/ns from query parameters or route params and passes them unvalidated to: - utils.setPath(resources, [lng, ns], ...) — the setPath helper did not guard against proto, constructor, or prototype keys, writing into Object.prototype when those values were supplied. - i18next.services.backendConnector.load(languages, namespaces, ...) — depending on the configured backend, unvalidated path segments enabled filesystem path traversal (e.g. with i18next-fs-backend) or SSRF (e.g. with i18next-http-backend). - A namespaces.forEach(ns = i18next.options.ns.push(ns)) loop additionally performed permanent, unbounded…
Recommended action: Upgrade to 3.9.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.