CVE-2026-79658 in Ech0
Summary
by MITRE • 08/25/2026
Ech0 before 5.0.1 does not impose any size or shape limit on the Accept-Language header processed by its i18n middleware, which runs on every HTTP request. The header is passed unfiltered to go-i18n's NewLocalizer, which internally calls golang.org/x/text/language.ParseAcceptLanguage. The CVE-2022-32149 mitigation in x/text caps '-' characters but not '_' characters, which the parser aliases to '-', allowing quadratic-time parsing to be triggered with a large header (up to Go's default 1 MiB) built from underscore separators. An unauthenticated attacker can send such requests to consume roughly 1.5 seconds of CPU each, and concurrent requests can saturate a multi-core server (denial of service).
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in Ech0 versions prior to 5.0.1 represents a significant denial-of-service risk stemming from an algorithmic complexity flaw within the internationalization middleware. This component is integral to handling HTTP requests, as it processes the Accept-Language header on every incoming connection to determine content localization preferences. The core technical failure lies in how this header data is passed through the application stack without adequate validation or size constraints. Specifically, the middleware forwards the raw value of the Accept-Language header directly to go-i18n's NewLocalizer function. This internal call subsequently invokes golang.org/x/text/language.ParseAcceptLanguage, which is responsible for parsing language tags according to standard conventions.
The root cause of this vulnerability is a discrepancy in character handling within the underlying Go text library, specifically related to CVE-2022-32149. While that previous mitigation addressed issues with hyphen characters by imposing caps on their usage, it failed to account for underscore characters. In language tag parsing logic, underscores are treated as aliases for hyphens. An attacker can exploit this aliasing behavior by constructing a malicious Accept-Language header composed of numerous segments separated by underscores rather than hyphens. Because the parser treats these underscores identically to hyphens but does not apply the same restrictive length limits or complexity checks that were implemented for hyphenated strings, it triggers a quadratic-time parsing algorithm. This means that as the size of the input string increases, the processing time grows exponentially rather than linearly.
The operational impact of this flaw is severe due to the lack of any imposed size or shape limits on the Accept-Language header by Ech0's middleware. Attackers can craft headers approaching Go's default maximum request body and header limit of one megabyte. When such a large, maliciously formatted header is processed, it consumes approximately 1.5 seconds of CPU time per single request. This high computational cost transforms what might otherwise be a simple localization check into a potent vector for resource exhaustion. Since the middleware runs on every HTTP request, even low-volume traffic can begin to degrade service performance if multiple such requests are sent in succession.
The threat escalates significantly under concurrent attack scenarios. Because each malicious request consumes substantial CPU resources independently, an unauthenticated attacker launching parallel connections from distributed sources can easily saturate a multi-core server. This results in a denial of service where legitimate users experience extreme latency or complete inability to access the application due to resource starvation. The vulnerability is classified as CWE-400: Uncontrolled Resource Consumption and aligns with ATT&CK technique T1496: Resource Hijacking, specifically within the context of computational exhaustion attacks against web applications.
To mitigate this risk, organizations running Ech0 versions before 5.0.1 should immediately upgrade to version 5.0.1 or later where these parsing constraints have been properly addressed. For environments that cannot be patched instantly, implementing a Web Application Firewall rule to restrict the maximum length of the Accept-Language header is recommended. Additionally, configuring reverse proxies like Nginx or Apache to drop requests with excessively long headers can provide an effective layer of defense against this specific algorithmic complexity attack vector until the underlying application software is updated.