远程主机上安装的 golang 版本低于 1.26.9-1。因此，该软件受到 ALAS2-2026-4005 公告中提及的多个漏洞影响。

    当 http.传输发送包含非空 Request.Body 的 HTTP/1 CONNECT 请求，它会将正文直接写入连接，而不在请求标头之后进行帧处理。如果服务器拒绝具有非 2xx 保持活动响应的 CONNECT 请求，传输将返回到空闲池的连接。由于 CONNECT 请求没有请求正文，服务器可能会将尾部正文字节解释为连接上的后续管道 HTTP/1.1 请求，从而使池连接不同步并导致重用它的下一个调用方读取对注入请求的响应。在反向代理（包括 httputil.ReverseProxy） 通过共享传输转发 CONNECT 请求，这可导致跨用户响应毒化。

    现在，无论响应状态如何，HTTP/1 传输都会在发送 CONNECT 请求后关闭连接。

    此外，ReverseProxy 现在拒绝传入的 CONNECT 请求，并发出 405 Method Not Allowed 响应。
    ReverseProxy 从未以有用的方式处理 CONNECT 请求（它不会将连接转换为双向隧道），因此我们预计此更改不会对任何当前用户产生负面影响。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81740NOTE: 已修复：
    https://github.com/golang/go/commit/76875df0f3425f69e4dc2c439040a248b6107854 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/3fe1aac0ce941cb16b0ec5d489827cf1c58197c4 （go1.26.9） （CVE-2026-56866）

    当客户端发送 Trailer 标头时，HTTP 服务器在内部使用这些标头值填充传递给服务器处理程序的 Request.Trailer 映射。由于 Request.Trailer 是一个映射，因此每个条目都会产生内存开销。对于 HTTP/2 服务器，恶意客户端可利用此漏洞，通过发送声明大量字段的尾部标头，导致服务器分配不成比例的内存量，同时绕过 Server.MaxHeaderValueCount 和 Server.MaxHeaderBytes 限制。此漏洞不适用于 HTTP/1 服务器，因为 HTTP/1 服务器不支持通过一个 TCP 连接对大量请求进行多路复用，并且其 Server.MaxHeaderBytes 的计算方式不同。Server.MaxHeaderValueCount 和 Server.MaxHeaderBytes 限制现在应用于尾部标头中声明的尾部字段。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81857NOTE: 已修复：
    https://github.com/golang/go/commit/cbb0fb8b51cba866018b8a0fb4b5458f16c5c80b （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 （go1.26.9） （CVE-2026-78659）

    历来，我们对 HTTP/2 实现中的畸形帧相关标头比较宽松，因为它们不会干扰 HTTP/2 帧。但是，这使得我们的 HTTP/2 实现在充当反向代理时，可以将包含此类标头的响应转发到 HTTP/1 客户端。如果 HTTP/1 客户端的行为也不够严格，这可导致响应走私。

    我们现在会在 HTTP/2 传输接收到与成帧相关的标头时删除畸形，以便它们不会被转发到可能易受攻击的 HTTP/1 客户端。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81115NOTE: 已修复：
    https://github.com/golang/go/commit/072779d81582543bf2872c259e0c6cceea728de4 （go1.27.2）TODO：检查 golang-golang-x-net （CVE-2026-78660） 可能需要跟踪

    HTTP/2 服务器可针对相同的数据退还两次连接级别的流控制：这两次是在客户端重置流（为流的任何已发送但未读部分退还数据）时，另一次是在请求处理程序读取缓冲的数据时。恶意客户端可利用此漏洞，绕过配置的连接级流控制限制 （MaxReceiveBufferPerConnection）。缓冲数据总量仍受到并发流限制和流级流控制的限制。HTTP/2 服务器现在会等到请求处理程序完成后，才退还重置流的连接层级流控制。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81743NOTE: 已修复：
    https://github.com/golang/go/commit/31dc9e2449e394439498142451627af52626d7c4 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 （go1.26.9） （CVE-2026-78663）

    解析包含大量小范围的 Range 标头时，FileServer（FS）、ServeContent 和 ServeFile（FS） 可消耗过量 CPU。

    这些函数现在忽略包含超过 200 个范围的 Range 标头。该限制由新的 httpservecontentmaxranges=GODEBUG 设置控制。设置 GODEBUG=httpservecontentmaxranges=0 会禁用该限制。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81858NOTE: 已修复：
    https://github.com/golang/go/commit/ababc3cd873d8acce1777268aa7a817e6b672028 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/eb25b4e532c5a01f99ef860ec66743a8783f992b （go1.26.9） （CVE-2026-78667）

    恶意的 HTTP/2 对等机可通过打开大量流然后发送许多包含SETTINGS_INITIAL_WINDOW_SIZE值的小型 SETTINGS 帧来导致客户端或服务器中过量消耗 CPU。HTTP/2 客户端和服务器现在可有效处理初始窗口大小（O（1）而非 O（流数））的变更。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81742NOTE: 已修复：
    https://github.com/golang/go/commit/1d58cdaa1069e259b60c324ec77472f09f23d92e （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 （go1.26.9） （CVE-2026-78669）

    当 HTTP 服务器处理程序向 HTTP/1 CONNECT 请求发送 2xx 响应并在未劫持连接的情况下返回时，服务器会错误地继续读取和服务连接中的请求。
    由于对 HTTP/1 CONNECT 的 2xx 响应会将连接转换为隧道，因此服务器不应将该连接视为继续包含 HTTP。这种不当行为的影响主要限于潜在的请求走私，其中中间代理将连接上的数据视为隧道，而服务器则将其视为 HTTP。HTTP/1 服务器现在在响应 CONNECT 请求后始终会关闭连接，无论响应状态如何。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81744NOTE: 已修复：
    https://github.com/golang/go/commit/e92229e24a387cc006a750af176b07a459ba71a1 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/087de1ff08ea620ac2f6ae26c939454cb793883a （go1.26.9） （CVE-2026-94439）

    当部分开头的剩余限制小于 400 字节时，解析多部分表单可绕过内存限制，并将任意长行读入内存。现在可在此情况下正确强制执行多部分表单内存限制。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81741NOTE: 已修复：
    https://github.com/golang/go/commit/7c79b50a74b6d1aa4269b1827dda7d81f3717f9d （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/d7a7aa8e6781ddf8dce12adf60a813d957d4763e （go1.26.9） （CVE-2026-94440）

    cmd/go：golang.org/fips140 的校验和绕过

    此前，在定义虚假 golang.org/fips140 并操作用户选择连接的恶意 GOMODPROXY 的恶意 Go 项目中操作的用户，可以在其位置提供任意模块。

    现在，我们解包捆绑的 golang.org/fips140 模块的受信任 ziphash，并在 GOMODCACHE 中构造其条目，以便工具链可以对其进行验证。（CVE-2026-94444）

    此前，在定义虚假 golang.org/toolchain go.sum 条目并操作用户选择使用的恶意 GOMODPROXY 的恶意 Go 项目中操作的用户，可绕过预期校验和。

    我们现在确保 golang.org/toolchain 始终进入网络进行规范校验和。



    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81834NOTE: 已修复：
    https://github.com/golang/go/commit/68fa7699a27d745f90bf8630202e1a415d1b0769 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/7325b729f07c7ff255b9b5e3f427234ebd21ac47 （go1.26.9） （CVE-2026-94447）

    当 JavaScript 模板文本包含连续表达式时，输入新表达式时未正确重置上下文跟踪状态。我们现在确保模板文字表达式条目正确重置上下文变量，因此可以准确识别和转义所有后续的正则表达式文字。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81821NOTE: 已修复：
    https://github.com/golang/go/commit/b26d150e6985f804826f4fcb1aa33aa81e700b52 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/e59c03e695f2eaa26e308f756c83773afb034e47 （go1.26.9） （CVE-2026-94448）

    受信任的模板作者之前可能编写了一个有效的模板，其中使用 |yield|关键字可能不会被正确转义。我们现在确保转义有效的关键字使用，并且不转义非关键字使用。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81823NOTE: 已修复：
    https://github.com/golang/go/commit/6e2cfab0a1c1683c52f9e09270627b0c4e6446e3 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/5d84f6f08caf63b5f1300930368756bd34955f4a （go1.26.9） （CVE-2026-97030）

    RFC 9849 不允许多个 ECH 外部扩展引用;以前，客户端可发送精心构建的数据包，该数据包可通过指定多个引用来触发服务器进程中的内存耗尽。我们现在拒绝这些畸形问题，并因此抑制内存放大矢量。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81855NOTE: 已修复：
    https://github.com/golang/go/commit/f022e61963529d5e691f0e42a87fd5b520f01636 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/eb1bf6e0c4f68b23409483b156e1455696508c6e （go1.26.9） （CVE-2026-97031）

    HTTP/2 服务器最终可能会因为无意中同时修改其 HPACK 编码器而崩溃。这个问题发生的原因在于服务器在未同步的情况下从两个 goroutine 修改 HPACK 编码器：一个使用编码器将标头帧编码为发送到客户端的响应的一部分，另一个在处理包含客户端发送的SETTINGS_HEADER_TABLE_SIZE的 SETTINGS 帧时修改编码器的表大小。恶意客户端可在更改标头表大小时重复发送请求，从而导致服务器崩溃。

    通过不立即应用SETTINGS_HEADER_TABLE_SIZE修复此问题。而是缓冲接收到的任何SETTINGS_HEADER_TABLE_SIZE，并且仅在服务器下次写入帧之前应用新值。

    注意：https://www.openwall.com/lists/oss-security/2026/10/08/9NOTE:
    https://github.com/golang/go/issues/81867NOTE: 已修复：
    https://github.com/golang/go/commit/12acaf3086437e140e2dd3b7d2c30fdd633c5fe0 （go1.27.2）注意：修复者：
    https://github.com/golang/go/commit/6e049521882c944afc1e519a83971ec421dc2974 （go1.26.9） （CVE-2026-97032）

Tenable 已直接从测试产品的安全公告中提取上述描述块。

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

检测

Amazon Linux 2 : golang (ALAS-2026-4005)

critical Nessus 插件 ID 371793

版本 1.1