GHSA-q89c-q3h5-w34g is a medium-severity (CVSS 6.5) Path Traversal vulnerability in i18next-http-backend. O3 Security confirms whether GHSA-q89c-q3h5-w34g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
i18next-http-backend has Path Traversal & URL Injection via Unsanitised lng/ns
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.
i18next-http-backendnpmDescription
Summary
Versions of i18next-http-backend prior to 3.0.5 interpolate the lng and ns values directly into the configured loadPath / addPath URL template without any encoding, validation, or path sanitisation. When an application exposes the language-code selection to user-controlled input (the default — i18next-browser-languagedetector reads ?lng= query params, cookies, localStorage, and request headers), an attacker can inject characters that change the structure of the outgoing request URL.
Affected call sites:
_readAny—lib/index.js:64:interpolate(resolvedLoadPath, { lng: languages.join('+'), ns: namespaces.join('+') })create—lib/index.js:123(pre-patch):interpolate(addPath, { lng, ns: namespace })
The helper interpolate (lib/utils.js) previously returned the raw value with no encoding. In contrast, addQueryString already correctly uses encodeURIComponent for each query-string param — only the URL-path substitution was unprotected.
Impact
An attacker who can influence the resolved lng or ns value can alter the URL in several ways:
- Path traversal —
lng = '../../config'turns/locales/{{lng}}/{{ns}}.jsoninto/locales/../../config/translation.json. On a misconfigured web server, this can cause the request to target a different resource than intended; in SSR pipelines that usefile://or similar schemes forloadPath, it can read arbitrary files from the host filesystem. - Query-string injection —
lng = 'en?admin=true'turns/locales/{{lng}}/{{ns}}.jsoninto/locales/en?admin=true/translation.json. Some server frameworks parse the query portion with higher priority than the path and branch on attacker-controlled flags. - Fragment truncation —
lng = 'en#anything'silently discards the rest of the path in browser fetches (client cannot see the final URL). - URL-encoded bypasses —
lng = 'en%2F..', after server-side URL decoding, resolves toen/..— the attacker bypasses the absence of a literal/in their input.
The practical worst case is SSRF when loadPath is an internal or file-scheme URL, and path-based authorisation bypass against servers that segment access by URL prefix.
Also fixed in 3.0.5
- Per-instance
omitFetchOptions. A module-level boolean inlib/request.jswas flipped totruethe first time any backend instance hit a "not implemented" fetch error. Once flipped, all subsequent requests from all backend instances in the same module silently stripped every user-configured fetch option — including security-relevantcredentials,mode, andcache. One misbehaving instance (for example during SSR hydration or in React Native) permanently removed these protections process-wide. 3.0.5 scopes the flag to the backend'soptionsobject (options._omitFetchOptions) so one instance's fallback cannot pollute siblings. - Log forging via control characters in
lng/ns. Error callbacks embedded the rawlng/ns/URL in the message string. Crafted CR/LF values could inject fake log lines into file-backed log aggregators (CWE-117). 3.0.5 strips C0/C1 control chars before concatenation. - Basic-auth credentials leaked into error callbacks. If
loadPathcontained auser:password@hostauthority, the full URL (including the credentials) ended up in the error message strings returned to the caller. 3.0.5 redactsuser:password@before logging. - Prototype-pollution amplification via
for...in.addQueryStringand the XHRcustomHeadersloop usedfor...inwhich walks the prototype chain. PollutedObject.prototypeentries could leak into URL query parameters and request headers. 3.0.5 usesObject.keysand an explicit prototype-key guard.
Affected versions
All versions of i18next-http-backend prior to 3.0.5.
Patch
Fixed in 3.0.5. Summary of the hardening:
- New
utils.interpolateUrl(used by_readAnyandcreate) returnsnullif any substitution fails the URL-segment safety check (blocks..,/,\,?,#,%,@, whitespace, control chars, prototype keys, and values > 128 chars). Multi-language joins (en+de) are validated per-segment. The call sites now refuse to issue a request when the check fails and call back with a clear error. omitFetchOptionsis stored per-instance onoptions._omitFetchOptions.- Error-callback messages sanitise strings and redact URL credentials.
for...inover untrusted objects replaced withObject.keys+ prototype-key guard.
Workarounds
No workaround short of upgrading. If you cannot upgrade immediately, sanitise lng / ns yourself before they reach i18next (strip .., /, \, ?, #, %, whitespace, and control characters; cap the length).
Credits
Discovered via an internal security audit of the i18next ecosystem.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | i18next-http-backend | all versions | 3.0.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for i18next-http-backend. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update i18next-http-backend to 3.0.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q89c-q3h5-w34g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-q89c-q3h5-w34g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-q89c-q3h5-w34g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-q89c-q3h5-w34g in your dependencies?
O3 detects GHSA-q89c-q3h5-w34g across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.