Base de CVEs

A malicious builder peer may be able to request an in-context file by name from the host and receive the contents of whatever the name resolves to, even when it resolves outside the build context. This vulnerability is addressed in container version 1.2.0.

libgit2 is a portable C implementation of the Git core methods provided as a linkable library with a solid API, allowing to build Git functionality into your application. Prior to 1.8.6 and 1.9.5, libgit2 does not reject traversal components in a submodule path loaded from .gitmodules. The affected src/libgit2/submodule.c paths include git_submodule_lookup and git_submodule_add_setup. A crafted repository can specify a path such as ../escape-target, and applications that initialize the submodule can create directories outside the repository working tree. This issue is fixed in versions 1.8.6 and 1.9.5.

Mongoose is an embedded web server and network library. Prior to 7.22, an attacker who can control an SSI-enabled file can place directory traversal sequences in an #include file or #include virtual directive. The mg_ssi() function in src/ssi.c concatenates the directive argument into a filesystem path without calling mg_path_is_sane(), allowing an MG_ENABLE_SSI deployment with ssi_pattern configured to disclose files readable by the Mongoose process. This issue is fixed in version 7.22.

Banks generates meaningful LLM prompts using a simple template language. Prior to version 2.4.5, DirectoryPromptRegistry.set() in src/banks/registries/directory.py interpolates attacker-controlled Prompt.name and Prompt.version values into a Path without canonicalization or containment validation. Relative traversal such as ../victim/foo and an absolute Prompt.name can escape or discard the configured registry root, while overwrite=True permits replacement of existing target files. The poisoned name is persisted in index.json and reconstructed by _load(), allowing the out-of-root path to survive later registry loads. An application that forwards request data into these fields can therefore write Prompt.raw bytes to attacker-chosen paths writable by the application process. This issue is fixed in version 2.4.5.

VictoriaMetrics is a scalable solution for monitoring and managing time series data. Prior to 1.122.25, 1.136.12, and 1.146.0, vmrestore does not validate backup part path components before using lib/backup/actions/restore.go and lib/backup/fslocal/fslocal.go to write restored data below storageDataPath. An attacker who can supply or modify an S3, GCS, Azure Blob Storage, or other backup source can place .. components in object names. When an operator restores that source, the crafted names can create or overwrite files outside the intended restore root within the filesystem permissions of the vmrestore process. This issue is fixed in versions 1.122.25, 1.136.12, and 1.146.0.

A path traversal vulnerability in ATutor's error log viewer allows an attacker with administrative privileges to access arbitrary files outside the intended logs directory. This can lead to unauthorized access to sensitive files and other resources accessible to the web server process. Product is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable.

In Splunk SOAR versions below 8.6.0, a user who holds the Administrator role could use path traversal in the Universal Forwarder installer's archive extraction to write files outside the intended installation directory. The vulnerability is possible because the Universal Forwarder credentials-package extraction workflow does not verify that each archive member remains within the intended destination before extraction. For more information see Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) and Configure forwarders to send SOAR data to your Splunk deployment (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/configure-administration-settings-in-splunk-soar-on-premises/configure-forwarders-to-send-soar-data-to-your-splunk-deployment) in the Splunk documentation.

In Splunk SOAR versions below 8.6.0, a user with app-install privileges could use path traversal during app installation to write files outside the intended temporary directory. The vulnerability is a path traversal in the archive extraction routine, which does not validate that extracted file paths stay within the intended destination directory. For more information see Manage roles and permissions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-on-premises) and Add and configure apps and assets to provide actions in Splunk SOAR (On-premises) (https://help.splunk.com/en/splunk-soar/soar-on-premises/administer-soar-on-premises/8.5.0/manage-your-splunk-soar-on-premises-apps-and-assets/add-and-configure-apps-and-assets-to-provide-actions-in-splunk-soar-on-premises) in the Splunk documentation.

In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, an unauthenticated user could read JavaScript files outside the Splunk Web static directory. The vulnerability is possible because Splunk Web does not restrict static file requests to the configured static directory.

A vulnerability was found in yangzongzhuan RuoYi-Vue up to 3.9.2. This impacts the function fileDownload/resourceDownload of the file ruoyi-admin/src/main/java/com/ruoyi/web/controller/common/CommonController.java of the component Common Download Endpoint. Performing a manipulation of the argument fileName/resource results in path traversal. It is possible to initiate the attack remotely. The exploit has been made public and could be used. The project was informed of the problem early through an issue report but has not responded yet.

IBM OpenBMC FW1060.00 through FW1060.80 is affected by a vulnerability in the BMC firmware update process. An attacker with authenticated administrator-level access to the BMC can, under specific conditions, execute arbitrary code, resulting in a confidentiality, integrity, and availability impact.