Stamparm

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 7.0.0 **Description** Authenticated users can cause a denial of service by uploading large amounts of data, which may exhaust the disk space of the Incus server and potentially crash the host system. This occurs because multiple binary import paths accept `application/octet-stream` requests and stream the HTTP request body directly into temporary files on the host without a request-size limit. The daemon uses direct `io.Copy` operations to write attacker-controlled streams into host storage before any validation or parsing takes place. This issue affects the following flows: - Instance backup import via the '/1.0/instances' endpoint - Storage bucket import - Storage volume import (including ISO uploads) The impact is reduced for users utilizing `storage.images volume` and `storage.backups volume`, as uploads are stored on those specific volumes rather than the host filesystem, which is the default configuration in IncusOS. **Recommendations** Update to version 7.0.0.

**Name of the Vulnerable Software and Affected Versions** Incus (affected versions not specified) **Description** A nil-pointer dereference exists in the custom volume backup import subsystem. An authenticated user with access to the storage volume feature can cause the Incus daemon to crash by importing a crafted backup archive. The issue occurs because the daemon iterates over the `VolumeSnapshots` slice in `srcBackup.Config` and dereferences elements without validating if they are initialized. An attacker can provide an `index.yaml` file containing explicit null array elements in the `volume snapshots` array, which the YAML unmarshaler converts into nil pointers. This triggers a crash in the `CreateCustomVolumeFromBackup()` function, leading to a denial of service on the node. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 7.0.0 **Description** Missing validation logic in the storage volume import logic allows an authenticated user with access to the storage volume feature to cause the Incus daemon to crash. The backup restore subsystem and the migration path contain an out-of-bounds panic caused by an invalid bounds check when indexing snapshot metadata arrays. Specifically, when iterating through physical snapshots in a backup archive, the loop uses an index to look up metadata in the `Config.Snapshots` and `Config.VolumeSnapshots` slices. The guard condition `len(slice) >= i-1` is incorrect, allowing the subsequent `slice[i]` access to be out of bounds, which triggers a runtime panic. An attacker can exploit this by submitting a backup archive containing physical snapshot directories while providing a tampered `index.yaml` file with an empty or truncated snapshot metadata array. This causes the daemon to index beyond the end of the metadata slice and crash, leading to a denial of service. **Recommendations** Update to version 7.0.0.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 7.0.0 **Description** Broken TLS validation logic in the OVN database connection logic allows connections to an attacker's OVN database. The OVN client implementations disable standard Go TLS server verification and use a custom peer-certificate verification logic that fails to anchor trust in the configured CA certificate. Instead, the system constructs the verification root set from certificates supplied by the peer during the handshake, meaning the configured CA is parsed but ignored for the final verification decision. In OVN-enabled deployments using these SSL database connection paths, an attacker capable of impersonating or intercepting the OVN endpoint on the management network can present a rogue self-signed certificate chain, which Incus will accept as valid. This affects authenticated connections to the OVN northbound and southbound databases, which serve as authoritative control-plane interfaces for logical network configuration and distribution. This failure in the CA-based trust model permits endpoint impersonation by an active attacker in a suitable network position. **Recommendations** Update to version 7.0.0.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 7.0.0 **Description** Missing validation logic in the storage bucket import process allows an authenticated user with access to the storage bucket feature to cause the Incus daemon to crash. The issue occurs in the backup metadata handling logic when the daemon processes the `index.yaml` file from an imported archive. Specifically, the daemon accesses members of the parsed backup configuration without verifying that the configuration object was initialized. A malformed `index.yaml` that omits the config block triggers a nil-pointer dereference—a runtime error in Go that occurs when attempting to access memory through a pointer that is not pointing to a valid object—within the `CreateBucketFromBackup()` function. This results in a daemon crash and can be repeatedly exploited to cause a denial of service, keeping Incus offline. **Recommendations** Update to version 7.0.0.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 7.0.0 **Description** An authenticated user can cause the daemon to make blind outbound HEAD requests to arbitrary destinations. This occurs because the image import flow issues a request to a user-supplied URL via the `imgPostURLInfo()` function before validating the request against project restrictions, such as `restricted.images.servers`. This creates a blind server-side request forgery (SSRF) primitive—a technique where an attacker forces a server to send requests to an unintended location—which can be used to probe internal services, unroutable address space, or cloud metadata endpoints reachable from the host. Additionally, these requests include custom headers (`Incus-Server-Architectures` and `Incus-Server-Version`) that disclose host environment information to the attacker-controlled endpoint. **Recommendations** Update to version 7.0.0. As a temporary workaround, restrict access to the image import functionality for untrusted authenticated users to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 6.23.0 **Description** Incus, a system container and virtual machine manager, contains a flaw where a specially crafted storage bucket backup can be used by a user with access to the storage bucket feature to crash the Incus daemon. Repeated exploitation of this issue can lead to a denial of service of the control plane API. This does not affect running containers or virtual machines. The issue is due to an unchecked string slicing vulnerability in the S3 transfer manager, specifically during S3 restore operations. The code fails to validate header names before slicing strings, and a malicious archive containing a header name shorter than expected can trigger a slice-bounds panic, terminating the daemon. The vulnerable code is located in the `UploadAllFiles` function within the `internal/server/storage/s3/transfer manager.go` file. **Recommendations** Update Incus to version 6.23.0 or later.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 6.23.0 **Description** Incus, a system container and virtual machine manager, has an issue in its API for retrieving VM screenshots. This API uses a temporary file for QEMU to write the screenshot to, which is then sent to the user. Versions prior to 6.23.0 use predictable paths under /tmp for these temporary files. An attacker with local access can exploit this by creating symlinks. On most Linux systems with the `protected symlinks` kernel security feature enabled, this results in a "Permission denied" error. However, on systems where this feature is disabled, an attacker can trick Incus into truncating and altering the mode and permissions of arbitrary files on the filesystem, potentially leading to a denial of service or local privilege escalation. The vulnerable code is located in the `instanceConsoleGet` function within `cmd/incusd/instance console.go` and the `ConsoleScreenshot` function within `internal/server/instance/drivers/driver qemu.go`. A proof-of-concept (PoC) demonstrates that an attacker can pre-place symlink traps and coerce the Incus daemon into truncating and changing the ownership of a sensitive host file. The `/proc/sys/fs/protected symlinks` file can be checked to determine if the kernel protection mechanism is disabled, with a value of 0 indicating it is disabled. **Recommendations** Versions prior to 6.23.0 should be updated to version 6.23.0 or later.

