4vulnerabilities
- Critical1 (25.0%)
- High3 (75.0%)
- Medium0 (0.0%)
- Moderate0 (0.0%)
- Low0 (0.0%)
i18next-http-middleware
Ecosystem: npm
Downloads: 1.25 Mln
- 1CriticalAffects 1 version
- 3HighAffects 3 versions
- 0MediumAffects 0 versions
- 0ModerateAffects 0 versions
- 0LowAffects 0 versions
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 1 vulnerabilities
- Critical: 1
- High: 0
- Medium: 0
- Moderate: 0
- Low: 0
- 3 vulnerabilities
- Critical: 0
- High: 3
- Medium: 0
- Moderate: 0
- Low: 0
Vulnerabilities (4)
Known vulnerabilities affecting i18next-http-middleware, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-f49m-vf83-692w | Critical | i18next-http-middleware: MissingKeyHandler does not reject keys whose segments contain prototype-polluting names### Impact `i18next-http-middleware` ≤ 3.9.6's `missingKeyHandler` blocked the literal request-body keys `__proto__`, `constructor`, and `prototype` (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as `"__proto__.polluted"`. Downstream backends that split the missing-key string on a configured `keySeparator` (notably `i18next-fs-backend` ≤ 2.6.5) hand these keys to an unguarded `setPath()` walker that writes to `Object.prototype`. Applications that expose `missingKeyHandler` to untrusted input **AND** use `i18next-fs-backend` ≤ 2.6.5 are directly exploitable |
| GitHub (opens in a new tab) | |
| GHSA-jfgf-83c5-2c4m | High | i18next-http-middleware has path traversal / SSRF via user-controlled language and namespace parameters### Summary Versions of `i18next-http-middleware` prior to 3.9.3 pass the user-controlled `lng` and `ns` values from `getResourcesHandler` directly into `i18next.services.backendConnector.load(languages, namespaces, …)` without any sanitisation. Depending on which backend is configured, the unvalidated path segments enable one of two attacks: - **Filesystem path traversal** when the middleware is paired with `i18next-fs-backend` (or any backend that interpolates `lng` / `ns` into a filesystem path). - **Server-Side Request Forgery (SSRF)** when the middleware is paired with `i18next-http-bac |
| GitHub (opens in a new tab) | |
| GHSA-5fgg-jcpf-8jjw | High | i18next-http-middleware: Prototype pollution and path traversal via user-controlled language and namespace parameters### Summary Versions of `i18next-http-middleware` prior to 3.9.3 pass user-controlled `lng` and `ns` parameters to two internal paths that use them in ways that enable prototype pollution and, depending on the configured backend, path traversal or SSRF. The vulnerable entry points are unauthenticated HTTP handlers that are part of the middleware's public API: - `getResourcesHandler` — reads `lng`/`ns` from query parameters or route params and passes them unvalidated to: - `utils.setPath(resources, [lng, ns], ...)` — the `setPath` helper did not guard against `__proto__`, `constructor`, or |
| GitHub (opens in a new tab) | |
| GHSA-c3h8-g69v-pjrg | High | i18next-http-middleware: HTTP response splitting and DoS via unsanitised Content-Language header### Summary Versions of `i18next-http-middleware` prior to 3.9.3 wrote user-controlled language values into the `Content-Language` response header after passing them through `utils.escape()`, which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older `i18next` (< 19.5.0) that still exercised the backward-compatibility fallback at `LanguageDetector.js:100` or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled `lng` parameter reached `res.setHeader('Content-Language', ...)` verba |
| GitHub (opens in a new tab) |
- GHSA-f49m-vf83-692wCriticali18next-http-middleware: MissingKeyHandler does not reject keys whose segments contain prototype-polluting names
< 3.9.7
### Impact `i18next-http-middleware` ≤ 3.9.6's `missingKeyHandler` blocked the literal request-body keys `__proto__`, `constructor`, and `prototype` (added in 3.9.3, see GHSA-5fgg-jcpf-8jjw), but did not reject dotted variants such as `"__proto__.polluted"`. Downstream backends that split the missing-key string on a configured `keySeparator` (notably `i18next-fs-backend` ≤ 2.6.5) hand these keys to an unguarded `setPath()` walker that writes to `Object.prototype`. Applications that expose `missingKeyHandler` to untrusted input **AND** use `i18next-fs-backend` ≤ 2.6.5 are directly exploitable
CVE: CVE-2026-48714
- GHSA-jfgf-83c5-2c4mHighi18next-http-middleware has path traversal / SSRF via user-controlled language and namespace parameters
< 3.9.3
### Summary Versions of `i18next-http-middleware` prior to 3.9.3 pass the user-controlled `lng` and `ns` values from `getResourcesHandler` directly into `i18next.services.backendConnector.load(languages, namespaces, …)` without any sanitisation. Depending on which backend is configured, the unvalidated path segments enable one of two attacks: - **Filesystem path traversal** when the middleware is paired with `i18next-fs-backend` (or any backend that interpolates `lng` / `ns` into a filesystem path). - **Server-Side Request Forgery (SSRF)** when the middleware is paired with `i18next-http-bac
CVE: CVE-2026-42353
- GHSA-5fgg-jcpf-8jjwHighi18next-http-middleware: Prototype pollution and path traversal via user-controlled language and namespace parameters
< 3.9.3
### Summary Versions of `i18next-http-middleware` prior to 3.9.3 pass user-controlled `lng` and `ns` parameters to two internal paths that use them in ways that enable prototype pollution and, depending on the configured backend, path traversal or SSRF. The vulnerable entry points are unauthenticated HTTP handlers that are part of the middleware's public API: - `getResourcesHandler` — reads `lng`/`ns` from query parameters or route params and passes them unvalidated to: - `utils.setPath(resources, [lng, ns], ...)` — the `setPath` helper did not guard against `__proto__`, `constructor`, or
CVE: CVE-2026-41690
- GHSA-c3h8-g69v-pjrgHighi18next-http-middleware: HTTP response splitting and DoS via unsanitised Content-Language header
< 3.9.3
### Summary Versions of `i18next-http-middleware` prior to 3.9.3 wrote user-controlled language values into the `Content-Language` response header after passing them through `utils.escape()`, which is an HTML-entity encoder that does not strip carriage return, line feed, or other control characters. When the application used an older `i18next` (< 19.5.0) that still exercised the backward-compatibility fallback at `LanguageDetector.js:100` or otherwise produced a raw detected value, CRLF sequences in the attacker-controlled `lng` parameter reached `res.setHeader('Content-Language', ...)` verba
CVE: CVE-2026-41683