It is, therefore, affected by multiple vulnerabilities as referenced in the ALAS2023-2026-3254 advisory.

    Previously, after a channel has been established, a malicious peer could send crafted messages that would     deadlock the entire connection. Now, we handle all RFC 4254 channel messages; global requests are handled     explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of     buffering and blocking. (CVE-2026-56855)

    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/9NOTE:
    https://github.com/golang/go/issues/81857NOTE: 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)

    Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious     peer was able flood the channel's incomingRequests, deadlocking the entire connection. Now, we add an     atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every     packet other than the open confirmation/failure, without blocking and without tearing down the connection.
    (CVE-2026-78662)

    The HTTP/2 server could refund connection-level flow control twice for the same data: Once when a client     resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request     handler reads the buffered data.A malicious client could exploit this to bypass the configured connection-     level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the     concurrent stream limit and stream-level flow control.The HTTP/2 server now waits to refund connection-     level flow control for reset streams until after the request handler is complete.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81743NOTE: Fixed by:
    https://github.com/golang/go/commit/31dc9e2449e394439498142451627af52626d7c4 (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 (go1.26.9) (CVE-2026-78663)

    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/9NOTE:
    https://github.com/golang/go/issues/81858NOTE: 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)

    When an HTTP server handler sent a 2xx response to an HTTP/1 CONNECT request and returned without     hijacking the connection, the server improperly continued to read and serve requests from the connection.
    Since a 2xx response to an HTTP/1 CONNECT converts the connection into a tunnel, the server should not     treat the connection as continuing to contain HTTP.The impact of this misbehavior is mostly limited to     potential request smuggling, where an intermediate proxy considers the data on the connection to be     tunneled and the server considers it to be HTTP.The HTTP/1 server now always closes a connection after     responding to a CONNECT request, regardless of the response status.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81744NOTE: Fixed by:
    https://github.com/golang/go/commit/e92229e24a387cc006a750af176b07a459ba71a1 (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/087de1ff08ea620ac2f6ae26c939454cb793883a (go1.26.9) (CVE-2026-94439)

    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/9NOTE:
    https://github.com/golang/go/issues/81741NOTE: 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)

    When a JavaScript template literal contains consecutive expressions, the context tracking state was not     properly reset upon entering a new expression.We now ensure that template-literal expression entries     correctly reset context variables so all subsequent regular expression literals are accurately recognized     and escaped.

    NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81821NOTE: Fixed by:
    https://github.com/golang/go/commit/b26d150e6985f804826f4fcb1aa33aa81e700b52 (go1.27.2)NOTE: Fixed by:
    https://github.com/golang/go/commit/e59c03e695f2eaa26e308f756c83773afb034e47 (go1.26.9) (CVE-2026-94448)

    A trusted template author may have previously written a valid template wherein the use of the |yield|     keyword would not be correctly escaped.We now ensure that valid keyword uses are escaped and non-keyword     uses are not escaped. (CVE-2026-97030)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Detections

Analytics

Amazon Linux 2023 : skopeo, skopeo-tests (ALAS2023-2026-3254)

critical Nessus Plugin ID 371913

Version 1.2