**Name of the Vulnerable Software and Affected Versions** Incus versions prior to 6.23.0 **Description** Incus is a system container and virtual machine manager. Incus instances allow providing credentials to systemd within the guest environment, managed through a shared directory for containers. Prior to version 6.23.0, an attacker could manipulate a configuration key, such as `systemd.credential.../../../../../../root/.bashrc`, to induce Incus to write files outside the designated `credentials` directory. This is possible because the Incus syntax for credentials, `systemd.credential.XYZ`, permits multiple periods within the `XYZ` component. While reading data is not possible through this method, writing to arbitrary files as root is achievable, potentially leading to privilege escalation and denial of service attacks. The vulnerability leverages the ability to traverse directory structures using specially crafted credential names. **Recommendations** Versions prior to 6.23.0 should be updated to version 6.23.0 or later.

**Name of the Vulnerable Software and Affected Versions** Conda Constructor versions prior to 3.11.3 **Description** The issue concerns the Conda Constructor, a tool for creating installers for conda packages. Prior to version 3.11.3, the shell installer scripts process the installation prefix using an eval statement, which executes unsanitized user input as shell code. This allows an attacker to inject arbitrary commands through a malicious path during installation, although it requires explicit user action. The script runs with user privileges, not root. **Recommendations** For versions prior to 3.11.3, update to version 3.11.3 to resolve the issue. As a temporary workaround, consider avoiding the use of the shell installer scripts until the update is applied.

