Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
26 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 0.62.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.62.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The HTTP/2 server can 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 can 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.
Recommended action: Upgrade to 0.60.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values.
Recommended action: Upgrade to 0.60.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.
Recommended action: Upgrade to 0.60.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.
Recommended action: Upgrade to 0.60.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 0.60.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Go Net (golang.org/x/net) before verion 0.55.0, parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.
Recommended action: Upgrade to 0.55.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. <math, <svg, etc contexts).
Recommended action: Upgrade to 0.38.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NOPROXY environment variable is set to ".example.com", a request to "[::1%25.example.com]:80 will incorrectly match and not be proxied.
Recommended action: Upgrade to 0.36.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package;…
Recommended action: Upgrade to 0.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20190125091013-d26f9f9a57f3
Fixed in
0.0.0-20190125091013-d26f9f9a57f3· Vendor fix available
Issue
The html package (aka x/net/html) through 2018-09-25 in Go mishandles <table<math<select<mi<select</table, leading to an infinite loop during an html.Parse call because inSelectIM and inSelectInTableIM do not comply with a specification.
Recommended action: Upgrade to 0.0.0-20190125091013-d26f9f9a57f3 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Text nodes not in the HTML namespace are incorrectly literally rendered, causing text which should be escaped to not be. This could lead to an XSS attack.
Recommended action: Upgrade to 0.13.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.
Recommended action: Upgrade to 0.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net >= 0.0.0-20220524220425-1d687d428aca, < 0.1.1-0.20221104162952-702349b0e862
Fixed in
0.1.1-0.20221104162952-702349b0e862· Vendor fix available
Issue
A request smuggling attack is possible when using MaxBytesHandler. When using MaxBytesHandler, the body of an HTTP request is not fully consumed. When the server attempts to read HTTP2 frames from the connection, it will instead be reading the body of the HTTP request, which could be attacker-manipulated to represent arbitrary HTTP2 requests. Specific Go Packages Affected golang.org/x/net/http2/h2c
Recommended action: Upgrade to 0.1.1-0.20221104162952-702349b0e862 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server connections contain a cache of HTTP header keys sent by the client. While the total number of entries in this cache is capped, an attacker sending very large keys can cause the server to allocate approximately 64 MiB per open connection.
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20220906165146-f3363e06e74c
Fixed in
0.0.0-20220906165146-f3363e06e74c· Vendor fix available
Issue
In net/http in Go before 1.18.6 and 1.19.x before 1.19.1, attackers can cause a denial of service because an HTTP/2 connection can hang during closing if shutdown were preempted by a fatal error.
Recommended action: Upgrade to 0.0.0-20220906165146-f3363e06e74c (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20210428140749-89ef3d95e781
Fixed in
0.0.0-20210428140749-89ef3d95e781· Vendor fix available
Issue
golang.org/x/net/http/httpguts in Go before 1.15.12 and 1.16.x before 1.16.4 allows remote attackers to cause a denial of service (panic) via a large header to ReadRequest or ReadResponse. Server, Transport, and Client can each be affected in some configurations.
Recommended action: Upgrade to 0.0.0-20210428140749-89ef3d95e781 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20210520170846-37e1c6afe023
Fixed in
0.0.0-20210520170846-37e1c6afe023· Vendor fix available
Issue
Go through 1.15.12 and 1.16.x through 1.16.4 has a golang.org/x/net/html infinite loop via crafted ParseFragment input.
Recommended action: Upgrade to 0.0.0-20210520170846-37e1c6afe023 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20190813141303-74dc4d7220e7
Fixed in
0.0.0-20190813141303-74dc4d7220e7· Vendor fix available
Issue
Some HTTP/2 implementations are vulnerable to a reset flood, potentially leading to a denial of service. Servers that accept direct connections from untrusted clients could be remotely made to allocate an unlimited amount of memory, until the program crashes. The attacker opens a number of streams and sends an invalid request over each stream that should solicit a stream of RSTSTREAM frames from the peer. Depending on how the peer queues the RSTSTREAM frames, this can consume excess memory, CPU, or both. Specific Go Packages Affected golang.org/x/net/http2
Recommended action: Upgrade to 0.0.0-20190813141303-74dc4d7220e7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20190813141303-74dc4d7220e7
Fixed in
0.0.0-20190813141303-74dc4d7220e7· Vendor fix available
Issue
Some HTTP/2 implementations are vulnerable to ping floods, potentially leading to a denial of service. The attacker sends continual pings to an HTTP/2 peer, causing the peer to build an internal queue of responses. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both. Specific Go Packages Affected golang.org/x/net/http2
Recommended action: Upgrade to 0.0.0-20190813141303-74dc4d7220e7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20190125002852-4b62a64f59f7
Fixed in
0.0.0-20190125002852-4b62a64f59f7· Vendor fix available
Issue
The html package (aka x/net/html) through 2018-09-25 in Go mishandles <math<template<mn<b</template, leading to a "panic: runtime error" (index out of range) in (insertionModeStack).pop in node.go, called from inHeadIM, during an html.Parse call.
Recommended action: Upgrade to 0.0.0-20190125002852-4b62a64f59f7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20190125002852-4b62a64f59f7
Fixed in
0.0.0-20190125002852-4b62a64f59f7· Vendor fix available
Issue
The html package (aka x/net/html) through 2018-09-25 in Go mishandles <svg<template<desc<t<svg</template, leading to a panic: runtime error (index out of range) in (nodeStack).pop in node.go, called from (parser).clearActiveFormattingElements, during an html.Parse call.
Recommended action: Upgrade to 0.0.0-20190125002852-4b62a64f59f7 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20180925071336-cf3bd585ca2a
Fixed in
0.0.0-20180925071336-cf3bd585ca2a· Vendor fix available
Issue
The html package (aka x/net/html) through 2018-09-17 in Go mishandles <math<template<mo<template, leading to a "panic: runtime error" in parseCurrentToken in parse.go during an html.Parse call
Recommended action: Upgrade to 0.0.0-20180925071336-cf3bd585ca2a (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go golang.org/x/net < 0.0.0-20180921000356-2f5d2388922f
Fixed in
0.0.0-20180921000356-2f5d2388922f· Vendor fix available
Issue
The html package (aka x/net/html) through 2018-09-17 in Go mishandles <template<tBody<isindex/action=0, leading to a "panic: runtime error" in inBodyIM in parse.go during an html.Parse call
Recommended action: Upgrade to 0.0.0-20180921000356-2f5d2388922f (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.