Summary
Package updates are available for Amazon Linux 2 that fix the following vulnerabilities: CVE-2026-94440: Parsing a multipart form could bypass memory limits and read an arbitrarily long line into memory when the remaining limit at the start of a part was less than 400 bytes. Multipart form memory limits are now properly enforced in this situation. NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9 NOTE: https://github.com/golang/go/issues/81741 NOTE: Fixed by: https://github.com/golang/go/commit/7c79b50a74b6d1aa4269b1827dda7d81f3717f9d (go1.27.2) NOTE: Fixed by: https://github.com/golang/go/commit/d7a7aa8e6781ddf8dce12adf60a813d957d4763e (go1.26.9) CVE-2026-78667: When parsing a Range header containing a large number of small ranges, FileServer(FS), ServeContent, and ServeFile(FS) could consume an excessive amount of CPU. These functions now ignore Range headers containing more than 200 ranges. The limit is controlled by the new httpservecontentmaxranges=GODEBUG setting. Setting GODEBUG=httpservecontentmaxranges=0 disables the limit. NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9 NOTE: https://github.com/golang/go/issues/81858 NOTE: Fixed by: https://github.com/golang/go/commit/ababc3cd873d8acce1777268aa7a817e6b672028 (go1.27.2) NOTE: Fixed by: https://github.com/golang/go/commit/eb25b4e532c5a01f99ef860ec66743a8783f992b (go1.26.9) CVE-2026-78659: 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. Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits are now applied towards the trailer fields declared in "Trailer" headers. NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9 NOTE: https://github.com/golang/go/issues/81857 NOTE: Fixed by: https://github.com/golang/go/commit/cbb0fb8b51cba866018b8a0fb4b5458f16c5c80b (go1.27.2) NOTE: Fixed by: https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9)
Fixed packages 2
| Release | Package | Fixed in |
|---|---|---|
| Amazon Linux · 2 | cni-plugins | 0:1.7.1-1.amzn2.0.8 |
| Amazon Linux · 2 | cni-plugins-debuginfo | 0:1.7.1-1.amzn2.0.8 |
Vulnerabilities 3
-
High 7.5
HTTP/2 server memory exhaustion due to Trailer headers in net/http
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 malicio…
-
High 7.5
Lack of limit on size of parsed Range headers in net/http
When parsing a Range header containing a large number of small ranges, FileServer(FS), ServeContent, and ServeFile(FS) can consume an excessive amount of CPU.
-
High 7.5
Memory limit bypass when parsing MIME headers in net/textproto, mime/multipart
Parsing a multipart form can bypass memory limits and read an arbitrarily long line into memory when the remaining limit at the start of a part is less than 400 bytes.