CVE-2026-78661: 
Gitea vulnerability analysis and mitigation

CVE-2026-78661 is a Denial of Service vulnerability in the golang.org/x/net/html HTML parser caused by inefficient algorithmic complexity (CWE-407) during text node coalescing. When adjacent text nodes are merged in the addText and fosterParent functions, string concatenation (n.Data += text) triggers a full reallocation and copy of the accumulated string on every token, resulting in O(n²) memory allocations and byte copies for inputs with many short text runs separated by ignored end tags (e.g., a</x>). All versions of golang.org/x/net/html before 0.62.0 are affected. The vulnerability was published on October 27, 2026, with a patch released the same day. The CVSS base score is estimated as Medium; the EUVD-assigned base score is 0.0 (pending full NVD analysis) (GitHub Advisory, OSV).

The root cause is inefficient string concatenation in the Go HTML parser's addText and fosterParent functions, classified as CWE-407 (Inefficient Algorithmic Complexity). Each time a text token is appended to an existing TextNode, the expression n.Data += text causes Go's runtime to allocate a new string and copy all previously accumulated bytes, yielding O(n²) total work for n tokens. The fix accumulates coalesced text in per-node byte slices during parsing and materializes the final Data string only once at the end of the parse, reducing complexity to O(n). The issue is tracked upstream at go.dev/issue/82224 and the code change is at go.dev/cl/849365. No preconditions beyond the ability to supply HTML input to a service using the affected parser are required (GitHub Advisory, OSV).

Successful exploitation causes excessive memory allocations and CPU consumption in any service that parses attacker-controlled HTML using golang.org/x/net/html versions before 0.62.0, potentially degrading or crashing the HTML parsing service. The impact is limited to availability (Denial of Service); there is no evidence of confidentiality or integrity compromise. Services that accept arbitrary HTML input from unauthenticated users are at highest risk (GitHub Advisory, OSV).

There is no known public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date. The vulnerability is unauthenticated and requires only the ability to send crafted HTML input to an affected service. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. No threat actor attribution has been reported (GitHub Advisory, OSV).

1. Identify target: Locate a service that accepts HTML input and processes it using golang.org/x/net/html at a version below 0.62.0 (e.g., a web scraper, HTML sanitizer, or content rendering service built in Go).
2. Craft malicious payload: Construct an HTML document containing a large number of short text runs separated by ignored end tags, such as a repeated pattern of a</x>b</x>c</x>... with thousands of iterations.
3. Submit payload: Send the crafted HTML to the target service's input endpoint (e.g., via HTTP POST to an HTML processing API or form submission).
4. Trigger O(n²) behavior: The parser's addText/fosterParent functions repeatedly reallocate and copy the accumulated string for each token, causing exponential growth in memory usage and CPU time.
5. Achieve DoS: The service exhausts available memory or CPU, resulting in degraded performance or a crash (GitHub Advisory, OSV).

• Network: Unusually large or repetitive HTML payloads submitted to HTML-processing endpoints; high-frequency requests with structurally similar malformed HTML content.
• Process: Go service processes exhibiting sudden spikes in CPU and memory consumption correlated with HTML parsing operations; out-of-memory (OOM) kills of Go-based services.
• Logs: Application logs showing parsing timeouts or panics in golang.org/x/net/html; repeated errors or slow response times on endpoints that accept HTML input.

Upgrade golang.org/x/net/html to version 0.62.0 or later, which accumulates coalesced text in per-node byte slices and materializes strings only once at parse completion, eliminating the O(n²) behavior. As interim mitigations, implement input size limits and request timeouts on HTML parsing operations, and apply rate limiting to endpoints that accept HTML input. Rebuilding and redeploying any Go application that vendors or depends on golang.org/x/net is required to pick up the fix (GitHub Advisory, Go CL 849365).

The vulnerability was announced via the golang-announce mailing list and noted on infosec.exchange and oss-sec. Community reaction has been low-key, consistent with a moderate-severity DoS in a widely used Go library with a straightforward patch and no active exploitation. No major vendor statements or notable researcher commentary beyond the standard Go security disclosure process have been observed (golang-announce, oss-sec).