CVE-2026-41691

What it actually does

Versions of i18nextify before 3.0.5 interpolate attacker-controllable language and namespace values, such as `lng` and `ns`, directly into i18next URL templates like `loadPath` and `addPath` without adequate encoding, validation, or path sanitization. Because common language detection mechanisms read these values from query parameters, cookies, localStorage, and request headers, a remote unauthenticated attacker can manipulate the structure of outbound localization resource URLs. Depending on the application’s i18n backend configuration, this can cause path traversal within localization endpoints, unintended requests to alternate paths, malformed URL generation, or broader URL-structure injection. The expected impact is limited confidentiality and integrity risk: exposure of unintended translation resources, pollution or loading of unexpected localization content, or interaction with unintended backend routes. The flaw does not directly provide code execution and is not known to affect availability by itself.

Why it matters to the business

Applications using vulnerable i18nextify versions may allow unauthenticated users to influence where the browser or i18n backend requests localization resources from. In practical terms, this can lead to incorrect site content, exposure of unintended localization files or adjacent resources, cache pollution, or abuse of trusted application traffic to reach unexpected URLs. The CVSS score is medium at 6.5 and EPSS is currently low at 0.00306, with no known CISA KEV listing and no known ransomware association, so this should be treated as a routine but important web application dependency fix rather than an emergency internet-wide exploitation event. The risk is higher for applications that expose language selection through URL parameters, cookies, or headers and use permissive or dynamic translation resource paths.

How an attack unfolds

An attacker first identifies a web application that loads i18nextify before version 3.0.5 and observes how translation resources are fetched, usually by reviewing browser network requests for paths containing language or namespace placeholders. The attacker then supplies a crafted language or namespace value through a supported detection source, most commonly a URL query parameter such as `?lng=`, but potentially also a cookie, localStorage value, or request header. Because the vulnerable library interpolates that value directly into the configured localization URL template, special characters such as path separators, traversal sequences, query delimiters, fragments, percent-encoded characters, or control characters may alter the final request URL. If the application’s translation backend accepts the resulting path, the attacker can cause requests for unintended localization files or adjacent resources, inject additional URL structure into the request, or influence which translation content the application loads. Successful exploitation depends heavily on the application’s i18n routing, backend access controls, and whether translation responses are cached or trusted by the frontend.

How to fix it

Upgrade i18nextify to version 3.0.5 or later, which sanitizes URL interpolation through the `interpolateUrl` fix. If using downstream packages or bundled frontend assets, ensure the deployed browser bundle actually contains the fixed version rather than only updating the package lock file. If immediate upgrade is not possible, validate `lng` and `ns` before they reach i18next/i18nextify: allow only expected language and namespace identifiers, strip or reject `..`, `/`, `\`, `?`, `#`, `%`, whitespace, and control characters, and enforce a short maximum length. Prefer an allowlist such as `en`, `en-US`, `fr`, `de`, or known namespace names instead of attempting broad denylist filtering. Harden translation endpoints so they only serve intended localization files and cannot traverse into adjacent directories or routes. Configure caches and CDNs to avoid storing unexpected localization paths generated from untrusted language values.

How to confirm the fix worked

Confirm dependency inventories, lock files, and deployed frontend bundles show i18nextify version 3.0.5 or later. In a staging environment, attempt benign validation payloads in language and namespace inputs, such as values containing `../`, `%2e%2e%2f`, `/`, `?`, `#`, and long strings, and verify that generated translation requests are rejected, normalized to safe values, or encoded without changing the URL structure. Review browser developer tools or automated integration test logs to ensure translation fetches only target expected localization paths. For applications with server-side logging of translation resources, verify no successful responses are returned for traversal-like or malformed language paths. If a temporary mitigation is used, add unit and integration tests that enforce the language and namespace allowlist before values reach i18next.

Typical attack path

1. Discover that the target application uses i18nextify or i18next-style browser language detection and loads translation resources over HTTP.
2. Inspect browser network traffic to identify translation URL patterns containing language or namespace components.
3. Submit crafted `lng` or `ns` values through query parameters, cookies, localStorage, or language-related request headers.
4. Observe whether the generated translation request URL contains attacker-controlled path traversal, query-string, fragment, or URL-structure changes.
5. Use successful payloads to request unintended localization resources, influence loaded translation content, or interact with adjacent backend routes reachable through the translation URL pattern.
6. Optionally attempt cache poisoning or persistent manipulation if translation responses are cached by shared infrastructure and the cache key includes attacker-controlled localization paths.

How to detect it

Look for evidence that attackers supplied malformed language or namespace values and that the application generated abnormal translation-resource requests. Useful sources include CDN logs, reverse proxy access logs, web server logs, WAF events, application logs for translation endpoints, browser telemetry if collected, and cache logs for localization assets. Search for requests containing `lng=` or `ns=` with traversal sequences, encoded traversal, slashes, backslashes, query delimiters, fragments, percent-encoding, whitespace encoding, or unusually long values. Also review requests to localization paths such as `/locales/`, `/i18n/`, `/translations/`, or configured i18next `loadPath`/`addPath` endpoints for unexpected `../`, `%2e%2e`, nested paths, double slashes, appended query strings, or non-language directory names. Indicators of attempted exploitation include repeated 400/404 responses against localization paths, successful 200 responses for localization requests outside expected language directories, cache entries for abnormal language identifiers, and WAF alerts for path traversal tied to language-selection parameters. Because this issue is client-side URL construction, server logs may show the resulting malformed translation request rather than the original page request that set the malicious value; correlate suspicious translation fetches with preceding requests from the same IP, session, or user agent containing crafted `lng` or `ns` values.

• lng=../
• lng=..%2f
• lng=%2e%2e%2f
• lng=..%5c
• lng=%2e%2e%5c
• lng=/
• lng=%2f
• lng=\\
• lng=%5c
• lng=?
• lng=%3f
• lng=#
• lng=%23
• ns=../
• ns=..%2f
• ns=%2e%2e%2f
• ns=..%5c
• ns=%2e%2e%5c
• ns=/
• ns=%2f
• ns=\\
• ns=%5c
• ns=?
• ns=%3f
• ns=#
• ns=%23
• /locales/../
• /locales/%2e%2e%2f
• /locales/..%2f
• /locales/..%5c
• /i18n/../
• /i18n/%2e%2e%2f
• /translations/../
• /translations/%2e%2e%2f

What your security team should do

• Inventory applications and frontend bundles that use i18nextify or i18next browser language detection with HTTP-backed translation loading.
• Upgrade i18nextify to 3.0.5 or later and redeploy all affected frontend assets.
• Prioritize internet-facing applications where `lng` or `ns` can be supplied through query strings, cookies, localStorage, or request headers.
• Add strict allowlist validation for supported language codes and namespace names at the application boundary.
• Review web server, CDN, WAF, and application logs for traversal-like localization requests since the vulnerable version was deployed.
• Harden translation resource routes so unexpected paths return 400 or 404 and cannot access non-localization resources.
• Add regression tests for language-code and namespace sanitization using traversal, encoded traversal, query injection, fragment injection, whitespace, and overlong values.
• Monitor for repeated probing of `lng` and `ns` parameters even though public exploit maturity is currently reported as none and EPSS is low.