CVE-2026-42353

What it actually does

i18next-http-middleware before 3.9.3 passes user-controlled language (lng) and namespace (ns) values from its resource handler directly into i18next.services.backendConnector.load() without sanitization. If the application uses a filesystem-backed translation backend, crafted lng or ns values can introduce path traversal sequences that cause the server to read files outside the intended localization directory. If the application uses an HTTP/backend-loader configuration, the same unvalidated values can be used to influence outbound backend fetches, creating server-side request forgery (SSRF) opportunities against internal services, loopback interfaces, cloud metadata endpoints, or other restricted network locations. The flaw is remotely reachable, requires no authentication, and primarily threatens confidentiality, with limited integrity impact depending on caching or backend behavior.

Why it matters to the business

A vulnerable application may expose sensitive local files or allow attackers to make the server connect to internal-only services that are not otherwise reachable from the internet. This can lead to disclosure of secrets, configuration files, credentials, cloud metadata, or internal service responses. Although this issue is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, it is still high severity because exploitation is network-accessible, unauthenticated, and depends mainly on whether the application exposes the affected resource handler and uses a susceptible backend configuration.

How an attack unfolds

An attacker first identifies a Node.js, Express, Fastify, or Deno application using i18next-http-middleware to serve translation resources. They locate the resource-loading endpoint exposed by getResourcesHandler or an application route wired to it. The attacker then sends crafted requests where the lng or ns parameter contains traversal sequences, URL-encoded traversal, absolute paths, full URLs, localhost addresses, private IP ranges, or cloud metadata addresses. In a filesystem backend configuration, the backend connector resolves the attacker-controlled values into file paths and may read files outside the intended locale directory. In an HTTP backend configuration, the backend connector may generate outbound requests to attacker-chosen or internal URLs, enabling SSRF. The attacker reviews the HTTP response for leaked file contents or uses timing, status codes, and error differences to infer access to internal resources. If responses are cached or stored by the i18next backend, the attacker may also attempt to poison translation resources or persist unexpected content until caches are cleared.

How to fix it

Upgrade i18next-http-middleware to version 3.9.3 or later, which patches the unsafe handling of lng and ns values. If direct upgrade is delayed, restrict the resource handler to a strict allowlist of expected languages and namespaces, reject path separators, dot-dot sequences, URL schemes, encoded traversal, absolute paths, and control characters in lng and ns, and normalize then re-validate values before use. For filesystem backends, constrain translation file resolution to a fixed base directory and ensure resolved paths remain within that directory. For HTTP backends, use fixed backend hosts rather than user-influenced URLs, block redirects to private ranges, and enforce outbound egress controls preventing access to loopback, link-local, RFC1918, and cloud metadata addresses. Clear translation caches after patching if suspicious requests were observed.

How to confirm the fix worked

Confirm dependency versions in package manifests and lockfiles using npm, yarn, pnpm, or SCA tooling, and verify that i18next-http-middleware resolves to 3.9.3 or later in deployed artifacts. Exercise the translation resource endpoint with benign traversal and SSRF probes in a test environment and confirm the application rejects them with safe 4xx responses and does not issue outbound requests or read files outside the locale directory. Review runtime dependency trees to catch transitive inclusion of vulnerable versions. For containerized deployments, rebuild images after upgrading and verify the installed package version inside the final runtime image. Validate that WAF, route-level validation, and egress controls block encoded and double-encoded traversal as well as requests targeting localhost, private IP ranges, link-local addresses, and metadata services.

Typical attack path

1. Identify an application endpoint that serves i18next translation resources through i18next-http-middleware.
2. Send baseline requests with legitimate lng and ns values to understand the route format and response behavior.
3. Inject path traversal payloads such as ../ or URL-encoded variants into lng and ns.
4. If a filesystem backend is used, attempt to read files outside the localization directory by targeting common sensitive paths.
5. If an HTTP backend is used, inject absolute URLs, localhost, private IP addresses, or cloud metadata addresses into lng or ns to trigger SSRF.
6. Observe response bodies, status codes, timing, and application errors to confirm file disclosure or internal network access.
7. Attempt to retrieve higher-value files, secrets, service metadata, or internal API responses.
8. Check whether malicious or unexpected translation resources are cached and continue to affect later users.

How to detect it

Review HTTP access logs, application logs, reverse-proxy logs, WAF events, and APM traces for requests to translation-resource endpoints containing suspicious lng or ns values. Look for dot-dot traversal, encoded slashes, encoded dots, absolute file paths, URL schemes, localhost references, private IP addresses, link-local addresses, and cloud metadata endpoints. Correlate suspicious inbound requests with outbound HTTP/DNS/proxy/firewall logs from the application process to detect SSRF attempts, especially connections to 127.0.0.1, ::1, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254, or internal hostnames. For filesystem-backed deployments, inspect application error logs for file-not-found or permission errors involving paths outside the locale directory, and review file access telemetry where available. For HTTP-backed deployments, inspect backend connector logs and egress proxy logs for unexpected destinations or redirects. If a CDN or application cache fronts the resource endpoint, review cached objects for keys containing traversal or full URLs and purge suspicious entries.

• lng=../
• ns=../
• lng=..%2f
• ns=..%2f
• lng=%2e%2e%2f
• ns=%2e%2e%2f
• lng=..%252f
• ns=..%252f
• lng=/etc/passwd
• ns=/etc/passwd
• lng=etc/passwd
• ns=etc/passwd
• lng=file://
• ns=file://
• lng=http://
• ns=http://
• lng=https://
• ns=https://
• lng=http://127.0.0.1
• ns=http://127.0.0.1
• lng=http://localhost
• ns=http://localhost
• lng=http://169.254.169.254
• ns=http://169.254.169.254
• lng=http://metadata.google.internal
• ns=http://metadata.google.internal
• lng=http://10.
• ns=http://10.
• lng=http://192.168.
• ns=http://192.168.
• lng=http://172.16.
• ns=http://172.16.
• lng=http://172.17.
• ns=http://172.17.
• lng=http://172.18.
• ns=http://172.18.
• lng=http://172.19.
• ns=http://172.19.
• lng=http://[::1]
• ns=http://[::1]

What your security team should do

• Inventory applications that use i18next-http-middleware, especially internet-facing Node.js, Express, Fastify, and Deno services exposing translation resource endpoints.
• Prioritize upgrading i18next-http-middleware to 3.9.3 or later for all affected services despite the currently low EPSS and absence from KEV, because exploitation is unauthenticated and remotely reachable.
• Add application-layer validation that only permits known language codes and namespace names, independent of the library patch.
• Review backend configuration to determine whether filesystem traversal, SSRF, or both are plausible in each deployment.
• Deploy temporary WAF or reverse-proxy rules blocking traversal sequences, URL schemes, localhost, private IPs, and metadata-service addresses in lng and ns parameters.
• Restrict outbound network access from web application runtimes so they cannot reach internal services or cloud metadata endpoints unless explicitly required.
• Search recent access logs and egress logs for suspicious lng and ns values, including encoded traversal and internal URL targets.
• Clear or invalidate i18next translation caches if malicious resource requests or unexpected translation content are found.