chore(deps): update dependency uniget-org/renovate-custom to v0.0.374

[uniget-bot]

This PR contains the following updates:

Package	Update	Change
uniget-org/renovate-custom	patch	0.0.373 -> 0.0.374

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

uniget-org/renovate-custom (uniget-org/renovate-custom)

v0.0.374: namespace v0.0.374

Compare Source

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[github-actions]

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/namespace:0.0.374

📦 Image Reference ghcr.io/uniget-org/tools/namespace:0.0.374

digest	sha256:e0ac855b54b413d9a82893be545ecd2b55ac219742d8017bef750108a443b239
vulnerabilities
platform	linux/amd64
size	77 MB
packages	312

github.com/moby/buildkit 0.12.3 (golang) pkg:golang/github.com/moby/buildkit@0.12.3 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') Affected range <0.12.5 Fixed version 0.12.5 CVSS Score 10 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H Description Impact A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. Patches The issue has been fixed in v0.12.5 Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature. References Incorrect Authorization Affected range <0.12.5 Fixed version 0.12.5 CVSS Score 9.8 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H Description Impact In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special security.insecure entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. Patches The issue has been fixed in v0.12.5 . Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using buildctl build command. References Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') Affected range <0.12.5 Fixed version 0.12.5 CVSS Score 8.7 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N Description Impact Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. Patches The issue has been fixed in v0.12.5 Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options. References https://www.openwall.com/lists/oss-security/2019/05/28/1 Improper Check for Unusual or Exceptional Conditions Affected range <0.12.5 Fixed version 0.12.5 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 Impact A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic. Patches The issue has been fixed in v0.12.5 Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using buildctl build command. References

