Where
-Infinity
0

-------- Forwarded Message -------- Subject: [security] Vulnerabilities in golang.org/x/net Date: Tue, 27 Oct 2026 19:53:49 +0000 From: announce () golang org To: golang-nuts () googlegroups com

Hello gophers, html: avoid quadratic complexity when coalescing text nodes

When coalescing adjacent text nodes in addText and fosterParent, appending to an existing TextNode's Data via string concatenation (n.Data += text) reallocated and copied the accumulated string on every token. Inputs containing many short text runs separated by ignored end tags (such as "a") caused O(n^2) allocations and byte copies.

Accumulate coalesced text in per-node byte slices during parsing and materialize Data strings once at the end of parse.

Thanks to Markus Magnuson for reporting this issue.

This is CVE-2026-78661 and Go issue <https://go.dev/issue/82224>.

html: check all ancestor namespace transitions when rendering raw text

In childTextNodesAreLiteral, walking up the tree previously stopped at the nearest foreign ancestor once an HTML integration point was found. However, that integration point may itself be a descendant of an element that was foster-parented into a foreign namespace (such as or fostered under ), causing a parser to resolve the subtree in a different foreign namespace upon re-parsing the rendered output.

Continue walking the full ancestor chain and verify that every transition from a non-empty namespace occurs at an HTML integration point before emitting literal text.

Thanks to Ali Sherif (<https://www.linkedin.com/in/ali-sherif-13812b276>) for reporting this issue.

This is CVE-2026-97045 and Go issue <https://go.dev/issue/82622>.

Cheers, Go Security team

--

Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

Check all ancestor namespace transitions when rendering raw text in html in golang.org/x/net

1 / 2
Source: Microsoft
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Avoid quadratic complexity when coalescing text nodes in html in golang.org/x/net

1 / 2
Source: Microsoft
First published (updated )

Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments.This advisory contains the RPM packages for Red Hat OpenShift Container Platform 4.21.39. See the following advisory for the container images for this release:https://access.redhat.com/errata/RHSA-2026:83702 Security Fix(es): urllib3: urllib3: Denial of Service due to excessive HTTP response decompression (CVE-2026-44432) ansible-core: argument injection in ansible-galaxy role install leads to arbitrary code execution (CVE-2026-11332) golang.org/x/crypto/ssh: golang.org/x/crypto/ssh: Denial of Service via crafted AES-GCM packet decoder inputs (CVE-2026-46597) net/http/internal/http2: golang: golang.org/x/net: Go HTTP/2: Denial of Service via malformed SETTINGSMAXFRAMESIZE frame (CVE-2026-33814) brace-expansion: brace-expansion: Denial of Service via uncontrolled recursion in nested brace patterns (CVE-2026-102278) js-yaml: js-yaml: Denial of Service vulnerability in YAML parsing (CVE-2026-84375) urllib3: urllib3: Information disclosure via cross-origin redirects forwarding sensitive headers (CVE-2026-44431) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.All OpenShift Container Platform 4.21 users are advised to upgrade to these updated packages and images when they are available in the appropriate release channel. To check for available updates, use the OpenShift CLI (oc) or web console. Instructions for upgrading a cluster are available at https://docs.redhat.com/en/documentation/openshiftcontainerplatform/4.21/html-single/updatingclusters/index#updating-cluster-cli.

First published (updated )

-------- Forwarded Message -------- Subject: [security] Vulnerabilities in golang.org/x/net Date: Thu, 8 Oct 2026 18:09:23 +0000 From: announce () golang org To: golang-nuts () googlegroups com

Hello gophers, net/http: HTTP/2 server memory exhaustion due to Trailer headers

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.

Thanks to RyotaK (https://ryotak.net <https://ryotak.net>) of GMO Flatt Security Inc. for reporting this issue.

This is CVE-2026-78659 and Go issue https://go.dev/issue/81857 <https://go.dev/issue/81857>.

net/http: excessive CPU consumption from repeated initial window changes

A malicious HTTP/2 peer could cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGSINITIALWINDOWSIZE values.

The HTTP/2 client and server now efficiently handle changes to the initial window size (O(1) rather than O(number of streams)).

Thanks to Jakub Ciolek (https://ciolek.dev <https://ciolek.dev>) for reporting this issue.

This is CVE-2026-78669 and Go issue https://go.dev/issue/81742 <https://go.dev/issue/81742>.

net/http: double flow control refund on HTTP/2 server streams

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 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.

Thanks to Ali Sherif (https://www.linkedin.com/in/ali-sherif-13812b276/ <https://www.linkedin.com/in/ali-sherif-13812b276/>) for reporting this issue.

This is CVE-2026-78663 and Go issue https://go.dev/issue/81743 <https://go.dev/issue/81743>.

net/http: HTTP/2 server crash due to HPACK encoder race

HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGSHEADERTABLESIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.

Fix this issue by not applying SETTINGSHEADERTABLESIZE immediately. Instead, buffer any SETTINGSHEADERTABLESIZE received, and only apply the new value prior to the next time the server writes a frame.

Thanks to RyotaK (https://ryotak.net <https://ryotak.net>) of GMO Flatt Security Inc. for reporting this issue.

This is CVE-2026-97032 and Go issue https://go.dev/issue/81867 <https://go.dev/issue/81867>.

Cheers, Go Security team

--

Severity
7.5
EPSS
0.06%
Null Pointer Dereference
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Due to missing nil check, sending 0x0a-0x0f HTTP/2 frames will cause a running server to panic

1 / 3
Source: NVD
First published (updated )
Input Validation

OpenShift Data Foundation is software-defined storage integrated with and optimized for the Red Hat OpenShift Data Foundation. Red Hat OpenShift DataFoundation is a highly scalable, production-grade persistent storage for stateful applications running in the Red Hat OpenShift Container Platform. In addition to persistent storage, Red Hat OpenShift Data Foundation provisions a multi-cloud data management service with an S3 compatible API.Security Fix(es): go-retryablehttp: url might write sensitive information to log file (CVE-2024-6104) PostCSS: Improper input validation in PostCSS (CVE-2023-44270) golang.org/x/crypto/ssh: Misuse of ServerConfig.PublicKeyCallback may cause authorization bypass in golang.org/x/crypto (CVE-2024-45337) golang.org/x/net/html: Non-linear parsing of case-insensitive content in golang.org/x/net/html (CVE-2024-45338) For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203