Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-21T15:17:30.477Z",
  "pubdate": "2026-09-21T15:17:30.477Z",
  "executiveSummary": "Nginx ignition versions 2.29.0 through 2.40.0 are vulnerable to a Denial of Service (DoS) attack via the gin i18n middleware.\nThe vulnerability stems from the improper handling of the 'Accept-Language' HTTP header, which exposes the underlying 'golang.org/x/text/language.ParseAcceptLanguage' function to resource exhaustion.\nBy crafting a malicious 'Accept-Language' header containing an excessive number of underscore (_) characters, an unauthenticated remote attacker can trigger quadratic-time complexity in the language parsing logic.\nThis leads to significant CPU saturation, potentially resulting in complete service unavailability for legitimate users.\nThe risk is critical as it requires no authentication and minimal bandwidth to initiate a highly effective resource depletion attack, effectively pinning down CPU cores on the host system.",
  "technicalDetails": "The root cause of this vulnerability lies in the 'gin i18n' middleware of the nginx-ignition API server, which processes the 'Accept-Language' header without adequate length or structure validation prior to invoking the 'golang.org/x/text/language.ParseAcceptLanguage' function.\nAlthough the 'golang.org/x/text' library introduced a security patch for CVE-2022-32149 in version 0.3.8 to mitigate quadratic-time complexity, this guard specifically targets the '-' character, limiting its frequency to 1000 occurrences.\nThe parser’s internal scanner performs an aliasing operation that treats the underscore character ('_') as equivalent to the hyphen ('-'). Because the vulnerability guard failed to account for this alias, the parser remains susceptible to inputs comprised of a large number of underscores.\nAn attacker can exploit this by sending a specially crafted 'Accept-Language' header where the string is populated with an excessive count of underscore characters. When processed, this input forces the parser into a quadratic-time computational state.\nEach malicious GET request is capable of consuming approximately 2.4 seconds of CPU time on the server host. Under sustained conditions, a relatively small number of concurrent requests (e.g., ten) can cause full saturation of a ten-core processing environment.\nThis attack requires no special privileges or authentication and is fully executable over standard HTTP protocols. The impact is a total denial of service for the target API server, as the application becomes unresponsive due to the CPU starvation caused by the parsing loop.\nThe vulnerable component is the 'gin i18n' middleware integrated within nginx-ignition. All versions from 2.29.0 up to and including 2.40.0 are affected by this flaw, as they rely on the deficient version of the parsing library or lack the necessary middleware input sanitization.\nThe attack flow follows these steps: 1) The attacker identifies the exposed endpoint utilizing the gin i18n middleware. 2) The attacker crafts an HTTP GET request containing a malicious 'Accept-Language' header characterized by a dense sequence of underscore separators. 3) The server receives the request and, before any business logic is executed, the middleware passes the raw header to the library. 4) The library's parser enters an inefficient state, consuming excessive CPU cycles to process the malicious string. 5) Multiple concurrent requests force the server into resource exhaustion, preventing the handling of legitimate traffic."
}