-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Testing auto-creation of subdirs #4270
Conversation
🔍 Vulnerabilities of
|
digest | sha256:9a1b04f1d001e82b4e2d60c6722d7474c0a08e2263892239b421a2cfa531fe45 |
vulnerabilities | |
platform | linux/amd64 |
size | 10 MB |
packages | 24 |
golang.org/x/net
|
Affected range | <0.23.0 |
Fixed version | 0.23.0 |
CVSS Score | 5.3 |
CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L |
Description
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.
stdlib 1.21.7
(golang)
Affected range | <1.21.8 |
Fixed version | 1.21.8 |
Description
If errors returned from MarshalJSON methods contain user controlled data, they may be used to break the contextual auto-escaping behavior of the html/template package, allowing for subsequent actions to inject unexpected content into templates.
Affected range | <1.21.8 |
Fixed version | 1.21.8 |
Description
The ParseAddressList function incorrectly handles comments (text within parentheses) within display names. Since this is a misalignment with conforming address parsers, it can result in different trust decisions being made by programs using different parsers.
Affected range | <1.21.8 |
Fixed version | 1.21.8 |
Description
Verifying a certificate chain which contains a certificate with an unknown public key algorithm will cause Certificate.Verify to panic.
This affects all crypto/tls clients, and servers that set Config.ClientAuth to VerifyClientCertIfGiven or RequireAndVerifyClientCert. The default behavior is for TLS servers to not verify client certificates.
Affected range | <1.21.8 |
Fixed version | 1.21.8 |
Description
When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion.
With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines.
Affected range | <1.21.8 |
Fixed version | 1.21.8 |
Description
When following an HTTP redirect to a domain which is not a subdomain match or exact match of the initial domain, an http.Client does not forward sensitive headers such as "Authorization" or "Cookie". For example, a redirect from foo.com to www.foo.com will forward the Authorization header, but a redirect to bar.com will not.
A maliciously crafted HTTP redirect could cause sensitive headers to be unexpectedly forwarded.
Affected range | <1.21.9 |
Fixed version | 1.21.9 |
Description
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.
Attempting automerge. See https://github.com/uniget-org/tools/actions/runs/8753573557. |
PR is blocked and can not be merged. See https://github.com/uniget-org/tools/actions/runs/8753573557. |
No description provided.