GHSA-4c35-wcg5-mm9h — next-intl
MEDIUMGHSA-4c35-wcg5-mm9h is a medium-severity (CVSS 4.2) vulnerability in next-intl. A fix is available for next-intl — see the affected versions and patch details below.
next-intl has prototype pollution with `experimental.messages.precompile` via attacker-controlled translation catalog keys
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
next-intlnpmDescription
Summary
setNestedProperty in packages/next-intl/src/extractor/utils.tsx walks a dotted key path and assigns the final value without blocking the reserved keys __proto__, constructor, or prototype. When the next-intl Next.js plugin is configured with experimental.messages and messages.precompile: true, a JSON translation catalog containing a top‑level __proto__ key causes setNestedProperty(result, '__proto__.isAdmin', compiledMessage) to assign onto Object.prototype, polluting every object in the running build process.
Details
Root cause — packages/next-intl/src/extractor/utils.tsx:13-34:
export function setNestedProperty(
obj: Record<string, any>,
keyPath: string,
value: any
): void {
const keys = keyPath.split('.');
let current = obj;
for (let i = 0; i < keys.length - 1; i++) {
const key = keys[i];
if (
!(key in current) ||
typeof current[key] !== 'object' ||
current[key] === null
) {
current[key] = {};
}
current = current[key];
}
current[keys[keys.length - 1]] = value;
}
The existence check !(key in current) uses the in operator, which walks the prototype chain. For key === '__proto__', '__proto__' in {} is true (it's inherited from Object.prototype) and typeof current['__proto__'] === 'object' (it is Object.prototype). The guard therefore never re-initializes current[key], and current = current['__proto__'] redirects all subsequent writes onto Object.prototype. The final assignment current[keys[keys.length-1]] = value sets Object.prototype[<attacker key>] = <attacker value>.
Build-time data flow:
packages/next-intl/src/plugin/catalog/catalogLoader.tsx:55-83— the webpack/turbopack loader receives the catalog filesourceand, ifoptions.messages.precompileis enabled, callscodec.decode(source, {locale}).packages/next-intl/src/extractor/format/codecs/JSONCodec.tsx:9-18—decoderunsJSON.parse(source). V8 installs__proto__as an own data property on the result when the JSON key is literally"__proto__"(bypassing the normalObject.prototype.__proto__setter that would otherwise reassign the prototype).JSONCodec.tsx:33-53—traverseMessagesiteratesObject.keys(obj), which for a JSON‑parsed object includes the own__proto__key. It readsobj.__proto__(returns the attacker’s nested object, notObject.prototype, because it's an own property), recurses into it, and emits message id__proto__.isAdmin.catalogLoader.tsx:71—precompileMessages(decoded, cache).catalogLoader.tsx:89-131— for each message, callssetNestedProperty(result, message.id, compiledMessage). Withmessage.id === '__proto__.isAdmin',setNestedPropertywalks intoObject.prototypeand assignsObject.prototype.isAdmin = compiledMessage.
The same sink is also reachable via JSONCodec.encode (JSONCodec.tsx:20-26) and POCodec (packages/next-intl/src/extractor/format/codecs/POCodec.tsx:87) during extraction, both of which feed attacker-influenced message.id values into setNestedProperty — but those paths require control of source-code identifiers, which is a weaker attack vector than the build-time catalog path above.
After pollution, every subsequent object access during the remainder of the Next.js build pipeline (webpack, turbopack, babel, next-intl’s own logic) inherits the attacker-controlled properties. This is a classic gadget-chain precondition for corrupting build-tool internals and tampering with generated bundles, since many build tools use patterns like if (obj.someFlag) or options[key] ?? default that are sensitive to polluted prototypes.
Trust boundary note: next-intl’s message catalogs are realistically attacker-influenced in practice. Translation files are routinely round-tripped through external TMS systems (Crowdin, Lokalise, Transifex), accepted via community locale PRs, or pulled from third-party translation packages — any of which can carry a crafted __proto__ key unnoticed, since JSON translation diffs are usually merged with minimal scrutiny.
PoC
Prerequisites: a Next.js project using next-intl ≤ 4.9.1 with the Next.js plugin configured:
// next.config.ts
import createNextIntlPlugin from 'next-intl/plugin';
const withNextIntl = createNextIntlPlugin({
experimental: {
messages: {
path: './messages',
format: 'json',
locales: 'infer',
precompile: true
}
}
});
export default withNextIntl({});
-
Drop a malicious catalog at
messages/en.json:{ "Greeting": "Hello", "__proto__": { "isAdmin": "polluted" } } -
Run
next build(ornext dev). ThecatalogLoaderwill invokeJSONCodec.decode→traverseMessages→precompileMessages→setNestedProperty. -
Minimal reproduction of the sink itself (verified locally against the v4.9.1 source):
function setNestedProperty(obj, keyPath, value) { const keys = keyPath.split('.'); let current = obj; for (let i = 0; i < keys.length - 1; i++) { const key = keys[i]; if (!(key in current) || typeof current[key] !== 'object' || current[key] === null) { current[key] = {}; } current = current[key]; } current[keys[keys.length - 1]] = value; } setNestedProperty({}, '__proto__.isAdmin', 'PWNED'); console.log(({}).isAdmin); // -> "PWNED"Output:
PWNED. -
Full chain reproduction (also verified):
const parsed = JSON.parse('{"Greeting":"Hello","__proto__":{"isAdmin":"polluted"}}'); // traverseMessages emits: [{id:"Greeting",message:"Hello"},{id:"__proto__.isAdmin",message:"polluted"}] // precompileMessages then calls setNestedProperty(result, "__proto__.isAdmin", "polluted") console.log(({}).isAdmin); // -> "polluted"After the loader runs,
({}).isAdmin === 'polluted'for the remainder of the build Node process.
Impact
Object.prototypeis polluted for the lifetime of the build‑time Node.js process, affecting every object created or inspected thereafter in the Next.js build pipeline (webpack/turbopack loaders, babel plugins, next-intl’s own codecs, user plugins).- Classic CWE-1321 gadget-chain precondition: downstream tools that branch on
obj.someFlag,options[key] ?? default,if (!config.noX), etc. can be coerced into unintended behavior, including emitting tampered bundles. - Realistic delivery vectors include TMS round-trips (Crowdin/Lokalise/Transifex), community locale PRs, and compromised/transitively-installed translation packages — all situations where a JSON catalog diff is routinely accepted without the scrutiny given to code changes.
- Exploitation requires the user to opt in to the
experimental.messages+precompileconfiguration. Users who do not use the extractor/precompile features are not affected.
Recommended Fix
Reject reserved keys in setNestedProperty and stop using the in operator for the existence check. A minimal patch to packages/next-intl/src/extractor/utils.tsx:
const FORBIDDEN_KEYS = new Set(['__proto__', 'constructor', 'prototype']);
export function setNestedProperty(
obj: Record<string, any>,
keyPath: string,
value: any
): void {
const keys = keyPath.split('.');
for (const key of keys) {
if (FORBIDDEN_KEYS.has(key)) {
throw new Error(`Invalid message id segment: ${key}`);
}
}
let current = obj;
for (let i = 0; i < keys.length - 1; i++) {
const key = keys[i];
if (
!Object.prototype.hasOwnProperty.call(current, key) ||
typeof current[key] !== 'object' ||
current[key] === null
) {
current[key] = Object.create(null);
}
current = current[key];
}
current[keys[keys.length - 1]] = value;
}
Additionally:
- In
packages/next-intl/src/extractor/format/codecs/JSONCodec.tsx, maketraverseMessagesskip reserved keys (or switch toObject.create(null)+Object.hasOwnsemantics) so that a malicious catalog is rejected early with a clear error rather than producing__proto__.*message ids. - In
packages/next-intl/src/plugin/catalog/catalogLoader.tsx, initializeprecompileMessages’sresultwithObject.create(null)as defense in depth, so even if a key slipped through it could not redirect throughObject.prototype.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | next-intl | all versions | 4.9.2npm install next-intl@4.9.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for next-intl, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update next-intl to 4.9.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-4c35-wcg5-mm9h is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-4c35-wcg5-mm9h can be triaged on real exposure rather than presence alone.
Tailored to GHSA-4c35-wcg5-mm9h. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-4c35-wcg5-mm9h in your dependencies?
O3 Security finds GHSA-4c35-wcg5-mm9h across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.