github.com/opencontainers/runc 1.1.7 (golang) pkg:golang/github.com/opencontainers/runc@1.1.7 Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak') Affected range >=1.0.0-rc93 <=1.1.11 Fixed version 1.1.12 CVSS Score 8.6 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H Description Impact In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem ("attack 2"). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run ("attack 1"). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes ("attack 3a" and "attack 3b"). Strictly speaking, while attack 3a is the most severe from a CVSS perspective, attacks 2 and 3b are arguably more dangerous in practice because they allow for a breakout from inside a container as opposed to requiring a user execute a malicious image. The reason attacks 1 and 3a are scored higher is because being able to socially engineer users is treated as a given for UI:R vectors, despite attacks 2 and 3b requiring far more minimal user interaction (just reasonable runc exec operations on a container the attacker has access to). In any case, all four attacks can lead to full control of the host system. Attack 1: process.cwd "mis-configuration" In runc 1.1.11 and earlier, several file descriptors were inadvertently leaked internally within runc into runc init, including a handle to the host's /sys/fs/cgroup (this leak was added in v1.0.0-rc93). If the container was configured to have process.cwd set to /proc/self/fd/7/ (the actual fd can change depending on file opening order in runc), the resulting pid1 process will have a working directory in the host mount namespace and thus the spawned process can access the entire host filesystem. This alone is not an exploit against runc, however a malicious image could make any innocuous-looking non-/ path a symlink to /proc/self/fd/7/ and thus trick a user into starting a container whose binary has access to the host filesystem. Furthermore, prior to runc 1.1.12, runc also did not verify that the final working directory was inside the container's mount namespace after calling chdir(2) (as we have already joined the container namespace, it was incorrectly assumed there would be no way to chdir outside the container after pivot_root(2)). The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N (8.2, high severity). Note that this attack requires a privileged user to be tricked into running a malicious container image. It should be noted that when using higher-level runtimes (such as Docker or Kubernetes), this exploit can be considered critical as it can be done remotely by anyone with the rights to start a container image (and can be exploited from within Dockerfiles using ONBUILD in the case of Docker). Attack 2: runc exec container breakout (This is a modification of attack 1, constructed to allow for a process inside a container to break out.) The same fd leak and lack of verification of the working directory in attack 1 also apply to runc exec. If a malicious process inside the container knows that some administrative process will call runc exec with the --cwd argument and a given path, in most cases they can replace that path with a symlink to /proc/self/fd/7/. Once the container process has executed the container binary, PR_SET_DUMPABLE protections no longer apply and the attacker can open /proc/$exec_pid/cwd to get access to the host filesystem. runc exec defaults to a cwd of / (which cannot be replaced with a symlink), so this attack depends on the attacker getting a user (or some administrative process) to use --cwd and figuring out what path the target working directory is. Note that if the target working directory is a parent of the program binary being executed, the attacker might be unable to replace the path with a symlink (the execve will fail in most cases, unless the host filesystem layout specifically matches the container layout in specific ways and the attacker knows which binary the runc exec is executing). The CVSS score for this attack is CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N (7.2, high severity). Attacks 3a and 3b: process.args host binary overwrite attack (These are modifications of attacks 1 and 2, constructed to overwrite a host binary by using execve to bring a magic-link reference into the container.) Attacks 1 and 2 can be adapted to overwrite a host binary by using a path like /proc/self/fd/7/../../../bin/bash as the process.args binary argument, causing a host binary to be executed by a container process. The /proc/$pid/exe handle can then be used to overwrite the host binary, as seen in CVE-2019-5736 (note that the same #! trick can be used to avoid detection as an attacker). As the overwritten binary could be something like /bin/bash, as soon as a privileged user executes the target binary on the host, the attacker can pivot to gain full access to the host. For the purposes of CVSS scoring: Attack 3a is attack 1 but adapted to overwrite a host binary, where a malicious image is set up to execute /proc/self/fd/7/../../../bin/bash and run a shell script that overwrites /proc/self/exe, overwriting the host copy of /bin/bash. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H (8.6, high severity). Attack 3b is attack 2 but adapted to overwrite a host binary, where the malicious container process overwrites all of the possible runc exec target binaries inside the container (such as /bin/bash) such that a host target binary is executed and then the container process opens /proc/$pid/exe to get access to the host binary and overwrite it. The CVSS score for this attack is CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H (8.2, high severity). As mentioned in attack 1, while 3b is scored lower it is more dangerous in practice as it doesn't require a user to run a malicious image. Patches runc 1.1.12 has been released, and includes patches for this issue. Note that there are four separate fixes applied: Checking that the working directory is actually inside the container by checking whether os.Getwd returns ENOENT (Linux provides a way of detecting if cwd is outside the current namespace root). This explicitly blocks runc from executing a container process when inside a non-container path and thus eliminates attacks 1 and 2 even in the case of fd leaks. Close all internal runc file descriptors in the final stage of runc init, right before execve. This ensures that internal file descriptors cannot be used as an argument to execve and thus eliminates attacks 3a and 3b, even in the case of fd leaks. This requires hooking into some Go runtime internals to make sure we don't close critical Go internal file descriptors. Fixing the specific fd leaks that made these bug exploitable (mark /sys/fs/cgroup as O_CLOEXEC and backport a fix for some *os.File leaks). In order to protect against future runc init file descriptor leaks, mark all non-stdio files as O_CLOEXEC before executing runc init. Other Runtimes We have discovered that several other container runtimes are either potentially vulnerable to similar attacks, or do not have sufficient protection against attacks of this nature. We recommend other container runtime authors look at our patches and make sure they at least add a getcwd() != ENOENT check as well as consider whether close_range(3, UINT_MAX, CLOSE_RANGE_CLOEXEC) before executing their equivalent of runc init is appropriate. crun 1.12 does not leak any useful file descriptors into the runc init-equivalent process (so this attack is not exploitable as far as we can tell), but no care is taken to make sure all non-stdio files are O_CLOEXEC and there is no check after chdir(2) to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to crun are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of crun can lead to these attacks becoming exploitable. youki 0.3.1 does not leak any useful file descriptors into the runc init-equivalent process (so this attack is not exploitable as far as we can tell) however this appears to be pure luck. youki does leak a directory file descriptor from the host mount namespace, but it just so happens that the directory is the rootfs of the container (which then gets pivot_root'd into and so ends up as a in-root path thanks to chroot_fs_refs). In addition, no care is taken to make sure all non-stdio files are O_CLOEXEC and there is no check after chdir(2) to ensure the working directory is inside the container. If a file descriptor happened to be leaked in the future, this could be exploitable. In addition, any file descriptors passed to youki are not closed until the container process is executed, meaning that easily-overlooked programming errors by users of youki can lead to these attacks becoming exploitable. LXC 5.0.3 does not appear to leak any useful file descriptors, and they have comments noting the importance of not leaking file descriptors in lxc-attach. However, they don't seem to have any proactive protection against file descriptor leaks at the point of chdir such as using close_range(...) (they do have RAII-like __do_fclose closers but those don't necessarily stop all leaks in this context) nor do they have any check after chdir(2) to ensure the working directory is inside the container. Unfortunately it seems they cannot use CLOSE_RANGE_CLOEXEC because they don't need to re-exec themselves. Workarounds For attacks 1 and 2, only permit containers (and runc exec) to use a process.cwd of /. It is not possible for / to be replaced with a symlink (the path is resolved from within the container's mount namespace, and you cannot change the root of a mount namespace or an fs root to a symlink). For attacks 1 and 3a, only permit users to run trusted images. For attack 3b, there is no practical workaround other than never using runc exec because any binary you try to execute with runc exec could end up being a malicious binary target. See Also https://www.cve.org/CVERecord?id=CVE-2024-21626 https://github.com/opencontainers/runc/releases/tag/v1.1.12 The runc 1.1.12 merge commit opencontainers/runc@a9833ff, which contains the following security patches: opencontainers/runc@506552a opencontainers/runc@0994249 opencontainers/runc@fbe3eed opencontainers/runc@284ba30 opencontainers/runc@b6633f4 opencontainers/runc@683ad2f opencontainers/runc@e9665f4 Credits Thanks to Rory McNamara from Snyk for discovering and disclosing the original vulnerability (attack 1) to Docker, @lifubang from acmcoder for discovering how to adapt the attack to overwrite host binaries (attack 3a), and Aleksa Sarai from SUSE for discovering how to adapt the attacks to work as container breakouts using runc exec (attacks 2 and 3b). OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <1.2.0-rc.1 Fixed version 1.2.0-rc.1 CVSS Score 7.2 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H Description Withdrawn Advisory This advisory has been withdrawn because it was incorrectly attributed to runc. Please see the issue here for more information. Original Description A flaw was found in cri-o, where an arbitrary systemd property can be injected via a Pod annotation. Any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system. This issue has its root in how runc handles Config Annotations lists. OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities Affected range <1.2.0-rc.1 Fixed version 1.2.0-rc.1 CVSS Score 7.2 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H Description On CRI-O, an arbitrary systemd property can be injected via a Pod annotation: --- apiVersion: v1 kind: Pod metadata: name: poc-arbitrary-systemd-property-injection annotations: </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 1" src="https://img.shields.io/badge/H-1-e25d68"/> <img alt="medium: 2" src="https://img.shields.io/badge/M-2-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>helm.sh/helm/v3</strong> <code>3.13.1</code> (golang)</summary> <small><code>pkg:golang/helm.sh/helm/v3@3.13.1</code></small><br/> <a href="https://scout.docker.com/v/CVE-2024-26147?s=github&n=v3&ns=helm.sh%2Fhelm&t=golang&vr=%3C3.14.2"><img alt="high 7.5: CVE--2024--26147" src="https://img.shields.io/badge/CVE--2024--26147-lightgrey?label=high%207.5&labelColor=e25d68"/></a> <i>Use of Uninitialized Variable</i> <table> <tr><td>Affected range</td><td><code><3.14.2</code></td></tr> <tr><td>Fixed version</td><td><code>3.14.2</code></td></tr> <tr><td>CVSS Score</td><td><code>7.5</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</code></td></tr> </table> <details><summary>Description</summary> <blockquote> A Helm contributor discovered uninitialized variable vulnerability when Helm parses index and plugin yaml files missing expected content. ### Impact When either an `index.yaml` file or a plugins `plugin.yaml` file were missing all metadata a panic would occur in Helm. In the Helm SDK this is found when using the `LoadIndexFile` or `DownloadIndexFile` functions in the `repo` package or the `LoadDir` function in the `plugin` package. For the Helm client this impacts functions around adding a repository and all Helm functions if a malicious plugin is added as Helm inspects all known plugins on each invocation. ### Patches This issue has been resolved in Helm v3.14.2. ### Workarounds If a malicious plugin has been added which is causing all Helm client commands to panic, the malicious plugin can be manually removed from the filesystem. If using Helm SDK versions prior to 3.14.2, calls to affected functions can use `recover` to catch the panic. ### For more information Helm's security policy is spelled out in detail in our [SECURITY](https://github.com/helm/community/blob/master/SECURITY.md) document. ### Credits Disclosed by Jakub Ciolek at AlphaSense. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-25620?s=github&n=v3&ns=helm.sh%2Fhelm&t=golang&vr=%3C%3D3.14.0"><img alt="medium 6.4: CVE--2024--25620" src="https://img.shields.io/badge/CVE--2024--25620-lightgrey?label=medium%206.4&labelColor=fbb552"/></a> <i>Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</i> <table> <tr><td>Affected range</td><td><code><=3.14.0</code></td></tr> <tr><td>Fixed version</td><td><code>3.14.1</code></td></tr> <tr><td>CVSS Score</td><td><code>6.4</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N</code></td></tr> </table> <details><summary>Description</summary> <blockquote> A Helm contributor discovered a path traversal vulnerability when Helm saves a chart including at download time. ### Impact When either the Helm client or SDK is used to save a chart whose name within the `Chart.yaml` file includes a relative path change, the chart would be saved outside its expected directory based on the changes in the relative path. The validation and linting did not detect the path changes in the name. ### Patches This issue has been resolved in Helm v3.14.1. ### Workarounds Check all charts used by Helm for path changes in their name as found in the `Chart.yaml` file. This includes dependencies. ### Credits Disclosed by Dominykas Blyžė at Nearform Ltd. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2019-25210?s=github&n=v3&ns=helm.sh%2Fhelm&t=golang&vr=%3E%3D3.0.0%2C%3C%3D3.14.2"><img alt="medium : CVE--2019--25210" src="https://img.shields.io/badge/CVE--2019--25210-lightgrey?label=medium%20&labelColor=fbb552"/></a> <i>Exposure of Sensitive Information to an Unauthorized Actor</i> <table> <tr><td>Affected range</td><td><code>>=3.0.0<br/><=3.14.2</code></td></tr> <tr><td>Fixed version</td><td><strong>Not Fixed</strong></td></tr></table> <details><summary>Description</summary> <blockquote> An issue was discovered in Cloud Native Computing Foundation (CNCF) Helm. It displays values of secrets when the --dry-run flag is used. This is a security concern in some use cases, such as a --dry-run call by a CI/CD tool. NOTE: the vendor's position is that this behavior was introduced intentionally, and cannot be removed without breaking backwards compatibility (some users may be relying on these values). </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 1" src="https://img.shields.io/badge/H-1-e25d68"/> <img alt="medium: 0" src="https://img.shields.io/badge/M-0-lightgrey"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>go.opentelemetry.io/contrib/instrumentation/net/http/httptrace/otelhttptrace</strong> <code>0.40.0</code> (golang)</summary> <small><code>pkg:golang/go.opentelemetry.io/contrib/instrumentation/net/http/httptrace/otelhttptrace@0.40.0</code></small><br/> <a href="https://scout.docker.com/v/CVE-2023-45142?s=github&n=otelhttptrace&ns=go.opentelemetry.io%2Fcontrib%2Finstrumentation%2Fnet%2Fhttp%2Fhttptrace&t=golang&vr=%3C0.44.0"><img alt="high 7.5: CVE--2023--45142" src="https://img.shields.io/badge/CVE--2023--45142-lightgrey?label=high%207.5&labelColor=e25d68"/></a> <i>Allocation of Resources Without Limits or Throttling</i> <table> <tr><td>Affected range</td><td><code><0.44.0</code></td></tr> <tr><td>Fixed version</td><td><code>0.44.0</code></td></tr> <tr><td>CVSS Score</td><td><code>7.5</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H</code></td></tr> </table> <details><summary>Description</summary> <blockquote> ### Summary This handler wrapper https://github.com/open-telemetry/opentelemetry-go-contrib/blob/5f7e6ad5a49b45df45f61a1deb29d7f1158032df/instrumentation/net/http/otelhttp/handler.go#L63-L65 out of the box adds labels - `http.user_agent` - `http.method` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it. ### Details HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally uses [httpconv.ServerRequest](https://github.com/open-telemetry/opentelemetry-go/blob/v1.12.0/semconv/internal/v2/http.go#L159) that records every value for HTTP [method](https://github.com/open-telemetry/opentelemetry-go/blob/38e1b499c3da3107694ad2660b3888eee9c8b896/semconv/internal/v2/http.go#L204) and [User-Agent](https://github.com/open-telemetry/opentelemetry-go/blob/38e1b499c3da3107694ad2660b3888eee9c8b896/semconv/internal/v2/http.go#L223). ### PoC Send many requests with long randomly generated HTTP methods or/and User agents (e.g. a million) and observe how memory consumption increases during it. ### Impact In order to be affected, the program has to configure a metrics pipeline, use [otelhttp.NewHandler](https://github.com/open-telemetry/opentelemetry-go-contrib/blob/5f7e6ad5a49b45df45f61a1deb29d7f1158032df/instrumentation/net/http/otelhttp/handler.go#L63-L65) wrapper, and does not filter any unknown HTTP methods or User agents on the level of CDN, LB, previous middleware, etc. ### Others It is similar to already reported vulnerabilities - https://github.com/open-telemetry/opentelemetry-go-contrib/security/advisories/GHSA-5r5m-65gx-7vrh ([open-telemetry/opentelemetry-go-contrib](https://github.com/open-telemetry/opentelemetry-go-contrib)) - https://github.com/advisories/GHSA-cg3q-j54f-5p7p ([prometheus/client_golang](https://github.com/prometheus/client_golang)) ### Workaround for affected versions As a workaround to stop being affected [otelhttp.WithFilter()](https://pkg.go.dev/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/filters) can be used, but it requires manual careful configuration to not log certain requests entirely. For convenience and safe usage of this library, it should by default mark with the label `unknown` non-standard HTTP methods and User agents to show that such requests were made but do not increase cardinality. In case someone wants to stay with the current behavior, library API should allow to enable it. The other possibility is to disable HTTP metrics instrumentation by passing [`otelhttp.WithMeterProvider`](https://pkg.go.dev/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp#WithMeterProvider) option with [`noop.NewMeterProvider`](https://pkg.go.dev/go.opentelemetry.io/otel/metric/noop#NewMeterProvider). ### Solution provided by upgrading In PR https://github.com/open-telemetry/opentelemetry-go-contrib/pull/4277, released with package version 0.44.0, the values collected for attribute `http.request.method` were changed to be restricted to a set of well-known values and other high cardinality attributes were removed. ### References - https://github.com/open-telemetry/opentelemetry-go-contrib/pull/4277 - https://github.com/open-telemetry/opentelemetry-go-contrib/releases/tag/v1.19.0 </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 2" src="https://img.shields.io/badge/M-2-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <img alt="unspecified: 1" src="https://img.shields.io/badge/U-1-lightgrey"/><strong>github.com/docker/docker</strong> <code>24.0.6+incompatible</code> (golang)</summary> <small><code>pkg:golang/github.com/docker/docker@24.0.6+incompatible</code></small><br/> <a href="https://scout.docker.com/v/CVE-2024-24557?s=github&n=docker&ns=github.com%2Fdocker&t=golang&vr=%3C24.0.9"><img alt="medium 6.9: CVE--2024--24557" src="https://img.shields.io/badge/CVE--2024--24557-lightgrey?label=medium%206.9&labelColor=fbb552"/></a> <i>Insufficient Verification of Data Authenticity</i> <table> <tr><td>Affected range</td><td><code><24.0.9</code></td></tr> <tr><td>Fixed version</td><td><code>24.0.9</code></td></tr> <tr><td>CVSS Score</td><td><code>6.9</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:C/C:L/I:H/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> The classic builder cache system is prone to cache poisoning if the image is built `FROM scratch`. Also, changes to some instructions (most important being `HEALTHCHECK` and `ONBUILD`) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. For example, an attacker could create an image that is considered as a valid cache candidate for: FROM scratch MAINTAINER Pawel when in fact the malicious image used as a cache would be an image built from a different Dockerfile. In the second case, the attacker could for example substitute a different `HEALTCHECK` command. ### Impact 23.0+ users are only affected if they explicitly opted out of Buildkit (`DOCKER_BUILDKIT=0` environment variable) or are using the `/build` API endpoint (which uses the classic builder by default). All users on versions older than 23.0 could be impacted. An example could be a CI with a shared cache, or just a regular Docker user pulling a malicious image due to misspelling/typosquatting. Image build API endpoint (`/build`) and `ImageBuild` function from `github.com/docker/docker/client` is also affected as it the uses classic builder by default. ### Patches Patches are included in Moby releases: - v25.0.2 - v24.0.9 - v23.0.10 ### Workarounds - Use `--no-cache` or use Buildkit if possible (`DOCKER_BUILDKIT=1`, it's default on 23.0+ assuming that the buildx plugin is installed). - Use `Version = types.BuilderBuildKit` or `NoCache = true` in `ImageBuildOptions` for `ImageBuild` call. </blockquote> </details> <a href="https://scout.docker.com/v/GHSA-jq35-85cj-fj4p?s=github&n=docker&ns=github.com%2Fdocker&t=golang&vr=%3E%3D24.0.0%2C%3C24.0.7"><img alt="medium : GHSA--jq35--85cj--fj4p" src="https://img.shields.io/badge/GHSA--jq35--85cj--fj4p-lightgrey?label=medium%20&labelColor=fbb552"/></a> <table> <tr><td>Affected range</td><td><code>>=24.0.0<br/><24.0.7</code></td></tr> <tr><td>Fixed version</td><td><code>24.0.7</code></td></tr></table> <details><summary>Description</summary> <blockquote> Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via `sysfs`. As RAPL is an interface to access a hardware feature, it is only available when running on bare metal with the module compiled into the kernel. By 2019, it was realized that in some cases unprivileged access to RAPL readings could be exploited as a power-based side-channel against security features including AES-NI (potentially inside a SGX enclave) and KASLR (kernel address space layout randomization). Also known as the [PLATYPUS attack](https://platypusattack.com/), Intel assigned [CVE-2020-8694](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694) and [CVE-2020-8695](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695), and AMD assigned [CVE-2020-12912](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912). Several mitigations were applied; Intel reduced the sampling resolution via a microcode update, and the Linux kernel [prevents access by non-root users](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71) since 5.10. However, this kernel-based mitigation does not apply to many container-based scenarios: * Unless using user namespaces, root inside a container has the same level of privilege as root outside the container, but with a slightly more narrow view of the system * `sysfs` is mounted inside containers read-only; however only read access is needed to carry out this attack on an unpatched CPU While this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments running directly on affected hardware. This is provided by masking `/sys/devices/virtual/powercap` in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile. While `sysfs` is not the only way to read from the RAPL subsystem, other ways of accessing it require additional capabilities such as `CAP_SYS_RAWIO` which is not available to containers by default, or `perf` paranoia level less than 1, which is a non-default kernel tunable. ## References * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912 * https://platypusattack.com/ * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71 * https://web.eece.maine.edu/~vweaver/projects/rapl/ </blockquote> </details> <a href="https://scout.docker.com/v/GMS-2023-3981?s=gitlab&n=docker&ns=github.com%2Fdocker&t=golang&vr=%3E%3D24.0.0%2C%3C24.0.7"><img alt="unspecified : GMS--2023--3981" src="https://img.shields.io/badge/GMS--2023--3981-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <i>OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities</i> <table> <tr><td>Affected range</td><td><code>>=24.0.0<br/><24.0.7</code></td></tr> <tr><td>Fixed version</td><td><code>v24.0.7</code></td></tr></table> <details><summary>Description</summary> <blockquote> Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via `sysfs`. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 2" src="https://img.shields.io/badge/M-2-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>github.com/jackc/pgx/v5</strong> <code>5.5.3</code> (golang)</summary> <small><code>pkg:golang/github.com/jackc/pgx/v5@5.5.3</code></small><br/> <a href="https://scout.docker.com/v/GHSA-7jwh-3vrq-q3m8?s=github&n=v5&ns=github.com%2Fjackc%2Fpgx&t=golang&vr=%3E%3D5.0.0%2C%3C5.5.4"><img alt="medium : GHSA--7jwh--3vrq--q3m8" src="https://img.shields.io/badge/GHSA--7jwh--3vrq--q3m8-lightgrey?label=medium%20&labelColor=fbb552"/></a> <i>Integer Overflow or Wraparound</i> <table> <tr><td>Affected range</td><td><code>>=5.0.0<br/><5.5.4</code></td></tr> <tr><td>Fixed version</td><td><code>5.5.4</code></td></tr></table> <details><summary>Description</summary> <blockquote> ### Impact SQL injection can occur if an attacker can cause a single query or bind message to exceed 4 GB in size. An integer overflow in the calculated message size can cause the one large message to be sent as multiple messages under the attacker's control. ### Patches The problem is resolved in v2.3.3 ### Workarounds Reject user input large enough to cause a single query or bind message to exceed 4 GB in size. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-27304?s=github&n=v5&ns=github.com%2Fjackc%2Fpgx&t=golang&vr=%3E%3D5.0.0%2C%3C5.5.4"><img alt="medium : CVE--2024--27304" src="https://img.shields.io/badge/CVE--2024--27304-lightgrey?label=medium%20&labelColor=fbb552"/></a> <i>Integer Overflow or Wraparound</i> <table> <tr><td>Affected range</td><td><code>>=5.0.0<br/><5.5.4</code></td></tr> <tr><td>Fixed version</td><td><code>5.5.4</code></td></tr></table> <details><summary>Description</summary> <blockquote> ### Impact SQL injection can occur if an attacker can cause a single query or bind message to exceed 4 GB in size. An integer overflow in the calculated message size can cause the one large message to be sent as multiple messages under the attacker's control. ### Patches The problem is resolved in v4.18.2 and v5.5.4. ### Workarounds Reject user input large enough to cause a single query or bind message to exceed 4 GB in size. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <img alt="unspecified: 1" src="https://img.shields.io/badge/U-1-lightgrey"/><strong>github.com/containerd/containerd</strong> <code>1.7.6</code> (golang)</summary> <small><code>pkg:golang/github.com/containerd/containerd@1.7.6</code></small><br/> <a href="https://scout.docker.com/v/GHSA-7ww5-4wqc-m92c?s=github&n=containerd&ns=github.com%2Fcontainerd&t=golang&vr=%3E%3D1.7.0%2C%3C%3D1.7.10"><img alt="medium : GHSA--7ww5--4wqc--m92c" src="https://img.shields.io/badge/GHSA--7ww5--4wqc--m92c-lightgrey?label=medium%20&labelColor=fbb552"/></a> <table> <tr><td>Affected range</td><td><code>>=1.7.0<br/><=1.7.10</code></td></tr> <tr><td>Fixed version</td><td><code>1.7.11</code></td></tr></table> <details><summary>Description</summary> <blockquote> # /sys/devices/virtual/powercap accessible by default to containers Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via `sysfs`. As RAPL is an interface to access a hardware feature, it is only available when running on bare metal with the module compiled into the kernel. By 2019, it was realized that in some cases unprivileged access to RAPL readings could be exploited as a power-based side-channel against security features including AES-NI (potentially inside a SGX enclave) and KASLR (kernel address space layout randomization). Also known as the [PLATYPUS attack](https://platypusattack.com/), Intel assigned [CVE-2020-8694](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694) and [CVE-2020-8695](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695), and AMD assigned [CVE-2020-12912](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912). Several mitigations were applied; Intel reduced the sampling resolution via a microcode update, and the Linux kernel [prevents access by non-root users](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71) since 5.10. However, this kernel-based mitigation does not apply to many container-based scenarios: * Unless using user namespaces, root inside a container has the same level of privilege as root outside the container, but with a slightly more narrow view of the system * `sysfs` is mounted inside containers read-only; however only read access is needed to carry out this attack on an unpatched CPU While this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments. This is provided by masking `/sys/devices/virtual/powercap` in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile. While `sysfs` is not the only way to read from the RAPL subsystem, other ways of accessing it require additional capabilities such as `CAP_SYS_RAWIO` which is not available to containers by default, or `perf` paranoia level less than 1, which is a non-default kernel tunable. ## References * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912 * https://platypusattack.com/ * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71 * https://web.eece.maine.edu/~vweaver/projects/rapl/ </blockquote> </details> <a href="https://scout.docker.com/v/GMS-2023-6564?s=gitlab&n=containerd&ns=github.com%2Fcontainerd&t=golang&vr=%3E%3D1.7.0%2C%3C%3D1.7.10"><img alt="unspecified : GMS--2023--6564" src="https://img.shields.io/badge/GMS--2023--6564-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <i>OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities</i> <table> <tr><td>Affected range</td><td><code>>=1.7.0<br/><=1.7.10</code></td></tr> <tr><td>Fixed version</td><td><code>1.6.26, 1.7.11</code></td></tr></table> <details><summary>Description</summary> <blockquote> # /sys/devices/virtual/powercap accessible by default to containers Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via `sysfs`. As RAPL is an interface to access a hardware feature, it is only available when running on bare metal with the module compiled into the kernel. By 2019, it was realized that in some cases unprivileged access to RAPL readings could be exploited as a power-based side-channel against security features including AES-NI (potentially inside a SGX enclave) and KASLR (kernel address space layout randomization). Also known as the [PLATYPUS attack](https://platypusattack.com/), Intel assigned [CVE-2020-8694](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694) and [CVE-2020-8695](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695), and AMD assigned [CVE-2020-12912](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912). Several mitigations were applied; Intel reduced the sampling resolution via a microcode update, and the Linux kernel [prevents access by non-root users](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71) since 5.10. However, this kernel-based mitigation does not apply to many container-based scenarios: * Unless using user namespaces, root inside a container has the same level of privilege as root outside the container, but with a slightly more narrow view of the system * `sysfs` is mounted inside containers read-only; however only read access is needed to carry out this attack on an unpatched CPU While this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments. This is provided by masking `/sys/devices/virtual/powercap` in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile. While `sysfs` is not the only way to read from the RAPL subsystem, other ways of accessing it require additional capabilities such as `CAP_SYS_RAWIO` which is not available to containers by default, or `perf` paranoia level less than 1, which is a non-default kernel tunable. ## References * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8694 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8695 * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-12912 * https://platypusattack.com/ * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=949dd0104c496fa7c14991a23c03c62e44637e71 * https://web.eece.maine.edu/~vweaver/projects/rapl/ </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>k8s.io/apiserver</strong> <code>0.28.3</code> (golang)</summary> <small><code>pkg:golang/k8s.io/apiserver@0.28.3</code></small><br/> <a href="https://scout.docker.com/v/CVE-2020-8552?s=gitlab&n=apiserver&ns=k8s.io&t=golang&vr=%3C1.15.10"><img alt="medium 4.3: CVE--2020--8552" src="https://img.shields.io/badge/CVE--2020--8552-lightgrey?label=medium%204.3&labelColor=fbb552"/></a> <i>OWASP Top Ten 2017 Category A9 - Using Components with Known Vulnerabilities</i> <table> <tr><td>Affected range</td><td><code><1.15.10</code></td></tr> <tr><td>Fixed version</td><td><code>1.15.10, 1.16.7, 1.17.3</code></td></tr> <tr><td>CVSS Score</td><td><code>4.3</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> The Kubernetes API server component has been found to be vulnerable to a denial of service attack via successful API requests. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>google.golang.org/protobuf</strong> <code>1.32.0</code> (golang)</summary> <small><code>pkg:golang/google.golang.org/protobuf@1.32.0</code></small><br/> <a href="https://scout.docker.com/v/CVE-2024-24786?s=github&n=protobuf&ns=google.golang.org&t=golang&vr=%3C1.33.0"><img alt="medium : CVE--2024--24786" src="https://img.shields.io/badge/CVE--2024--24786-lightgrey?label=medium%20&labelColor=fbb552"/></a> <i>Loop with Unreachable Exit Condition ('Infinite Loop')</i> <table> <tr><td>Affected range</td><td><code><1.33.0</code></td></tr> <tr><td>Fixed version</td><td><code>1.33.0</code></td></tr></table> <details><summary>Description</summary> <blockquote> The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 1" src="https://img.shields.io/badge/M-1-fbb552"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <!-- unspecified: 0 --><strong>golang.org/x/net</strong> <code>0.19.0</code> (golang)</summary> <small><code>pkg:golang/golang.org/x/net@0.19.0</code></small><br/> <a href="https://scout.docker.com/v/CVE-2023-45288?s=github&n=net&ns=golang.org%2Fx&t=golang&vr=%3C0.23.0"><img alt="medium 5.3: CVE--2023--45288" src="https://img.shields.io/badge/CVE--2023--45288-lightgrey?label=medium%205.3&labelColor=fbb552"/></a> <i>Uncontrolled Resource Consumption</i> <table> <tr><td>Affected range</td><td><code><0.23.0</code></td></tr> <tr><td>Fixed version</td><td><code>0.23.0</code></td></tr> <tr><td>CVSS Score</td><td><code>5.3</code></td></tr> <tr><td>CVSS Vector</td><td><code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L</code></td></tr> </table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> </details></td></tr> <tr><td valign="top"> <details><summary><img alt="critical: 0" src="https://img.shields.io/badge/C-0-lightgrey"/> <img alt="high: 0" src="https://img.shields.io/badge/H-0-lightgrey"/> <img alt="medium: 0" src="https://img.shields.io/badge/M-0-lightgrey"/> <img alt="low: 0" src="https://img.shields.io/badge/L-0-lightgrey"/> <img alt="unspecified: 8" src="https://img.shields.io/badge/U-8-lightgrey"/><strong>stdlib</strong> <code>1.21.5</code> (golang)</summary> <small><code>pkg:golang/stdlib@1.21.5</code></small><br/> <a href="https://scout.docker.com/v/CVE-2024-24790?s=golang&n=stdlib&t=golang&vr=%3C1.21.11"><img alt="unspecified : CVE--2024--24790" src="https://img.shields.io/badge/CVE--2024--24790-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.11</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.11</code></td></tr></table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-24789?s=golang&n=stdlib&t=golang&vr=%3C1.21.11"><img alt="unspecified : CVE--2024--24789" src="https://img.shields.io/badge/CVE--2024--24789-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.11</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.11</code></td></tr></table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-24785?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2024--24785" src="https://img.shields.io/badge/CVE--2024--24785-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-24784?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2024--24784" src="https://img.shields.io/badge/CVE--2024--24784-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2024-24783?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2024--24783" src="https://img.shields.io/badge/CVE--2024--24783-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-45290?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2023--45290" src="https://img.shields.io/badge/CVE--2023--45290-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-45289?s=golang&n=stdlib&t=golang&vr=%3C1.21.8"><img alt="unspecified : CVE--2023--45289" src="https://img.shields.io/badge/CVE--2023--45289-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.8</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.8</code></td></tr></table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> <a href="https://scout.docker.com/v/CVE-2023-45288?s=golang&n=stdlib&t=golang&vr=%3C1.21.9"><img alt="unspecified : CVE--2023--45288" src="https://img.shields.io/badge/CVE--2023--45288-lightgrey?label=unspecified%20&labelColor=lightgrey"/></a> <table> <tr><td>Affected range</td><td><code><1.21.9</code></td></tr> <tr><td>Fixed version</td><td><code>1.21.9</code></td></tr></table> <details><summary>Description</summary> <blockquote> 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. </blockquote> </details> </details></td></tr> </table>

[github-actions]

Attempting automerge. See https://github.com/uniget-org/tools/actions/runs/9397687786.

[github-actions]

PR is clean and can be merged. See https://github.com/uniget-org/tools/actions/runs/9397687786.