testkube-migration-2.7.1_linux_amd64

digest	sha256:b710e19ff3777c1a4246b9beae9aca6bdae91c8b8ffe2f880207fc42d9619a03
vulnerabilities
platform	linux/amd64
size	36 MB
packages	241

github.com/docker/cli 27.1.1+incompatible (golang) pkg:golang/github.com/docker/cli@27.1.1%2Bincompatible Uncontrolled Search Path Element Affected range >=19.03.0 <29.2.0 Fixed version 29.2.0 CVSS Score 7 CVSS Vector CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.011% EPSS Percentile 1st percentile Description This issue affects Docker CLI through 29.1.5 Impact Docker CLI for Windows searches for plugin binaries in C:\ProgramData\Docker\cli-plugins, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the docker CLI is executed as a privileged user. This issue affects Docker CLI through v29.1.5 (fixed in v29.2.0). It impacts Windows binaries acting as a CLI plugin manager via the github.com/docker/cli/cli-plugins/manager package, which is consumed by downstream projects such as Docker Compose. Docker Compose became affected starting in v2.31.0, when it incorporated the relevant CLI plugin manager code (see https://github.com/docker/compose/pull/12300), and is fixed in v5.1.0. This issue does not impact non-Windows binaries or projects that do not use the plugin manager code. Patches Fixed version starts with 29.2.0 This issue was fixed in https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa (https://github.com/docker/cli/pull/6713), which removed %PROGRAMDATA%\Docker\cli-plugins from the list of paths used for plugin-discovery on Windows. Workarounds None Resources Pull request: "cli-plugins/manager: remove legacy system-wide cli-plugin path" (https://github.com/docker/cli/pull/6713) Patch: https://github.com/docker/cli/commit/13759330b1f7e7cb0d67047ea42c5482548ba7fa.patch Credits Nitesh Surana (niteshsurana.com) of Trend Research of TrendAI

github.com/nats-io/nats-server/v2 2.11.4 (golang) pkg:golang/github.com/nats-io/nats-server@2.11.4#v2 Improper Handling of Highly Compressed Data (Data Amplification) Affected range <2.11.12 Fixed version 2.11.12 CVSS Score 5.9 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.070% EPSS Percentile 21st percentile Description Impact The WebSockets handling of NATS messages handles compressed messages via the WebSockets negotiated compression. The implementation bound the memory size of a NATS message but did not independently bound the memory consumption of the memory stream when constructing a NATS message which might then fail validation for size reasons. An attacker can use a compression bomb to cause excessive memory consumption, often resulting in the operating system terminating the server process. The use of compression is negotiated before authentication, so this does not require valid NATS credentials to exploit. The fix was to bounds the decompression to fail once the message was too large, instead of continuing on. Patches This was released in nats-server without being highlighted as a security issue. It should have been, this was an oversight. Per the NATS security policy, because this does not require a valid user, it is CVE-worthy. This was fixed in the v2.11 series with v2.11.12 and in the v2.12 series with v2.12.3. Workarounds This only affects deployments which use WebSockets and which expose the network port to untrusted end-points. References This was reported to the NATS maintainers by Pavel Kohout of Aisle Research (www.aisle.com).