GHSA-69ch-w2m2-3vjp CVE-2022-32149 GO-2022-1059
golang.org/x/text/language Denial of service via crafted Accept-Language header
- Severity
- 7.5 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 1.84%
- Chance of exploitation in the next 30 days. Higher than 79.00% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-772 Missing Release of Resource after Effective Lifetime
- Fix
0.3.8- Upgrade golang.org/x/text to this version or later
Description
The BCP 47 tag parser has quadratic time complexity due to inherent aspects of its design. Since the parser is, by design, exposed to untrusted user input, this can be leveraged to force a program to consume significant time parsing Accept-Language headers. The parser cannot be easily rewritten to fix this behavior for various reasons. Instead the solution implemented in this CL is to limit the total complexity of tags passed into ParseAcceptLanguage by limiting the number of dashes in the string to 1000. This should be more than enough for the majority of real world use cases, where the number of tags being sent is likely to be in the single digits.
Specific Go Packages Affected
golang.org/x/text/language
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| golang.org/x/text | < 0.3.8 |
0.3.8 |
| golang.org/x/text | < 0.3.8 |
0.3.8 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
golang.org/x/text Go → 0.3.8
- go
go get golang.org/x/text@v0.3.8 && go mod tidy
Severity breakdown
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-772: Missing Release of Resource after Effective Lifetime
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
How to prevent it
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- Implementation: It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
- Operation, Architecture and Design: Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GO-2026-6629 Panic parsing crafted input in x/text/secure/precis in golang.org/x/text | High | Also affects golang.org/x/text |
| GO-2026-5970 Infinite loop on invalid input in golang.org/x/text | High | Also affects golang.org/x/text |
| GHSA-ppp9-7jff-5vj2 golang.org/x/text/language Out-of-bounds Read vulnerability | High | Also affects golang.org/x/text |
| GHSA-5rcv-m4m3-hfh7 golang.org/x/text Infinite loop | High | Also affects golang.org/x/text |
| PYSEC-2026-4007 vLLM through 0.29.0 contains a resource exhaustion vulnerability in MooncakeConnector where rejected prefill requests create ownerless transfer placeholders… | Medium | Same weakness, CWE-772 |
| GHSA-pmjh-fq2x-6v4x undici vulnerable to Denial of Service via orphaned RetryHandler response body | Medium | Same weakness, CWE-772 |
| GHSA-3p27-qvp9-27qf Wasmtime has a leak in WASIp1 `fd_renumber` implementation | Medium | Same weakness, CWE-772 |
| GHSA-fw38-pc54-jvx9 Klever-Go KVM: Throttler slot leak in trie account-data sync causes epoch bootstrap / state sync DoS | Medium | Same weakness, CWE-772 |
Credits: Adam Korczynski (ADA Logics), OSS-Fuzz, rbeuque74
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor