Threat Intelligence Database

CVE-2026-56853 is a high-severity vulnerability in the Go standard library net/http package. It occurs when a server supports unencrypted HTTP/2 and reads initial bytes from new connections to detect the HTTP/2 client preface. During this process, the ReadHeaderTimeout setting is not applied as expected, leading to allocation of resources without proper limits or throttling. This can cause denial of service by exhausting server resources.

The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error. This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".

When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.

CVE-2025-58186 is a medium severity vulnerability in the Go standard library net/http package. It involves uncontrolled resource consumption due to the lack of a limit on the number of cookies parsed, despite an overall HTTP header size limit of 1MB. An attacker can exploit this by sending many small cookies, causing the server to allocate excessive memory and degrade availability.

Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.

MediumVulnerabilityGermanyFranceNetherlands+7#cve#cve-2025-4673#cwe-201

An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.

HighVulnerabilityGermanyFranceUnited Kingdom+7#cve#cve-2023-45288#cwe-400