I18Next Http Middleware
Approved changes feed: RSS · Atom
cpe:2.3:a:i18next:i18next-http-middleware:*:*:*:*:*:*:*:*
part: a version: * update: *
| Vendor | I18Next (a5183295-a199-5245-92a0-67861c9ae2d3) |
|---|---|
| Product | I18Next Http Middleware (82d3ed68-671c-5e11-ac0c-3af04dc0cb7a) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | * |
| Target hardware | * |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
pkg:github/i18next/i18next-http-middleware |
purl2cpe | 2026-06-19 13:12:45.584998 |
pkg:npm/i18next-http-middleware |
purl2cpe | 2026-06-19 13:12:45.585001 |
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-48714 |
vulnerable | 2026-07-29 00:55:01.585730 |
i18next-http-middleware missingKeyHandler does not reject keys whose segments contain prototype-polluting names
CRITICAL (9.1)
i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. In versions prior to 3.9.7, the 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 for remote prototype pollution. Other downstream backends that split the missing-key string the same way may be similarly affected. Depending on the host application, polluted prototype properties may cause crashes, corrupted translation behaviour, configuration poisoning, or bypasses of property-based security checks. This issue has been fixed in version 3.9.7. If developers cannot upgrade immediately, they should do the following: do not expose missingKeyHandler to untrusted users (mount it behind authentication, or remove the route), add a request-body filter ahead of the handler that rejects any top-level key containing __proto__, constructor, or prototype after splitting on their configured keySeparator, and disable missing-key persistence (saveMissing: false) when accepting writes from untrusted input.
Published: 2026-06-15T20:41:49.382Z
Updated: 2026-06-16T14:50:29.087Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-42353 |
vulnerable | 2026-06-08 08:03:16.204188 |
Path traversal / SSRF in i18next-http-middleware via user-controlled language and namespace parameters
HIGH (8.2)
i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Prior to version 3.9.3, i18next-http-middleware passes the user-controlled lng and ns values from getResourcesHandler directly into i18next.services.backendConnector.load(languages, namespaces, …) without any sanitization. Depending on which backend is configured, the unvalidated path segments enable either path traversal or SSRF. This issue has been patched in version 3.9.3.
Published: 2026-05-08T15:29:55.900Z
Updated: 2026-05-08T23:30:15.045Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-41690 |
vulnerable | 2026-06-08 08:03:15.698332 |
Prototype pollution and path traversal in i18next-http-middleware via user-controlled language and namespace parameters
HIGH (8.6)
18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Versions prior to 3.9.3 allow an unauthenticated HTTP client to pollute Object.prototype in the Node.js process hosting the middleware, via two unvalidated entry points that reach internal object-key writes: getResourcesHandler and missingKeyHandler. This can break authorisation checks (if (user.isAdmin) returning true for any user), cause type-confusion DoS, and depending on downstream code it can be chained into RCE.
Published: 2026-05-08T15:24:12.014Z
Updated: 2026-05-08T16:43:48.281Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-41683 |
vulnerable | 2026-06-08 08:03:15.691271 |
HTTP response splitting and DoS in i18next-http-middleware via unsanitised Content-Language header
HIGH (8.6)
i18next-http-middleware is a middleware to be used with Node.js web frameworks like express or Fastify and also for Deno. Prior to version 3.9.3, i18next-http-middleware 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', ...) verbatim. This issue has been patched in version 3.9.3.
Published: 2026-05-08T15:27:05.036Z
Updated: 2026-05-08T23:29:00.230Z |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.