**Name of the Vulnerable Software and Affected Versions** Conda-build versions prior to 25.4.0 **Description** The issue is related to path traversal attacks due to improper sanitization of tar entry paths in the conda-build processing logic. This could allow attackers to craft tar archives that write files outside the intended extraction directory, potentially leading to arbitrary file overwrites, privilege escalation, or code execution if sensitive locations are targeted. **Recommendations** For versions prior to 25.4.0, update to version 25.4.0 to resolve the issue. As a temporary workaround, consider restricting the use of conda-build to minimize the risk of exploitation. Avoid using conda-build to extract tar archives from untrusted sources until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** conda-build versions prior to 25.4.0 **Description** The conda-build recipe processing logic is vulnerable to arbitrary code execution due to unsafe evaluation of recipe selectors. This is because conda-build uses the eval function to process embedded selectors in meta.yaml files without proper sanitization, allowing arbitrary code to be executed during the build process. This compromises the integrity of the build environment and may allow unauthorized commands or file operations to be performed. The issue stems from the risk of using eval() on untrusted input in a context intended to control dynamic build configurations. **Recommendations** For versions prior to 25.4.0, update to version 25.4.0 to resolve the issue. As a temporary workaround, consider disabling the use of eval() for recipe processing or restricting the execution of user-defined expressions in meta.yaml files until a patch is applied. Avoid using the eval function for untrusted input in the build process.

**Name of the Vulnerable Software and Affected Versions** conda-build versions prior to 25.3.1 **Description** The issue in conda-build allows attackers with filesystem access to exploit a race condition and overwrite a temporary build script, potentially leading to arbitrary code execution under the victim's privileges. This risk is significant in shared environments and could result in full system compromise. Attackers can monitor parent directories for file creation events, infer directory names via timestamps or logs, and use automation to exploit the issue rapidly. **Recommendations** For versions prior to 25.3.1, consider updating to version 25.3.1 to resolve the issue. As a temporary workaround, restrict conda build.sh permissions from 0o766 to 0o700 (owner-only read/write/execute). Use atomic file creation (write to a temporary randomized filename and rename atomically) to minimize the race condition window.

**Name of the Vulnerable Software and Affected Versions** conda-forge-ci-setup versions prior to 4.15.0 **Description** The conda-forge-ci-setup-feedstock setup script is vulnerable due to the unsafe use of the `eval` function when parsing version information from a custom-formatted `meta.yaml` file. An attacker controlling `meta.yaml` can inject malicious code into the version assignment, which is executed during file processing, leading to arbitrary code execution. Exploitation requires an attacker to modify the recipe file by manipulating the `RECIPE DIR` variable and introducing a malicious `meta.yaml` file. While this is more feasible in CI/CD pipelines, it is uncommon in typical environments, reducing overall risk. **Recommendations** For versions prior to 4.15.0, update to version 4.15.0 to fix the vulnerability. As a temporary workaround, consider restricting access to the `meta.yaml` file and the `RECIPE DIR` variable to minimize the risk of exploitation. Avoid using the `eval` function when parsing version information from custom-formatted files until the issue is resolved.

Name of the Vulnerable Software and Affected Versions: OpenTelemetry Collector versions prior to 0.102.1 confighttp module versions prior to 0.102.0 configgrpc module versions prior to 0.102.1 Description: An unsafe decompression vulnerability allows unauthenticated attackers to crash the collector via excessive memory consumption. The OpenTelemetry Collector handles compressed HTTP requests by recognizing the Content-Encoding header, rewriting the HTTP request body, and allowing subsequent handlers to process decompressed data. A malicious attacker could leverage this weakness to crash the collector by sending a small request that, when uncompressed by the server, results in excessive memory consumption. The issue was confirmed through proof-of-concept testing, where all supported compression algorithms could be abused, with zstd causing the most significant impact. Recommendations: For OpenTelemetry Collector versions prior to 0.102.1, update to version 0.102.1 or later. For confighttp module versions prior to 0.102.0, update to version 0.102.0 or later. For configgrpc module versions prior to 0.102.1, update to version 0.102.1 or later. As a temporary workaround, consider disabling support for decompressing client HTTP requests entirely or limit the size of the decompressed data that can be processed. Limiting the decompressed data size can be achieved by wrapping the decompressed data reader inside an io.LimitedReader, which restricts the reading to a specified number of bytes.