CVE-2026-115730 in i18next-http-backend
Summary
by MITRE • 10/23/2026
i18next-http-backend 4.0.2 contains an incomplete fix in interpolateUrl() that allows attackers to redirect translation requests by supplying an ns value starting with a slash. Attackers controlling the namespace value can form a protocol-relative URL in loadPath or addPath templates to load attacker-hosted translations, enabling UI content injection and cross-site scripting.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in i18next-http-backend version 4.0.2 represents a critical flaw within the interpolateUrl function, which is responsible for constructing URLs used to fetch translation resources from remote servers. This component serves as a bridge between internationalization libraries and backend storage systems, allowing applications to dynamically load language-specific content based on user preferences or configuration settings. The core issue stems from an incomplete remediation of a previous security defect, where input validation mechanisms failed to adequately sanitize the namespace parameter before it was integrated into URL templates. Specifically, when a malicious actor supplies a namespace value that begins with a forward slash character, the interpolation logic incorrectly interprets this as part of a path structure rather than a simple string identifier. This misinterpretation allows the attacker to manipulate the resulting loadPath or addUrl template variables in ways that deviate from the intended application behavior.
From a technical perspective, the flaw enables protocol-relative URL injection. By starting the namespace with a slash, an attacker can effectively break out of the expected relative path context and inject absolute paths or domain references into the request URL. This capability is particularly dangerous because it allows for the loading of translation files from arbitrary external hosts controlled by the adversary. Instead of retrieving legitimate JSON or XML translation assets from the application's designated backend server, the client-side JavaScript will fetch content from a malicious source. This bypasses same-origin policy protections in certain contexts and exploits the trust relationship between the frontend application and its data sources. The vulnerability is classified under CWE-20 as Improper Input Validation because the system fails to restrict or reject inputs that contain characters leading to URL manipulation, specifically failing to validate that namespace values conform to expected alphanumeric patterns without special path delimiters.
The operational impact of this vulnerability extends beyond simple redirection and poses a severe risk to application integrity and user security. Once an attacker successfully injects a malicious translation file from their own server, they can embed arbitrary JavaScript code within the JSON or XML payload. When i18next processes these translations for display in the web interface, the embedded scripts are executed by the victim's browser. This leads directly to Cross-Site Scripting (XSS) attacks, allowing attackers to steal session cookies, hijack user accounts, perform actions on behalf of victims, or deface the application interface. Furthermore, this vulnerability aligns with MITRE ATT&CK technique T1059.007, which covers JavaScript execution in web browsers, and can be leveraged as part of a broader attack chain involving UI redressing or credential harvesting through phishing pages hosted on the attacker-controlled domain.
Mitigation strategies must address both immediate remediation and long-term defensive posture improvements. The most effective solution is to upgrade i18next-http-backend to version 4.0.3 or later, where this specific input validation flaw has been corrected by enforcing stricter constraints on namespace values to prevent slash injection. For applications unable to update immediately due to dependency conflicts, a temporary workaround involves implementing custom middleware or wrapper functions that sanitize the namespace parameter before it is passed to the backend loader. This sanitization should strip any leading slashes and validate that the input consists only of allowed characters such as letters, numbers, hyphens, and underscores. Additionally, developers should enforce Content Security Policy headers with strict script-src directives to mitigate the impact of successful XSS attempts by preventing inline script execution unless explicitly whitelisted. Regular security audits of internationalization configurations are recommended to ensure that dynamic content loading mechanisms remain robust against evolving injection techniques.