i18next Prototype Pollution: The Translation Layer Nobody Thought to Secure.

The Library You Never Audited

i18next is the most widely used internationalisation library in the npm ecosystem. It powers language switching, locale formatting, and translation loading in applications built on React, Next.js, Angular, Vue, Nuxt, and every other JavaScript framework that serves content in more than one language. Most development teams install it in the first week of a project and never think about it again. It sits in the dependency tree, quietly loading translation strings.

On June 25, 2026, two CVSS 9.1 prototype pollution vulnerabilities were disclosed in i18next's server-side packages: i18next-fs-backend (CVE-2026-48713) and i18next-http-middleware (CVE-2026-48714). Both allow an attacker to pollute JavaScript's Object prototype through crafted translation key strings, potentially gaining remote code execution on the server.

How Prototype Pollution Works Here

Prototype pollution is a JavaScript-specific vulnerability where an attacker manipulates the Object prototype — the base object that all JavaScript objects inherit from. If an attacker can set Object.prototype.isAdmin = true, then every object in the application suddenly has an isAdmin property that returns true. Authentication checks, permission gates, and configuration lookups that rely on property presence can all be subverted.

In i18next's case, the attack vector is the missing key handler. When a translation key is requested but not found, i18next logs it, stores it, and optionally writes it to a file (fs-backend) or forwards it via HTTP (http-middleware). The key string itself was not sanitised. An attacker who can control the translation key — through URL parameters, form inputs, or API requests that trigger missing translations — can inject __proto__ property assignments into the handler's storage logic.

The Patch Bypass

This fix-bypass pattern appears repeatedly in the JavaScript ecosystem. A sanitiser checks for the literal string __proto__. An attacker uses constructor.prototype, or encodes __proto__ as a nested path segment, or uses Unicode lookalikes. The whack-a-mole nature of prototype pollution defences is a structural problem in JavaScript's object model, not just an implementation failure in i18next.

The Blast Radius

The affected packages are server-side components. i18next-fs-backend runs on Node.js servers that load translations from the filesystem. i18next-http-middleware runs as Express/Koa/Fastify middleware that processes language detection and translation loading on every request. These are not obscure configurations — they are the standard deployment pattern for server-rendered internationalised applications.

Every Next.js application using next-i18next with server-side rendering, every Nuxt application using nuxt-i18n with SSR, every Express API that serves localised responses — if they use i18next-fs-backend <= 2.6.5 or i18next-http-middleware <= 3.9.6, they are exposed. The fix is straightforward: update to i18next-fs-backend 2.6.6 and i18next-http-middleware 3.9.7. But the update must reach every server deployment, not just the npm lockfile.

The Supply Chain Lesson

i18next is not a security library. It is not an authentication module. It is not a database driver. It is a translation string loader. It sits in the category of 'utility dependencies' that development teams install and forget. Security audits focus on authentication middleware, database queries, and API input validation. Nobody audits the internationalisation layer.