Yggdrasil-worker-package-manager: yggdrasil-worker-package-manager: path traversal via unsanitized repo name in addrepo/removerepo

A flaw was found in yggdrasil-worker-package-manager. An authenticated attacker can exploit this issue to achieve arbitrary file modification or potential privilege escalation. The vulnerability exists because repository management operations fail to sanitize directory traversal sequences (such as '../') within repository names. By supplying a crafted repository name, an attacker can manipulate the root-level worker process into creating or deleting files outside the intended directory, compromising host system integrity.

MLflow < 3.18.0 Path Traversal via model_id in log_outputs API

MLflow before 3.18.0 using the FileStore backend contains a path traversal vulnerability that allows unauthenticated remote attackers to write files outside the intended run directory by supplying a malicious model_id parameter to the log outputs API. Attackers can exploit the unvalidated model_id containing ../ sequences via the POST /api/3.0/mlflow/runs/outputs endpoint to create directories and write a meta.yaml file at arbitrary filesystem locations, limited only by the server account's permissions. FileStore was the default backend before 3.7.0 and is opt-in afterward through MLFLOW_ALLOW_FILE_STORE.

Arbitrary File Read/Write via Path Traversal in Synology DiskStation Manager Sharing API

An improper limitation of a pathname to a restricted directory vulnerability in the Sharing API in Synology DiskStation Manager (DSM) before 7.3.2-86009-5 and 7.4.1-90080-1 allows remote authenticated users to read or write arbitrary files and conduct denial-of-service attacks.

Backup Migration before 2.1.8 Path Traversal via PclZip Restore Fallback

Backup Migration before 2.1.8 for WordPress contains a path traversal vulnerability in its PclZip restore fallback that allows an attacker to achieve arbitrary file write when an administrator restores a malicious backup archive on a server lacking the PHP zip extension. Attackers can craft a zip archive with entry names containing ".." sequences, which PclZip's extract() processes without the PCLZIP_OPT_EXTRACT_DIR_RESTRICTION option, writing a PHP file outside the intended extraction directory into the web-servable tree to achieve remote code execution.

Authenticated path traversal allows arbitrary file writes via crafted archive

A improper limitation of a pathname to a restricted directory ('path traversal') vulnerability in Fortinet FortiAnalyzer 8.0.0 through 8.0.1, FortiAnalyzer 7.6.2 through 7.6.7, FortiAnalyzer 7.4.7 through 7.4.11, FortiAnalyzer 7.2.10 through 7.2.12, FortiAnalyzer Cloud 8.0.0 through 8.0.1, FortiAnalyzer Cloud 7.6.0 through 7.6.7, FortiAnalyzer Cloud 7.4.1 through 7.4.11, FortiAnalyzer Cloud 7.2.1 through 7.2.12, FortiManager 8.0.0 through 8.0.1, FortiManager 7.6.2 through 7.6.7, FortiManager 7.4.7 through 7.4.11, FortiManager 7.2.10 through 7.2.12, FortiManager Cloud 8.0.0 through 8.0.1, FortiManager Cloud 7.6.0 through 7.6.7, FortiManager Cloud 7.4.1 through 7.4.11, FortiManager Cloud 7.2.1 through 7.2.12 may allow an authenticated administrator to write arbitrary files via a specially crafted archive.

Path Traversal Vulnerability Allowing Unauthorized Code Execution in Fortinet FortiManager and FortiAnalyzer

A improper limitation of a pathname to a restricted directory ('path traversal') vulnerability in Fortinet FortiAnalyzer 8.0.0 through 8.0.1, FortiAnalyzer 7.6.3 through 7.6.7, FortiAnalyzer Cloud 8.0.0 through 8.0.1, FortiAnalyzer Cloud 7.6.3 through 7.6.7, FortiManager 8.0.0 through 8.0.1, FortiManager 7.6.3 through 7.6.7, FortiManager Cloud 8.0.0 through 8.0.1, FortiManager Cloud 7.6.3 through 7.6.7 may allow an authenticated attacker with admin privileges to execute unauthorized code or commands via crafted requests.

An improper limitation of a pathname to a restricted directory ('path traversal') vulnerability in Fortinet FortiAnalyzer 7.6.0 through 7.6.4, FortiAnalyzer 7.4.0 through 7.4.7, FortiAnalyzer 7.2.0 through 7.2.11, FortiManager 7.6.0 through 7.6.4, FortiManager 7.4.0 through 7.4.7, FortiManager 7.2.0 through 7.2.11, FortiManager Cloud 7.6.0 through 7.6.4, FortiManager Cloud 7.4.1 through 7.4.7, FortiManager Cloud 7.2.1 through 7.2.10 may allow an authenticated attacker whose profile only has read permission to write and delete files from the underlying filesystem via crafted HTTP or HTTPs requests.

