ALAS2-2026-4042

References: CVE-2026-111943  CVE-2026-78659  CVE-2026-78667  CVE-2026-94440 
FAQs regarding Amazon Linux ALAS/CVE Severity

Issue Overview:

Due to security concerns regarding a small set of intermediate certificates issued by a specific Certificate Authority (CA), the Go's crypto/x509 package is updated to not trust certificates issued by the affected intermediate certificates. This would prevent possible future misuse of certificate issued by the affected intermediate certificates. (CVE-2026-111943)

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) (CVE-2026-78659)

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-78667)

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-94440)

Issue Correction:
Run yum update cri-tools or yum update --advisory ALAS2-2026-4042 to update your system.

New Packages:

aarch64:
    cri-tools-1.32.0-1.amzn2.0.8.aarch64
    cri-tools-debuginfo-1.32.0-1.amzn2.0.8.aarch64

src:
    cri-tools-1.32.0-1.amzn2.0.8.src

x86_64:
    cri-tools-1.32.0-1.amzn2.0.8.x86_64
    cri-tools-debuginfo-1.32.0-1.amzn2.0.8.x86_64