GHSA-MQXV-9RM6-W8QC: CPU Exhaustion in Ech0 i18n Middleware via Accept-Language Header Parser Bypass

The publishing platform Ech0 incorporates an internationalization (i18n) middleware component designed to localise application content for incoming HTTP clients. This middleware processes every unauthenticated HTTP request arriving at public endpoints such as the landing page and public API feeds. The middleware automatically extracts the client-supplied Accept-Language HTTP header and forwards its contents to the underlying language parser library.

Because the middleware processes this header prior to authentication and without string length enforcement, it exposes a direct network attack surface. The parsing library x/text/language evaluates the raw input value to match the closest supported language tag. Consequently, any malicious payload injected into this header is parsed using server CPU resources before the request routing is resolved.

This architecture creates a critical path for denial-of-service vectors. An unauthenticated remote attacker can easily exploit this flow by sending requests containing structured, malformed language tags. The lack of proactive input filtering in the middleware allows attackers to force the underlying parsing engine to execute high-complexity computation loops.

The root cause of this vulnerability lies in a bypass of the security mitigation implemented for CVE-2022-32149 within the golang.org/x/text language tag parser. The original mitigation restricted processing of inputs containing more than 1,000 hyphen characters. This check was designed to prevent a quadratic-time complexity loop when scanning malformed tags.

However, the scanner in golang.org/x/text/internal/language/parse.go normalizes underscore characters to hyphens on the fly during parsing. An attacker can construct a payload substituting underscore characters for hyphens. Because the CVE-2022-32149 guard exclusively counts literal hyphen characters, the input bypasses the restriction entirely.

When the parser processes these normalized tokens, it evaluates the length of each token. If a token exceeds the limit of eight bytes, the parser falls back to an internal gobble function. This function uses runtime.memmove to shift the remaining memory buffer contents. When processing N malformed tokens, the continuous buffer shift operations trigger quadratic-time O(N^2) computational complexity.

The vulnerable middleware implementation in internal/i18n/i18n.go accepts the raw header string without validation. The application does not define a custom HTTP header limit, defaulting to the Go standard library limit of 1 MiB. This allows an attacker to transmit 1,048,576 bytes of malicious language tags in a single request.

// Vulnerable Middleware code in internal/i18n/i18n.go
func Middleware() gin.HandlerFunc {
    return func(ctx *gin.Context) {
        explicit := explicitLocaleFromRequest(ctx)
        acceptLanguage := strings.TrimSpace(ctx.GetHeader(\"Accept-Language\"))
        locale := systemDefaultLocale()
        if explicit != "" {
            locale = ResolveLocale(explicit, acceptLanguage)
        }
        setLocaleContext(ctx, locale, acceptLanguage)
        ctx.Next()
    }
}

The flow moves from the middleware directly into the language tag parser. The diagram below illustrates the exact request processing path leading to CPU exhaustion.

The security fix introduced in Ech0 version 5.0.1 resolves this issue by enforcing validation limits on the count of separator characters. Specifically, the patch validates that the combined count of hyphens and underscores does not exceed a secure threshold. This limits the worst-case time complexity of the parser and prevents CPU amplification. This mitigation is complete because it addresses the underlying parsing path before it reaches the vulnerable Go standard library code.

Exploitation is straightforward and requires zero authentication or special server configurations. The attacker identifies public endpoints that invoke the i18n middleware, which typically includes the default root path. A payload is structured by repeating underscore-prefixed tokens of length nine to trigger the gobble code path. A single 1 MiB payload is sufficient to pin a CPU core for several seconds.

# Example of single-line bash exploit payload execution
PAYLOAD=\"en$(python3 -c 'print(\"_abcdefghi\" * 100000, end=\"\")')\"
curl -s -H \"Accept-Language: ${PAYLOAD}\" http://127.0.0.1:18300/

The target application processes the request synchronously inside the current goroutine. This blocks the execution thread until the parsing loop finishes. Because Go multiplexes goroutines over a pool of operating system threads, saturating the threads causes complete application unresponsiveness.

The security impact of this vulnerability is a high-impact denial of service. A single malicious request consuming 1 MiB of bandwidth can lock a single CPU core for up to 7.9 seconds when evaluated twice. Attackers can scale this technique to block all available processing threads on a multi-core server with minimal effort.

To achieve a sustained denial of service, an attacker only needs to transmit roughly 10 MiB of data per second. This low bandwidth requirement makes the vulnerability easy to exploit using basic consumer internet connections. The attack does not require persistent connections or session maintenance, facilitating simple distributed amplification attacks.

This vulnerability does not directly permit data exfiltration or arbitrary code execution. The entire impact is confined to resource exhaustion and application availability. However, the ease of trigger and the lack of prerequisites makes this a highly critical availability threat for deployments of Ech0.

Remediation requires upgrading the Ech0 package to version 5.0.1 or higher. This version implements input sanitization limits on the Accept-Language header. For installations where immediate upgrade is impossible, developers should implement a custom middleware handler that truncates or rejects long headers.

// Mitigation: Add helper to reject high-separator headers
const maxSeparators = 32
func sanitizeHeader(header string) string {
    if strings.Count(header, \"-\") + strings.Count(header, \"_\") > maxSeparators {
        return \"\"
    }
    return header
}

Additionally, operations teams can configure front-end reverse proxies such as Nginx or HAProxy to restrict the maximum size of incoming HTTP headers. Restricting HTTP request headers to 8 KiB or smaller provides an effective external mitigation layer. This prevents malicious payloads from ever reaching the Go application environment.