AES key schedule not cleared by the TinyCrypt AES-CTR backend in MCUboot bootutil

When MCUboot is built with the TinyCrypt crypto backend (MCUBOOT_USE_TINYCRYPT), bootutil_aes_ctr_drop() in boot/bootutil/include/bootutil/crypto/aes_ctr_tinycrypt.h was an empty stub. The AES-CTR context for this backend is the fully expanded AES-128 key schedule (struct tc_aes_key_sched_struct). Generic code relies on this hook to release and clear key state, so with TinyCrypt nothing was cleared. The mbedTLS and PSA backends do free or destroy their key state here. As a result, boot_state_clear(), which boot_go() calls before handing off to the application, left the image's AES content-encryption key schedule in the static boot_data state. This is the case after an encrypted upgrade in single-image builds, where boot_enc_zeroize() is not called. boot_decrypt_key() likewise left the ECIES-derived key-encryption key schedule on the stack. The affected build uses MCUBOOT_ENC_IMAGES with TinyCrypt, which is the default ECDSA and Ed25519 backend in the Zephyr port. The first AES-128 round key equals the cipher key, so anyone who can read the leftover bootloader RAM after boot can recover the image content key and decrypt that encrypted image. That includes a physical attacker with debug or RAM access, or code later running on the device. This weakens image-encryption key confidentiality (and so the confidentiality of the encrypted image's plaintext). The device's long-term private decryption key is not exposed, and image authenticity is not affected. The fix wipes the context with bootutil_wipe_memory().

AES image key left on the stack after serial-recovery encrypted-image handling in MCUboot

In MCUboot's serial-recovery encrypted-image support (boot/boot_serial/src/boot_serial_encryption.c), decrypt_image_inplace() and boot_image_validate_encrypted() each keep a stack-local struct boot_status. boot_enc_load() writes the plaintext per-image AES key into its enckey[] field. Neither function cleared this structure before returning. In addition, a decrypt failure inside the per-sector loop of decrypt_image_inplace() returned early and skipped the total_out: cleanup, which left the expanded AES key context (enc_data) on the stack as well. The error paths of boot_image_validate_encrypted() similarly skipped boot_enc_zeroize(). The affected code is built when encrypted images (MCUBOOT_ENC_IMAGES, Zephyr CONFIG_BOOT_ENCRYPT_IMAGE) are combined with serial recovery. It runs when an encrypted image is uploaded to the primary slot over the recovery protocol, and when the image list or state is queried while an encrypted image is in the secondary slot. After these functions return, the image's AES content key remains in dead stack memory. An attacker who can later read device RAM, for example through a debug port or retained RAM, can recover it. This weakens the confidentiality of image-encryption keys within the bootloader trust boundary. A recovered key exposes the plaintext of the encrypted firmware image it protects. The device's long-term private decryption key is not exposed. No remote or recovery-protocol channel that returns this memory is known, so exploitation requires a separate memory-read capability.

Pulpcore: pulpcore: file:// scheme allowlist bypass in content upload file_url field enables arbitrary file read and pulp container registry signing key theft

A path traversal vulnerability was found in pulpcore. The content upload API accepts a 'file_url' parameter that allows users with file repository privileges to specify a local file URL for Pulp to download and store. A URL scheme validation check uses a string prefix comparison that only rejects URLs beginning with 'file://', but Python's URL parser recognizes the 'file:' scheme without double slashes, creating a mismatch between what is validated and what is dispatched to the file downloader. An authenticated user with low-privilege repository permissions can supply a specially crafted URL using relative path traversal sequences to read any file accessible to the Pulp server process. In deployments that include Pulp Container, successful exploitation allows an attacker to read the container registry token signing private key and forge bearer tokens, granting unauthorized access to all private container repositories in the affected registry.

Pulp-rpm: distribution tree publish creates directories from .treeinfo ids

A flaw was found in pulp-rpm when it publishes a distribution tree. Addon and variant ids from .treeinfo are used as directory names. A user who can sync or upload that tree can make the publish task create a new directory outside the task work area and write that tree's repository metadata and packages there, as the Pulp worker user. An existing file or directory is not replaced. The flaw does not disclose data and does not stop the service.

Astro: Image endpoint in @astrojs/node can read files from a case-variant sibling of the output directory on case-sensitive filesystems

