Added meteor-commit

[nicholasdille]

No description provided.

[github-actions]

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/meteor-commit:0.22.0

📦 Image Reference ghcr.io/uniget-org/tools/meteor-commit:0.22.0

digest	sha256:1a4175b3533adcd434aa7b1f38c66a9420bf4665c8d7b9b2afdfe815920bbbf6
vulnerabilities
platform	linux/amd64
size	2.1 MB
packages	30

stdlib 1.22.1 (golang) pkg:golang/stdlib@1.22.1 Affected range >=1.22.0-0 <1.22.4 Fixed version 1.22.4 Description The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms. Affected range >=1.22.0-0 <1.22.5 Fixed version 1.22.5 Description The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an "Expect: 100-continue" header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail. An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending "Expect: 100-continue" requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail. Affected range >=1.22.0-0 <1.22.4 Fixed version 1.22.4 Description The archive/zip package's handling of certain types of invalid zip files differs from the behavior of most zip implementations. This misalignment could be exploited to create an zip file with contents that vary depending on the implementation reading the file. The archive/zip package now rejects files containing these errors. Affected range >=1.22.0-0 <1.22.3 Fixed version 1.22.3 Description A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an infinite loop. Affected range >=1.22.0-0 <1.22.2 Fixed version 1.22.2 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.