# CVE-2026-61629: nginx ignition has ParseAcceptLanguage `_` separator bypass that enables ~75x CPU amplification via Accept-Language header in i18nMiddleware

> Unauthenticated attackers can cause CPU exhaustion and denial of service in nginx-ignition by sending crafted Accept-Language headers.

- **Severity:** High 7.5 (`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`)
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 21 Sep 2026
- **Updated:** 24 Sep 2026
- **Also known as:** GHSA-jr34-h97m-9hpx, GO-2026-6539

## What is CVE-2026-61629?

CVE-2026-61629 is a high-severity denial of service vulnerability in lucasdillmann nginx-ignition, published on 21 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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.

Weakness: CWE-770 (Allocation of Resources Without Limits or Throttling)

## Which versions are affected by CVE-2026-61629?

3 open source packages ship an affected version, including github.com/lucasdillmann/nginx-ignition.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `github.com/lucasdillmann/nginx-ignition` | Go | From 0.0.0-20260126024607-cbaf0fc16ed8 | 0.0.0-20260526022344-0c988fc1277c |
| `github.com/lucasdillmann/nginx-ignition` | Go | From 0.0.0-20260126024607-cbaf0fc16ed8 | 0.0.0-20260526022344-0c988fc1277c |
| `github.com/lucasdillmann/nginx-ignition` | Go | From 0.0.0-20260126024607-cbaf0fc16ed8 | 0.0.0-20260526022344-0c988fc1277c |

## How do I fix CVE-2026-61629?

Upgrade github.com/lucasdillmann/nginx-ignition to 0.0.0-20260526022344-0c988fc1277c or later.

## Is CVE-2026-61629 being exploited?

It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-61629 exists.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2026-61629 and fix it if it is affected.

What it is: CVE-2026-61629 is a high-severity denial of service vulnerability in lucasdillmann nginx-ignition, published on 21 Sep 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: It is not confirmed as exploited in the wild, but public exploit code for CVE-2026-61629 exists.

Affected packages and fixed versions:
- github.com/lucasdillmann/nginx-ignition (Go): affected from 0.0.0-20260126024607-cbaf0fc16ed8; fixed in 0.0.0-20260526022344-0c988fc1277c
- github.com/lucasdillmann/nginx-ignition (Go): affected from 0.0.0-20260126024607-cbaf0fc16ed8; fixed in 0.0.0-20260526022344-0c988fc1277c
- github.com/lucasdillmann/nginx-ignition (Go): affected from 0.0.0-20260126024607-cbaf0fc16ed8; fixed in 0.0.0-20260526022344-0c988fc1277c

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2026-61629/ (Markdown: https://insights.sbomify.com/CVE-2026-61629/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2026-61629
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-61629
- OSV: https://osv.dev/vulnerability/CVE-2026-61629

---
From sbomify Insights: https://insights.sbomify.com/CVE-2026-61629/
Summaries are generated and may contain mistakes; the official description above is the record.