Astro is a web framework for content-driven websites. From 5.14.3 until 7.4.7, Astro's /_image endpoint compared the requested local-image path with the build output directory without preserving case on case-sensitive filesystems. A sibling directory whose path differed from the output directory only by letter case could therefore pass the containment check, allowing an unauthenticated requester to read image files accepted by the image service from outside the output directory. Exploitation required on-demand rendering with the @astrojs/node adapter, a case-sensitive filesystem, and a preexisting case-variant sibling directory; ordinary traversal to unrelated paths was already rejected. This issue is fixed in Astro version 7.4.7.

Openscap: openscap: arbitrary file write via path traversal in source datastream decomposition

A flaw was found in OpenSCAP. When decomposing a Source DataStream (SDS) file, the application does not properly validate relative file path attributes, leading to a path traversal vulnerability. An attacker can exploit this flaw by tricking a user or automated system into decomposing a crafted datastream containing directory traversal sequences. Successful exploitation allows unauthorized file creation or modification outside the intended target directory with the permissions of the executing process.

Addressable URI normalization resolves some dotted path segments to the wrong path

Addressable is an alternative implementation to the URI implementation that is part of Ruby's standard library. From 2.2.5 until 2.9.1, Addressable::URI.normalize_path can resolve a path containing leading parent segments and later parent segments to a different path than an RFC 3986 resolver. URI#normalize, URI#join, URI#==, and URI#=== inherit the result. An application that authorizes the Addressable-normalized path but sends the original URI to another resolver can allow access outside the intended path allowlist. Applications that use the same normalized value for authorization and the request, or reject parent segments, are unaffected. This issue is fixed in version 2.9.1.

CAI Content Credentials | Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (CWE-22)

CAI Content Credential is affected by an Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability that could result in an arbitrary file system write. An attacker could leverage this vulnerability to write to unauthorized files or directories outside of intended restrictions. Exploitation of this issue requires user interaction in that a victim must extract a maliciously crafted file.

CAI Content Credentials | Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (CWE-22)

CAI Content Credentials is affected by an Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability that could result in a Security feature bypass. An attacker could leverage this vulnerability to access unauthorized files or directories outside the intended restrictions. Exploitation of this issue requires user interaction in that a victim must visit a maliciously crafted URL or interact with a compromised web page.

Xiaomi Mi Browser < 14.66.0 Path Traversal via ThirdDocViewerActivity

Xiaomi Mi Browser Android Application (com.mi.globalbrowser) before 14.66.0-gn contains a path traversal vulnerability in the exported ThirdDocViewerActivity component, where CopyExternalFile.copyFromUri() copies content provider streams using an unsanitized filename from the _display_name column without basename reduction or canonical-path checks. A zero-permission co-resident malicious application can supply a crafted content provider with a _display_name containing .. sequences to make the browser write attacker-controlled bytes to an arbitrary path within its external storage directory, escaping the intended cache_docs staging location without requiring user interaction.

Bulk Media Register < 2.01 - Author+ Arbitrary File Move via Path Traversal

The Bulk Media Register WordPress plugin before 2.01 does not properly validate a user-supplied path before moving a file on the server, allowing users with the Author role to move or rename arbitrary files, including outside the WordPress root, which can defeat directory-level access controls and disclose protected files.

Path Traversal (Tar Slip) in Lenovo XClarity OneCLI 5.5.0 Linux

A path traversal vulnerability in the TAR.GZ extraction logic of Lenovo XClarity Essentials OneCLI 5.5.0 for Linux could allow an attacker to write arbitrary files with the privileges of the OneCLI process by convincing a user to process a specially crafted TAR.GZ update package.

Vanquish Upload Files for WooCommerce <= 2.7.13 - Unauthenticated Arbitrary File Read via 'vanupfi_file_name' Parameter

The Vanquish Upload Files for WooCommerce plugin for WordPress is vulnerable to Directory Traversal in all versions up to, and including, 2.7.13 via the 'vanupfi_file_name' parameter parameter. This makes it possible for authenticated attackers, with subscriber-level access and above, to read the contents of arbitrary files on the server, which can contain sensitive information. The authorization bypass is achieved by supplying a non-existent order ID (e.g., '.pdf'), which causes wc_get_order() to return false and short-circuits the vanupfi_user_can_access_order_files() check, while the is_pdf() branch selector's loose strpos() substring match allows a traversal payload such as '../.pdf/../../../../wp-config.php' to satisfy the PDF branch and be streamed verbatim via readfile().