The Go project reports:
net/http: improper sanitization of Transfer-Encoding
header
The HTTP/1 client accepted some invalid
Transfer-Encoding headers as indicating a "chunked"
encoding. This could potentially allow for request
smuggling, but only if combined with an intermediate
server that also improperly failed to reject the header
as invalid.
When httputil.ReverseProxy.ServeHTTP was called with a
Request.Header map containing a nil value for the
X-Forwarded-For header, ReverseProxy would set the client
IP as the value of the X-Forwarded-For header, contrary to
its documentation. In the more usual case where a Director
function set the X-Forwarded-For header value to nil,
ReverseProxy would leave the header unmodified as
expected.
compress/gzip: stack exhaustion in Reader.Read
Calling Reader.Read on an archive containing a large
number of concatenated 0-length compressed files can
cause a panic due to stack exhaustion.
encoding/xml: stack exhaustion in Unmarshal
Calling Unmarshal on a XML document into a Go struct
which has a nested field that uses the any field tag can
cause a panic due to stack exhaustion.
encoding/xml: stack exhaustion in Decoder.Skip
Calling Decoder.Skip when parsing a deeply nested XML
document can cause a panic due to stack exhaustion.
encoding/gob: stack exhaustion in Decoder.Decode
Calling Decoder.Decode on a message which contains
deeply nested structures can cause a panic due to stack
exhaustion.
path/filepath: stack exhaustion in Glob
Calling Glob on a path which contains a large number of
path separators can cause a panic due to stack
exhaustion.
io/fs: stack exhaustion in Glob
Calling Glob on a path which contains a large number of
path separators can cause a panic due to stack
exhaustion.
go/parser: stack exhaustion in all Parse* functions
Calling any of the Parse functions on Go source code
which contains deeply nested types or declarations can
cause a panic due to stack exhaustion.