Interchaintest v8

[ash-burnt]

No description provided.

[github-actions]

🔍 Vulnerabilities of burnt/xion:scout

📦 Image Reference burnt/xion:scout

digest	sha256:81e33f79e39d533ff17c0770e00843cd32350da5e5d61db89632d7ea7df69c17
vulnerabilities
size	87 MB
packages	242

📦 Base Image alpine:3.19

also known as	3.19.3
digest	sha256:8d733e27df31ac40ec64633002a200a0aed5477866730e0bfeb8d2dec5d8e76a
vulnerabilities

stdlib 1.22.3 (golang) pkg:golang/stdlib@1.22.3 Affected range >=1.22.0-0 <1.22.4 Fixed version 1.22.4 EPSS Score 0.06% EPSS Percentile 27th percentile 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 EPSS Score 0.04% EPSS Percentile 16th percentile 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 EPSS Score 0.04% EPSS Percentile 10th percentile 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.

github.com/hashicorp/go-getter 1.7.4 (golang) pkg:golang/github.com/hashicorp/go-getter@1.7.4 Improper Neutralization of Special Elements used in a Command ('Command Injection') Affected range <1.7.5 Fixed version 1.7.5 CVSS Score 8.4 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:H EPSS Score 0.04% EPSS Percentile 9th percentile Description HashiCorp’s go-getter library can be coerced into executing Git update on an existing maliciously modified Git Configuration, potentially leading to arbitrary code execution. When go-getter is performing a Git operation, go-getter will try to clone the given repository in a specified destination. Cloning initializes a git config to the provided destination and if the repository needs to get updated go-getter will pull the new changes . An attacker may alter the Git config after the cloning step to set an arbitrary Git configuration to achieve code execution.

github.com/cometbft/cometbft 0.38.7 (golang) pkg:golang/github.com/cometbft/cometbft@0.38.7 Externally Controlled Reference to a Resource in Another Sphere Affected range >=0.38.0 <0.38.8 Fixed version 0.38.8 Description Name: ASA-2024-008: Instability during blocksync when syncing from malicious peer Component: CometBFT Criticality: Medium (ACMv1: I:Moderate; L: Possible) Affected versions: < v0.38.7 Summary An issue was identified for nodes syncing on an existing network during blocksync in which a malicious peer could cause the syncing peer to panic, enter into a catastrophic invalid syncing state or get stuck in blocksync mode, never switching to consensus. It is recommended for all clients to adopt this patch so that blocksync functions as expected and is tolerant of malicious peers presenting invalid data in this situation. Nodes that are vulnerable to this state may experience a Denial of Service condition in which syncing will not work as expected when joining a network as a client. Recognition This issue was reported to the Cosmos Bug Bounty Program on HackerOne on 5/01/24 by unknown_feature. If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos. If you have questions about Interchain security efforts, please reach out to our official communication channel at security@interchain.io. For more information about CometBFT, please see https://docs.cometbft.com/. For more information about the Interchain Foundation’s engagement with Amulet, please see https://github.com/interchainio/security.