i18next Add-ons i18next-fs-backend and i18next-http-middleware: Two Unauthenticated Flaws, Fixed in 2.6.6 / 3.9.7

Two companion components of "i18next," the JavaScript library used worldwide to switch a web app's interface between languages, have flaws rated 9.1: i18next-fs-backend, which loads translation data from files, and i18next-http-middleware, which detects a visitor's language on the server. They are tracked as CVE-2026-48713 and CVE-2026-48714. With no login, an attacker can rewrite the shared settings inside an app — leading to bypassed login checks, service outages, and, in some cases, a chain to full takeover. If your dependency is i18next-fs-backend 2.6.6 or later and i18next-http-middleware 3.9.7 or later, no action is needed; anything older needs updating.

Both are distributed via npm, and even if you do not use them directly, another library may pull them in internally. The tricky part: both are "second-time" flaws that slip past fixes released earlier. Since they were published in June 2026, no further flaws have been reported in these two components, and the fixed versions above remain the latest releases (as of 2026-07-23).

What are i18next and "prototype pollution"

i18next is a JavaScript library for "internationalization" — switching an app's interface between languages such as English and Japanese. It is a staple in web apps built with React, Vue, and Node.js, and the two components here play supporting roles: loading translation data from files and detecting the language of an incoming visitor.

The vulnerability type is prototype pollution (CWE-1321). In JavaScript, every object (chunk of data) references a shared template (the prototype). If an attacker can write arbitrary values onto that template, the common foundation the whole app references gets rewritten, so the impact does not stay in one place.

The trigger is a place where a string from outside is used as an object key — such as the handling for when a translation key is missing (missingKeyHandler). When an attacker sends a string laced with a special key like __proto__, it becomes a write to that shared template.

Rewrite the foundation, and the door you thought you locked opens

Before the number 9.1, it helps to grasp what "the shared foundation gets rewritten" concretely means. Prototype pollution is frightening not because one record gets stolen, but because it warps the very premises on which the app makes decisions.

The ones who come to exploit this are automated bots throwing requests at every public web app, attackers who want to slip past the login check and impersonate an administrator, those aiming to take a service down for sabotage or extortion, and initial access brokers who build a foothold and resell it. No login or sign-up is needed; it works just by slipping a crafted string into the traffic where the app detects language or processes a translation key. What they rewrite is not one concrete record, but the shared premise the app consults when judging "is this person an admin?" or "is this value safe?" The moment that foundation is tampered with, a user who should be rejected can pass as an administrator, the app itself can be brought down, or — chained with another weakness — it can escalate all the way to takeover.

In security terms, prototype pollution is a "foundation-laying" attack that does more damage combined with other mechanisms than on its own. For example, if a privilege check like if (user.isAdmin) ends up true for everyone due to pollution, you get an authentication bypass. Induce a type confusion to crash the app and you get an outage; if downstream code leaves room to inject code, it has been reported it can develop into arbitrary code execution on the server. Because the entry point is "language handling that anyone can touch," it is easy for attackers to automate.

The number "9.1" only marks technical severity. For the operator of an app that embeds these components, what is really lost is the basic premise that "the login check is working correctly," a service that is supposed to stay up, and the safety of the data entrusted by users. When the foundation can no longer be trusted, every judgment built on top of it wavers.

CVE-2026-48713: pollution in the translation-file loader

CVE-2026-48713 is a flaw in i18next-fs-backend (before 2.6.6), the component that loads translation data from files. When a crafted string from outside reaches the handling for a missing translation key (missingKeyHandler), the shared template can be rewritten. Per NVD, this can lead to configuration poisoning, bypasses of property-based safety checks, and crashes. Update to the fixed version 2.6.6.

CVE-2026-48714: pollution in the language-detection middleware

CVE-2026-48714 is a flaw in i18next-http-middleware (before 3.9.7), the component that detects a visitor's language on the server. The new problem is that using dotted special keys such as __proto__.polluted slips past the defense (a blocklist) introduced in an earlier version. Combined with a component like fs-backend that splits keys by a separator, the pollution succeeds. Update to the fixed version 3.9.7.

"Second-time" flaws that slip past the earlier fixes

Around i18next, this prototype pollution has been a recurring problem. i18next-http-middleware had a similar flaw reported before and addressed in version 3.9.3, and i18next-fs-backend had a related issue fixed in 2.6.4. The new CVE-2026-48713 / 48714 are "second-time" flaws that slip past those fixes with a different way of writing the input. They illustrate how a blocklist approach — rejecting specific strings — is easy to bypass with rephrased input and tends to turn into a cat-and-mouse game.

The problem of a vulnerability lurking in a component (open source) pulled in from outside is not unique to i18next. On this site we have covered malware planted in axios, with 100 million weekly downloads, and a supply-chain attack that chained from TanStack to Nx Console (CVE-2026-45321 and others). Knowing which component and version your app depends on is the prerequisite for moving fast when a fix lands. For npm or Python dependencies, our OSS vulnerability scanner offers a paste-and-check option.

Affected versions, and how to get to a safe one

The fix is simple: update the components you depend on to the fixed version or later. Even if you do not use them directly, other libraries may depend on them internally, so check your whole dependency tree. The fixed 2.6.6 and 3.9.7 are also each package's latest release as of 2026-07-23, so moving to the latest is enough.

It is also worth reviewing whether you use values from outside directly as object keys or load paths — translation keys, language and namespace specifications, and the like. As a baseline, user-supplied values should be filtered for dangerous characters (such as __proto__, separators, and overly long strings) before use.

Exploitation status, and what to keep an eye on

About a month after disclosure, as of 2026-07-23 there are still no reports of CVE-2026-48713 / 48714 being used in real attacks, and they are not listed in the U.S. government's CISA KEV catalog of actively exploited vulnerabilities. You can track the latest status of exploited flaws in one place on our CISA KEV dashboard (Japanese).

That said, prototype pollution is familiar territory for attackers, requires no login, and can be tried from public apps. Because these components are widely embedded across many apps, the blast radius would be large once exploitation begins. With the fixes out and remaining the latest releases, there is no reason to stay on an older version; keeping your dependencies at the fixed version or later is the most reliable defense.

References

• ▸ NVD - CVE-2026-48713 (i18next-fs-backend)
• ▸ NVD - CVE-2026-48714 (i18next-http-middleware)
• ▸ i18next official site
• ▸ MITRE - CWE-1321: Prototype Pollution
• ▸ CISA - Known Exploited Vulnerabilities Catalog