ghsa

### Impact An issue was found in K3s where an attacker with network access to K3s servers' apiserver/supervisor port (TCP 6443) can force the TLS server to add entries to the certificate's Subject Alternative Name (SAN) list, through a stuffing attack, until the certificate grows so large that it exceeds the maximum size allowed by TLS client implementations. OpenSSL for example will raise an `excessive message size` error when this occurs. No authentication is necessary to perform this attack, only the ability to perform a TLS handshake against the apiserver/supervisor port (TCP 6443). Affected servers will continue to operate, but clients (including both external administrative access with `kubectl` and server or agent nodes) will fail to establish new connections, thus leading to a denial of service (DoS) attack. ### Remediation Upgrade to a fixed release: - v1.28.1+k3s1 - v1.27.5+k3s1 - v1.26.8+k3s1 - v1.25.13+k3s1 - v1.24.17+k3s1 If you are using K3s 1.27 or earlier, you mus...

### Impact All versions of ArgoCD starting from v2.4 have a bug where the ArgoCD repo-server component is vulnerable to a Denial-of-Service attack vector. Specifically, the said component extracts a user-controlled tar.gz file without validating the size of its inner files. As a result, a malicious, low-privileged user can send a malicious tar.gz file that exploits this vulnerability to the repo-server, thereby harming the system's functionality and availability. Additionally, the repo-server is susceptible to another vulnerability due to the fact that it does not check the extracted file permissions before attempting to delete them. Consequently, an attacker can craft a malicious tar.gz archive in a way that prevents the deletion of its inner files when the manifest generation process is completed. ### Patches A patch for this vulnerability has been released in the following Argo CD versions: * v2.6.15 * v2.7.14 * v2.8.3 ### Workarounds The only way to completely resolve the issue...

### Impact Argo CD Cluster secrets might be managed declaratively using Argo CD / kubectl apply. As a result, the full secret body is stored in`kubectl.kubernetes.io/last-applied-configuration` annotation. https://github.com/argoproj/argo-cd/pull/7139 introduced the ability to manage cluster labels and annotations. Since clusters are stored as secrets it also exposes the `kubectl.kubernetes.io/last-applied-configuration` annotation which includes full secret body. In order to view the cluster annotations via the Argo CD API, the user must have `clusters, get` RBAC access. **Note:** In many cases, cluster secrets do not contain any actually-secret information. But sometimes, as in bearer-token auth, the contents might be very sensitive. ### Patches The bug has been patched in the following versions: * 2.8.3 * 2.7.14 * 2.6.15 ### Workarounds Update/Deploy cluster secret with `server-side-apply` flag which does not use or rely on `kubectl.kubernetes.io/last-applied-configuration`...

hutool v5.8.21 was discovered to contain a buffer overflow via the component `JSONUtil.parse()`.

hutool v5.8.21 was discovered to contain a buffer overflow via the component `jsonObject.putByPath`.

hutool v5.8.21 was discovered to contain a buffer overflow via the component `jsonArray`.

An arbitrary file upload vulnerability in the Upload Asset function of Cockpit CMS v2.6.3 allows attackers to execute arbitrary code via uploading a crafted `.shtml` file.

Jeecg boot up to v3.5.3 was discovered to contain a SQL injection vulnerability via the component `/jeecg-boot/jmreport/show`.

Jeecg boot up to v3.5.3 was discovered to contain an arbitrary file read vulnerability via the interface `/testConnection`.

Terraform version 1.0.8 through 1.5.6 allows arbitrary file write during the `init` operation if run on maliciously crafted Terraform configuration. This vulnerability is fixed in Terraform 1.5.7.