ghsa

# Impact Guest orders may be viewed without authentication using a "guest-view" cookie which contains the order's "protect_code". This code is 6 hexadecimal characters which is arguably not enough to prevent a brute-force attack. Exposing each order would require a separate brute force attack. # Patches None. # Workarounds Implementing rate-limiting at the web server would help mitigate the issue. In particular, a very strict rate limit (e.g. 1 per minute per IP) for the specific route (`sales/guest/view/`) would effectively mitigate the issue. # References Email from Frank Rochlitzer ([email protected]) to [email protected]: ## Summary The German Federal Office for Information Security (BSI) found the following flaw in OpenMage through a commissioned pen test: The web application was found to accept certain requests even without prior strong authentication if the person making the request has data that is non-public but also not secret, such as easily easily guessed t...

Affected versions do not enforce a `Sync` bound on the type of caller-provided value held in the plugin registry. References to these values are made accessible to arbitrary threads other than the one that constructed them. A caller could use this flaw to submit thread-unsafe data into inventory, then access it as a reference simultaneously from multiple threads. The flaw was corrected by enforcing that data submitted by the caller into inventory is `Sync`.

Affected versions dereference a potentially unaligned pointer. The pointer is commonly unaligned in practice, resulting in undefined behavior. In some build modes, this is observable as a panic followed by abort. In other build modes the UB may manifest in some other way, including the possibility of working correctly in some architectures. The crate is not currently maintained, so a patched version is not available. ## Recommended alternatives - [`sysinfo`](https://crates.io/crates/sysinfo)

Affected versions allow arbitrary caller-provided code to execute before the lifetime of `main`. If the caller-provided code accesses particular pieces of the standard library that require an initialized Rust runtime, such as `std::io` or `std::thread`, these may not behave as documented. Panics are likely; UB is possible. The flaw was corrected by enforcing that only code written within the `inventory` crate, which is guaranteed not to access runtime-dependent parts of the standard library, runs before `main`. Caller-provided code is restricted to running at compile time.

### Impact Under certain circumstances, an attacker could successfully submit an entity id for an `EntityType` that is *not* part of the valid choices. Affected applications are any that use: * A custom `query_builder` option to limit the valid results; AND * An `EntityType` with `'autocomplete' => true` or a custom [AsEntityAutocompleteField](https://symfony.com/bundles/ux-autocomplete/current/index.html#usage-in-a-form-with-ajax). Under this circumstance, if an id is submitted, it is accepted even if the matching record would not be returned by the custom query built with `query_builder`. ### Patches The problem has been fixed in `symfony/ux-autocomplete` version 2.11.2. ### Workarounds Upgrade to version 2.11.2 or greater of `symfony/ux-autocomplete` or perform extra validation after submit to verify the selected option is valid.

### Impact An issue was found in RKE2 where an attacker with network access to RKE2 servers' supervisor port (TCP 9345) 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 supervisor port (TCP 9345). Affected servers will continue to operate, but clients (server or agent nodes) will fail to establish new connections when joining or rejoining the cluster, thus leading to a denial of service (DoS) attack. ### Remediation Upgrade to a fixed release: - v1.28.1+rke2r1 - v1.27.5+rke2r1 - v1.26.8+rke2r1 - v1.25.13+rke2r1 - 1.24.17+rke2r1 If you are using RKE2 1.27 or earlier, you must also add the parameter `tls-san-se...

### 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`...

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.