ALAS2023-2026-3378

References: CVE-2026-111943  CVE-2026-16317  CVE-2026-93599  CVE-2026-93600  CVE-2026-93601 
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.

Amazon Linux golang-based packages are being rebuilt with the fixed crypto/x509 package described in CVE-2026-111943 as a defense-in-depth measure against the eMudhra intermediate CA certificates with weak private keys.

By default, Go programs on Amazon Linux use the system-wide certificate authority (CA) store. Therefore, the primary fix for this issue is the ca-certificates update that removes the root CA certificates that signed the affected intermediates. Customers should ensure that update is installed: https://explore.alas.aws.amazon.com/CVE-2026-113470.html (CVE-2026-111943)

Missing validation of the outer content_type byte on TLS 1.3 encrypted records in s2n-tls allows an active man-in-the-middle to silently discard individual application data records without either endpoint detecting the modification. RFC 8446 Section 5.2 requires that the outer content_type of all encrypted TLS 1.3 records must be application_data (0x17). The s2n-tls AEAD implementation hardcodes this value in the additional authenticated data rather than using the actual wire byte, so the outer content_type is not covered by the authentication tag.

This enables selective suppression of application data. In HTTP pipelining scenarios, dropping a TLS record containing an HTTP request can cause request/response desynchronization, where subsequent responses are delivered to the wrong requests. In write-heavy workloads, a dropped record containing a write request can result in undetectable data loss when the client interprets a subsequent success response as confirmation of the dropped write.

All TLS 1.3 connections are affected. Both TLS clients and servers are affected. TLS 1.2 and QUIC connections are not affected.

We recommend you upgrade s2n-tls to version v1.7.6 (CVE-2026-16317)

rustls-webpki through 0.103.12 (and 0.104.0-alpha releases before 0.104.0-alpha.7) contains a reachable panic in bit_string_flags() in src/der.rs. The input guard fails to reject a named-bit BIT STRING whose content is exactly [0x00] (zero padding bits and no data bytes), so raw_bits.len() - 1 underflows on the empty slice and the subsequent index operation panics (subtract-with-overflow in debug, index-out-of-bounds in release). The condition is reachable through the public API BorrowedCertRevocationList::from_der() when a CRL contains an issuingDistributionPoint extension with such an onlySomeReasons value. Exploitation requires an application that explicitly opts in to CRL revocation checking by passing RevocationOptions to verify_for_usage() and that parses CRL bytes obtained from a source the attacker can influence; the default rustls configuration, which does not use RevocationOptions, is unaffected. A crafted CRL causes a denial of service via the panic. Fixed in 0.103.13 and 0.104.0-alpha.7. (CVE-2026-93599)

rustls-webpki (rustls/webpki) versions 0.101.0 through 0.103.11 and 0.104.0-alpha releases before 0.104.0-alpha.6 ignore X.509 name constraints that apply to URI names, causing such constraints to be accepted rather than enforced. Because name constraints are restrictions on otherwise properly issued certificates, the flaw is only reachable after successful signature verification and requires a misissued certificate to exploit; the library also provides no API for asserting URI names, and URI name constraints are otherwise unimplemented. Versions 0.103.12 and 0.104.0-alpha.6 reject URI name constraints unconditionally. (CVE-2026-93600)

rustls-webpki (the Rust webpki fork used by rustls) versions >= 0.101.0 and prior to 0.103.12 and 0.104.0-alpha.6 incorrectly accepted permitted-subtree DNS name constraints for certificates asserting a wildcard name. For example, a name constraint of accept.example.com was treated as satisfied by a certificate for *.example.com, which could feasibly assert reject.example.com -- a name outside the permitted subtree. Because name constraints are restrictions applied to otherwise properly issued certificates, the issue is only reachable after signature verification succeeds and requires a misissued wildcard certificate to exploit. (CVE-2026-93601)

Issue Correction:
Run dnf update amazon-efs-utils --releasever 2023.12.20261109 or dnf update --advisory ALAS2023-2026-3378 --releasever 2023.12.20261109 to update your system.
More information on how to update your system can be found on this page: Amazon Linux 2023 documentation

New Packages:

aarch64:
    amazon-efs-utils-3.3.5-1.amzn2023.aarch64

src:
    amazon-efs-utils-3.3.5-1.amzn2023.src

x86_64:
    amazon-efs-utils-3.3.5-1.amzn2023.x86_64