GHSA-4c35-wcg5-mm9h

What it actually does

The vulnerability is a prototype pollution flaw in next-intl when the experimental `messages.precompile` feature processes translation catalogs containing attacker-controlled keys. Malicious catalog keys such as `__proto__`, `constructor`, or `prototype` can modify JavaScript object prototypes during message precompilation. Depending on how the affected application uses objects after precompilation, this can lead to unexpected application behavior, denial of service, logic manipulation, or secondary security impacts. The issue is lower severity in isolation because exploitation requires an attacker to influence translation catalog content and the practical impact is application-specific.

Why it matters to the business

Organizations using next-intl with experimental message precompilation may be exposed if translation files are imported from users, vendors, localization platforms, CMS workflows, or other semi-trusted sources. A successful exploit could disrupt application behavior, break localized pages, or create hard-to-diagnose integrity issues in application logic. This is not currently listed as known exploited by CISA and no public exploit maturity is indicated, but it has been public for 96 days, so teams should remediate during normal dependency patch cycles, with higher urgency where translation content is externally supplied.

How an attack unfolds

An attacker first needs a path to influence translation catalog keys used by an application that depends on vulnerable next-intl versions and has `experimental.messages.precompile` enabled. This influence may come from a localization management platform, translation import pipeline, CMS integration, pull request to translation files, or another source that accepts catalog content. The attacker submits a catalog containing JavaScript prototype-pollution keys such as `__proto__`, `constructor`, or nested `constructor.prototype` structures. When the application build or precompilation process handles those messages, next-intl processes the malicious keys unsafely and pollutes object prototypes. The resulting impact depends on what code executes afterward: the application may crash, render incorrect localized content, change conditional behavior, or expose secondary bugs in code that trusts inherited object properties.

How to fix it

Upgrade next-intl to version 4.9.2 or later. For npm-based projects, update `package.json` and the lockfile, then rebuild and redeploy affected applications. If immediate upgrade is not possible, disable `experimental.messages.precompile` until patched. Add validation to translation ingestion workflows to reject dangerous object keys, including `__proto__`, `prototype`, and `constructor`, at any nesting level. Treat translation catalogs as untrusted input when they originate from external vendors, CMS systems, localization platforms, or user-editable sources. Review localization import pipelines and CI/CD jobs to ensure untrusted catalog content cannot be introduced without validation and review.

How to confirm the fix worked

Confirm the deployed dependency version is next-intl 4.9.2 or later by inspecting `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, SBOM output, or runtime package inventory. Verify that `experimental.messages.precompile` is disabled if the upgrade has not yet been applied. Test translation catalog validation by attempting to introduce keys such as `__proto__`, `constructor`, and `prototype` in a non-production environment and confirming they are rejected before precompilation. Rebuild the application after upgrading and run localization rendering tests across supported locales. Use dependency scanners or `npm ls next-intl` to confirm no vulnerable copy remains through direct or transitive dependency resolution.

Typical attack path

1. Identify an application using next-intl with `experimental.messages.precompile` enabled.
2. Find a way to submit or modify translation catalog content, such as through a localization platform, CMS workflow, repository contribution, or compromised translation supply chain account.
3. Add malicious translation keys using prototype-pollution primitives such as `__proto__`, `constructor`, or `prototype`.
4. Trigger the application’s message precompilation path, commonly during build, deployment, or catalog import.
5. Cause polluted object prototypes to affect subsequent application behavior, potentially resulting in denial of service, logic manipulation, or other application-specific consequences.

How to detect it

To determine whether this was already exploited, focus on translation supply-chain artifacts rather than network indicators. Review source repositories, localization platform exports, CMS-managed message files, deployment artifacts, and build workspaces for suspicious translation keys containing `__proto__`, `constructor`, `prototype`, or `constructor.prototype`. Examine CI/CD, build, and deployment logs around catalog import or message precompilation for unexpected failures, object-related exceptions, or changes following translation updates. Review pull requests, localization vendor uploads, CMS audit trails, and service-account activity that modified locale/message files. Because prototype pollution often leaves no durable host or network artifact, absence of logs is not proof of non-exploitation; prioritize content review of message catalogs and change history. Also check whether vulnerable versions of next-intl were present at the time suspicious translation files were processed and whether `experimental.messages.precompile` was enabled.

• experimental.messages.precompile
• "__proto__"
• '__proto__'
• __proto__:
• "constructor"
• 'constructor'
• constructor.prototype
• "prototype"
• 'prototype'
• prototype:
• next-intl@4.9.1
• next-intl@4.9.0
• "next-intl": "4.9.1"
• "next-intl": "4.9.0"

What your security team should do

• Upgrade next-intl to 4.9.2 or later across all applications using the package.
• Prioritize applications that enable `experimental.messages.precompile` and consume translation catalogs from external or semi-trusted sources.
• Search repositories, localization exports, CMS content, and translation import artifacts for prototype-pollution keys such as `__proto__`, `constructor`, and `prototype`.
• Add automated validation in CI/CD and localization ingestion pipelines to block dangerous keys in message catalogs.
• If patching is delayed, disable `experimental.messages.precompile` as a temporary mitigation.
• Review recent translation catalog changes and deployment/build logs for suspicious catalog updates since the vulnerable feature was enabled.
• Ensure dependency monitoring covers npm lockfiles and alerts on next-intl versions older than 4.9.2.