CVE-2026-61629: nginx ignition has ParseAcceptLanguage `_` separator bypass that enables ~75x CPU amplification via Accept-Language header in i18nMiddleware
nginx ignition is a user interface for the nginx web server. In versions 2.29.0 through 2.40.0, the gin i18n middleware in nginx-ignition's API server runs in front of every HTTP request and calls golang.org/x/text/language.ParseAcceptLanguage on the raw Accept-Language header without imposing any size or shape filter. The underlying parser has quadratic-time behaviour on long lists of malformed language tags. The CVE-2022-32149 guard that golang.org/x/text added in v0.3.8 caps the number of - characters in the input at 1000, but it does not cap characters even though the parser's internal scanner aliases to - before parsing. A single unauthenticated GET request with an Accept-Language header built out of separators burns about 2.4 seconds of server CPU on the host running nginx-ignition; ten concurrent attackers saturate a ten-core box for the duration of the attack while consuming ~10 MiB/s of upstream bandwidth. Version 2.40.1 fixes this issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
nginx-ignitionto a version that resolves this vulnerability.Fixed in 2.40.1
Event History
Frequently Asked Questions
Who can exploit this issue?
Any unauthenticated remote client that can send HTTP requests to the nginx-ignition API server can trigger it. Exploitation requires only a crafted Accept-Language header and no user interaction or valid account.
Are default deployments exposed?
The affected i18n middleware runs before every HTTP request and parses the raw Accept-Language header without a size or shape filter. Therefore, deployments of affected versions with the API server reachable by untrusted clients are exposed unless another layer rejects or constrains these headers.
What is the practical impact of an attack?
A single crafted GET request can consume about 2.4 seconds of CPU on the host running nginx-ignition. Ten concurrent attackers can saturate a ten-core system during the attack while using roughly 10 MiB/s of upstream bandwidth.
What should be done if an immediate upgrade is not possible?
Restrict untrusted access to the nginx-ignition API server and use an upstream HTTP layer to reject or constrain malformed or excessively long Accept-Language headers, particularly headers containing large numbers of underscore separators. Upgrade to version 2.40.1 when possible.