i18next-http-backend EUVD-2026-112360

Two preconditions must both hold: (1) the loadPath or addPath template must place {{lng}} or {{ns}} in the URL query string (e.g. the README multiload shape /locales/resources.json?lng={{lng}}&ns={{ns}}), and (2) the attacker must control the language or namespace value - which in normal setups comes from ?lng=, a cookie, localStorage, or the Accept-Language header (and i18next-http-middleware's LanguageDetector on the server). Explicitly NOT exploitable: the default path template /locales/{{lng}}/{{ns}}.json and any other path-only template (the earlier 3.0.5 fix already blocks ? in the path position), and applications that restrict languages via a supportedLngs allowlist. The injected '+' multiload form (de+en) continues to work normally. Realistic impact is further limited by how the target translations API branches on the injected/overridden parameters.

All signals converge on low real-world priority. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) scores 3.7 (Low): network-reachable and unauthenticated (PR:N), but AC:H and limited confidentiality-only impact (C:L, I:N, A:N). The AC:H is well-grounded in the evidence - exploitation requires a non-default query-shaped loadPath/addPath template, so the raw CVSS understates how conditional this is. The vuln.today Decision label is 'monitor' (not act_now/emergency), consistent with the low score. There is NO CISA KEV listing (not actively exploited) and NO EPSS score was provided in the input, so probability-of-exploitation cannot be quantified here. A detailed public proof-of-concept is published in the GHSA advisory with full reproduction steps and captured output, so working exploitation is demonstrable - but PoC availability is a distinct signal from active exploitation and should not be read as the latter. Net: this is a genuine but low-severity, configuration-dependent issue (an incomplete fix for CVE-2026-41691), appropriately triaged as 'monitor/patch on normal cadence' rather than an emergency. Missing data to note: EPSS absent; no KEV; impact magnitude depends on downstream translations-API behavior, which the sources cannot enumerate.

On a server-side (SSR/Node) app using i18next-http-middleware with a README-style multiload template like /locales/resources.json?lng={{lng}}&ns={{ns}}, an unauthenticated visitor requests GET /?lng=de%26ns%3Dprivate%26admin%3Dtrue. Because & and = were not rejected, the application server then sends …?lng=de&ns=private&admin=true&ns=common to its own internal/partner translations API using the server's network position and credentials, potentially exposing other namespaces or tenants or altering backend behavior. A public PoC in the GHSA advisory demonstrates this end-to-end; the browser-side variant achieves the same via a crafted ?lng= link against the victim's same-origin request.