You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.
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; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.
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.
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.
[mirror] Go supplementary network libraries
Library home page: https://proxy.golang.org/github.com/golang/net/@v/v0.1.0.zip
Path to dependency file: /go.mod
Path to vulnerable library: /go.mod
Vulnerabilities
**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation
Details
Vulnerable Library - github.com/golang/net-v0.1.0
[mirror] Go supplementary network libraries
Library home page: https://proxy.golang.org/github.com/golang/net/@v/v0.1.0.zip
Path to dependency file: /go.mod
Path to vulnerable library: /go.mod
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.
Publish Date: 2024-04-04
URL: CVE-2023-45288
CVSS 3 Score Details (7.5)
Base Score Metrics:
Suggested Fix
Type: Upgrade version
Release Date: 2023-10-06
Fix Resolution: golang/net - v0.23.0
⛑️ Automatic Remediation will be attempted for this issue.
Vulnerable Library - github.com/golang/net-v0.1.0
[mirror] Go supplementary network libraries
Library home page: https://proxy.golang.org/github.com/golang/net/@v/v0.1.0.zip
Path to dependency file: /go.mod
Path to vulnerable library: /go.mod
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
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; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.
Publish Date: 2023-10-11
URL: CVE-2023-39325
CVSS 3 Score Details (7.5)
Base Score Metrics:
Suggested Fix
Type: Upgrade version
Origin: https://pkg.go.dev/vuln/GO-2023-2102
Release Date: 2023-10-11
Fix Resolution: go1.20.10, go1.21.3, golang.org/x/net - v0.17.0
⛑️ Automatic Remediation will be attempted for this issue.
Vulnerable Library - github.com/golang/net-v0.1.0
[mirror] Go supplementary network libraries
Library home page: https://proxy.golang.org/github.com/golang/net/@v/v0.1.0.zip
Path to dependency file: /go.mod
Path to vulnerable library: /go.mod
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
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.
Publish Date: 2023-01-13
URL: CVE-2022-41721
CVSS 3 Score Details (7.5)
Base Score Metrics:
Suggested Fix
Type: Upgrade version
Release Date: 2023-01-13
Fix Resolution: v0.2.0
⛑️ Automatic Remediation will be attempted for this issue.
Vulnerable Library - github.com/golang/net-v0.1.0
[mirror] Go supplementary network libraries
Library home page: https://proxy.golang.org/github.com/golang/net/@v/v0.1.0.zip
Path to dependency file: /go.mod
Path to vulnerable library: /go.mod
Dependency Hierarchy:
Found in base branch: main
Vulnerability Details
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.
Publish Date: 2023-08-02
URL: CVE-2023-3978
CVSS 3 Score Details (6.1)
Base Score Metrics:
Suggested Fix
Type: Upgrade version
Origin: https://www.cve.org/CVERecord?id=CVE-2023-3978
Release Date: 2023-08-02
Fix Resolution: v0.13.0
⛑️ Automatic Remediation will be attempted for this issue.
⛑️Automatic Remediation will be attempted for this issue.
The text was updated successfully, but these errors were encountered: