Описание
When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.
Пакеты
| Пакет | Статус | Версия исправления | Релиз | Тип |
|---|---|---|---|---|
| golang-1.27 | fixed | 1.27.2-1 | package | |
| golang-1.26 | fixed | 1.26.9-1 | package | |
| golang-1.25 | removed | package | ||
| golang-1.24 | removed | package | ||
| golang-1.24 | no-dsa | trixie | package | |
| golang-1.19 | removed | package | ||
| golang-1.19 | postponed | bookworm | package | |
| golang-golang-x-net | fixed | 1:0.60.0-1 | package | |
| golang-golang-x-net | no-dsa | trixie | package | |
| golang-golang-x-net | postponed | bookworm | package |
Примечания
https://www.openwall.com/lists/oss-security/2026/10/08/9
https://github.com/golang/go/issues/81857
Fixed by: https://github.com/golang/go/commit/cbb0fb8b51cba866018b8a0fb4b5458f16c5c80b (go1.27.2)
Fixed by: https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9)
Fixed by: https://github.com/golang/net/commit/57f4235f83712a299328015548240512213a3852 (v0.60.0)
EPSS
Связанные уязвимости
When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.
When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.
When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.
HTTP/2 server memory exhaustion due to Trailer headers in net/http
EPSS