How can an HTTP/2 server built using the Go standard library mitigate CVE-2026-49975

Getting Help
1

I have an HTTP server built using the Go language, which supports the HTTP/2 protocol and primarily utilizes the “net/http” standard library.

After my testing, CVE-2026-49975 (an HTTP/2 memory amplification DoS vulnerability) is effective against my server.

For security reasons, I have attempted to disable HTTP/2 on my server.

By the way, I have tried upgrading Go to the latest version (Go 1.26.5), but the issue still persists.

Key server startup code when http/2 has not been disabled:

func httpServeTls(addr string, tlsConfig *tls.Config, handler http.Handler) error {
    s := &http.Server{Addr: addr, Handler: handler, TLSConfig: tlsConfig}

    ln, err := net.Listen("tcp", addr)
    if err != nil {
        return err
    }
    defer ln.Close()

    return s.ServeTLS(ln, "", "")
}

The Proof of Concept (POC) that crashed my server is sourced from https://github.com/mrx-arafat/CVE-2026-49975-POC.git. The README.md file in this repository clearly outlines the basic details of this vulnerability, so I will not elaborate further.

I cloned the POC code repository, and then I crashed my server using the following command:

python3 exploit-test.py myserver.example.com 443 --mode nginx --threads 70 --streams 50 --headers 16374

After running the POC, the server program did not respond (in fact, it froze), and subsequently, the system triggered an OOM error and killed the server process.

In summary, I have two questions:

1. Using Go’s HTTP standard library, is there a way to mitigate this vulnerability on the existing basis so that I can re-enable HTTP/2 support?

2.When will the Go standard library release a patch for this vulnerability? (Under normal circumstances?)

2

Go is usually very fast in patching critical vulnerabilities.

But if I understand this POC correctly, the CVE mainly helps the attacker to save resources by sending lots of header-references, which results in the server allocating 1MB for a single connection. But in essence this introduces no new attack vector - if your server can run into OOM by accepting too many connections, all this CVE does is reducing the amount of resources an attacker needs on his end to create so many “heavy” connections. - So even if this vulnerability is fixed, an attacker could still crash your server if it is not correctly configured with limits on memory/amount of concurrent connections - it doesn’t even have to be an attacker, a million users accessing your server in the same minute would lead to the same problem.

So the correct way to mitigate OOM attacks like this is to limit the amount of concurrent connections and individual connection lifetime and total memory each connection can occupy. - Go gives you a lot of tools and attributes you can use to limit these parameters and prevent OOM or server freeze - a correctly configured server will start to drop or not accept new connections, if the number of open connections or allocated memory reaches a certain threshold.