i18next-http-backend EUVD-2026-28438

Exploitation requires two deployment facts. (1) The application must expose the lng (or ns) selection to attacker-controlled input - this is the DEFAULT when i18next-browser-languagedetector is used, since it reads the ?lng= query parameter, cookies, localStorage, and request headers. (2) The configured loadPath / addPath template must reference a resource where URL restructuring matters: the high-impact outcomes (arbitrary host file read, SSRF) occur specifically when loadPath is a file:// or internal/private URL in a server-side-rendering pipeline, and path-based authorization bypass occurs on servers that segment access by URL prefix. Exploitation is unauthenticated (PR:N) and needs no user interaction. LIMITING FACTORS: a purely client-side browser deployment serving static locale files over HTTP sees mostly benign path changes or fragment truncation rather than file disclosure; an app that does not feed untrusted input into lng/ns, or that already sanitises it, is not exploitable. The only complete fix is upgrading to 3.0.5 - the vendor states there is no workaround short of upgrading, though sanitising lng/ns (strip .., /, \, ?, #, %, whitespace, control chars; cap length) before they reach i18next is offered as interim mitigation.

The input's CVSS 3.1 base score is 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), which rates this Critical on severity alone, but the exploitation signals pull the real-world priority down sharply: EPSS is only 0.05% (15th percentile), SSVC reports Exploitation: none, and the CVE is NOT in CISA KEV. SSVC does flag Automatable: yes with Technical Impact: partial, and the vuln.today Decision label is act_now, so this is treated as a patch-now item despite the low probability - the urgency is driven by ease of automation and the default-on exposure of the language code, not by observed attack activity. The signals are therefore consistent but point to different things: high potential impact and easy triggering versus no evidence of in-the-wild use (targeted or widespread). The headline C:H/I:H appears optimistic for the common case - the advisory's own worst case (arbitrary host file read / SSRF) only materialises when loadPath is a file:// or internal URL in a server-side-rendering pipeline; in a plain browser deployment serving static locale files the practical effect is closer to fragment truncation, benign path changes, or conditional query-flag injection. Treat as a genuine act_now patch item because the fix is available and the trigger is user-controlled by default, but recognise the C:H/I:H rating assumes a sensitive loadPath that not every deployment has.

An application uses i18next-http-backend with its default language detection, so an attacker sets ?lng=../../config (or an internal/file-scheme target) and the library interpolates that value straight into the loadPath URL template without sanitisation, altering the outgoing request structure. On a server-side-rendering pipeline whose loadPath uses file:// or an internal URL, this becomes SSRF or arbitrary host-file disclosure; on servers that authorise by URL prefix it can bypass path-based access controls. No public working exploit is referenced in the input - the advisory supplies illustrative payloads only - and exploitation is unauthenticated (PR:N).