| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A potential improper file path validation vulnerability was reported in some Lenovo Personal Cloud Storage devices that could allow a remote authenticated user to move or access files belonging to other users on the same device. |
| i18next-fs-backend is a backend layer for i18next using in Node.js and for Deno to load translations from the filesystem. Prior to version 2.6.4, i18next-fs-backend substitutes the lng and ns options directly into the configured loadPath / addPath templates and then read / write the resulting file from disk. The interpolation is unencoded and unvalidated, so a crafted lng or ns value — containing .., a path separator, a control character, a prototype key, or simply an unexpectedly long string — allows an attacker who can influence either value to read or overwrite files outside the intended locale directory. When lng / ns are derived from untrusted input (request-scoped i18next instances behind an HTTP layer such as i18next-http-middleware, or any framework that lets the end user pick the language via query string, cookie, or header), a single request such as ?lng=../../../../etc/passwd causes the backend to attempt to read that path. This issue has been patched in version 2.6.4. |
| An authenticated iControl REST user with low privileges can create or modify arbitrary files through an undisclosed iControl REST endpoint on the BIG-IQ system.
Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. |
| If `shutil.unpack_archive()` is given a ZIP archive with an absolute Windows path containing a drive (`C:\\...`) then the archive will be extracted outside the target directory which is different than other operating systems. Only Windows is affected by this vulnerability. |
| AGiXT is a dynamic AI Agent Automation Platform. Prior to 1.9.2, the safe_join() function in the essential_abilities extension fails to validate that resolved file paths remain within the designated agent workspace. An authenticated attacker can use directory traversal sequences to read, write, or delete arbitrary files on the server hosting the AGiXT instance. This vulnerability is fixed in 1.9.2. |
| django-s3file is a lightweight file upload input for Django and Amazon S3. Prior to 7.0.2, S3FileMiddleware is vulnerable to relative path traversal attacks, where an attacker can use a modified request to escape pre-signed upload locations and have the Django application load files from random locations into request.FILES. Depending on how files are handled, this may lead to confidentiality and integrity issues. This vulnerability is fixed in 7.0.2. |
| Mako is a template library written in Python. Prior to 1.3.12, on Windows, a URI using backslash traversal (e.g. \..\..\ secret.txt) bypasses the directory traversal check in Template.__init__ and the posixpath-based normalization in TemplateLookup.get_template(), allowing reads of files outside the configured template directory. This vulnerability is fixed in 1.3.12. |
| Wireshark MCP is an MCP Server that turns tshark into a structured analysis interface, then layers in optional Wireshark suite utilities. In 1.1.5 and earlier, wireshark-mcp exposes a wireshark_export_objects MCP tool that accepts an attacker-controlled dest_dir parameter and passes it to tshark's --export-objects flag with no mandatory path restriction. The path sandbox (_allowed_dirs) is None by default and only activates when the environment variable WIRESHARK_MCP_ALLOWED_DIRS is explicitly set. In a default installation, any directory on the filesystem can be used as the export destination. |
| Adobe Commerce versions 2.4.9-beta1, 2.4.8-p4, 2.4.7-p9, 2.4.6-p14, 2.4.5-p16, 2.4.4-p17 and earlier are affected by an Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability that could result in arbitrary file system read and write. An authenticated attacker with administrative privileges could exploit this vulnerability to read or write files outside the restricted directory. Exploitation of this issue does not require user interaction. Scope is changed. |
| oxyno-zeta/s3-proxy is an aws s3 proxy written in go. Prior to 5.0.0, s3-proxy contains an authentication bypass caused by inconsistent URL path interpretation between the authentication middleware and the bucket handler. The authentication middleware evaluates resource path patterns against the percent-encoded request URI (r.URL.RequestURI()), while the bucket handler constructs S3 object keys from the decoded path (r.URL.Path). This mismatch, combined with the glob library being invoked without a path separator (causing * to match across / boundaries), allows unauthenticated attackers to write to, read from, or delete objects in protected S3 namespaces. Exploitation is possible via three techniques: (1) using * patterns
that match across path separators to reach protected routes via path traversal (e.g., /open/foo/drafts/../restricted/), (2) using percent-encoded slashes (%2F) to collapse multiple path segments into a single token at the auth layer while the decoded form resolves to a protected namespace at the storage layer, and (3) using dot-dot segments (../) under ** prefix patterns, where the raw path matches an open route while Go's URL parser resolves the traversal to a protected path before the bucket handler runs. An unauthenticated attacker with network access can perform unauthorized PUT, GET, or DELETE operations on objects in authentication-protected S3 namespaces. This vulnerability is fixed in 5.0.0. |
| Hugo is a static site generator. From 0.43 to before 0.161.0, when building a Hugo site that uses Node-based asset pipelines (PostCSS, Babel, TailwindCSS), Hugo invoked the configured Node tools without restrictions on file system access. As a result, executing hugo against an untrusted site could allow code running through these tools to read or write files outside the project's working directory. Users who do not use PostCSS, Babel, or TailwindCSS, or who only build trusted sites, are not affected. This vulnerability is fixed in 0.161.0. |
| CWE-22: Improper Limitation of a Pathname to a Restricted Directory (“Path Traversal”) vulnerability that could cause unauthorized access to sensitive files when user-supplied input is improperly handled during server-side file path processing. |
| HashiCorp Nomad and Nomad Enterprise prior to 2.0.1 are vulnerable to code execution on the client host through a path traversal attack. This vulnerability (CVE-2026-7474) is fixed in Nomad 2.0.1, 1.11.5 and 1.10.11. |
| docuFORM Managed Print Service Client 11.11c is vulnerable to a directory traversal allowing attackers to read arbitrary files via crafted url. |
| Ruijie Networks Switch eWeb S29_RGOS 11.4 contains a directory traversal vulnerability that allows unauthenticated attackers to access sensitive configuration files by manipulating file path parameters. Attackers can exploit the /download.do endpoint with '../' sequences to retrieve system configuration files containing credentials and network settings. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware_loader: Block path traversal
Most firmware names are hardcoded strings, or are constructed from fairly
constrained format strings where the dynamic parts are just some hex
numbers or such.
However, there are a couple codepaths in the kernel where firmware file
names contain string components that are passed through from a device or
semi-privileged userspace; the ones I could find (not counting interfaces
that require root privileges) are:
- lpfc_sli4_request_firmware_update() seems to construct the firmware
filename from "ModelName", a string that was previously parsed out of
some descriptor ("Vital Product Data") in lpfc_fill_vpd()
- nfp_net_fw_find() seems to construct a firmware filename from a model
name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I
think parses some descriptor that was read from the device.
(But this case likely isn't exploitable because the format string looks
like "netronome/nic_%s", and there shouldn't be any *folders* starting
with "netronome/nic_". The previous case was different because there,
the "%s" is *at the start* of the format string.)
- module_flash_fw_schedule() is reachable from the
ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as
GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is
enough to pass the privilege check), and takes a userspace-provided
firmware name.
(But I think to reach this case, you need to have CAP_NET_ADMIN over a
network namespace that a special kind of ethernet device is mapped into,
so I think this is not a viable attack path in practice.)
Fix it by rejecting any firmware names containing ".." path components.
For what it's worth, I went looking and haven't found any USB device
drivers that use the firmware loader dangerously. |
| fast-uri decoded percent-encoded path separators and dot segments before applying dot-segment removal in its normalize() and equal() functions. Encoded path data was treated like real slashes and parent-directory references, so distinct URIs could collapse onto the same normalized path. Applications that normalize or compare attacker-controlled URLs to enforce path-based policy can be bypassed, with a path that appears confined under an allowed prefix normalizing to a different location. Versions <= 3.1.0 are affected. Update to 3.1.1 or later. |
| SolidCAM-GPPL-IDE is an unofficial, independently developed extension, Postprocessor IDE for SolidCAM. From version 1.0.0 to before version 1.0.2, the inc "filename" directive in GPPL postprocessor files is resolved by GpplDocumentLinkHandler into a clickable link (VS Code textDocument/documentLink). The handler accepted arbitrary paths — absolute, relative with parent-directory segments (..\..\..\), UNC (\\server\share\), and arbitrary subfolders — and called File.Exists on each to decide whether to render the link. Two distinct attack surfaces resulted: information disclosure via File.Exists probing and NTLM hash leak via UNC path probing. This issue has been patched in version 1.0.2. |
| Spring Cloud Config allows applications to serve arbitrary text and binary files through the spring-cloud-config-server module. A malicious user, or attacker, can send a request using a specially crafted URL that can lead to a directory traversal attack.
Spring Cloud Config 3.1.x: affected from 3.1.0 through 3.1.13 (inclusive); upgrade to 3.1.14 or greater (Enterprise Support Only). Spring Cloud Config 4.1.x: affected from 4.1.0 through 4.1.9 (inclusive); upgrade to 4.1.10 or greater (Enterprise Support Only). Spring Cloud Config 4.2.x: affected from 4.2.0 through 4.2.6 (inclusive); upgrade to 4.2.7 or greater (Enterprise Support Only). Spring Cloud Config 4.3.x: affected from 4.3.0 through 4.3.2 (inclusive); upgrade to 4.3.3 or greater. Spring Cloud Config 5.0.x: affected from 5.0.0 through 5.0.2 (inclusive); upgrade to 5.0.3 or greater. |
| jotty·page is a self-hosted app for your checklists and notes. Prior to 1.22.0, an unauthenticated path traversal vulnerability exists in /api/app-icons/[filename]. The filename route parameter is joined into a filesystem path without traversal/boundary validation, allowing file reads outside data/uploads/app-icons/. This vulnerability is fixed in 1.22.0. |
