Total
543 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-8650 | 1 Progress | 1 Moveit Transfer | 2026-10-25 | N/A | 4.5 MEDIUM |
| Relative path traversal vulnerability in Progress MOVEit Transfer (Admin Settings module). This issue affects MOVEit Transfer: before 2025.0.7, from 2025.1.0 before 2025.1.3. | |||||
| CVE-2026-25707 | 1 Opensuse | 1 Libzypp | 2026-10-25 | N/A | 8.8 HIGH |
| A relative path traversal bug problem when processing repository metadata in libzypp before 17.38.10 could be used by remote attackers supplying repositories to overwrite files on the system, leading to denial of service or privilege escalation. | |||||
| CVE-2026-59832 | 2026-10-25 | N/A | 7.7 HIGH | ||
| SiYuan is an open-source personal knowledge management system. Prior to 3.7.1, the /snippets/*filepath route handler serveSnippets in kernel/server/serve.go joins a single-decoded request path with the snippets directory without subpath containment or sensitive-path checks, allowing an authenticated request such as /snippets/%2e%2e/%2e%2e/conf/conf.json to read workspace secrets and the document database. This issue is fixed in versions 3.7.1. | |||||
| CVE-2026-57988 | 1 Microsoft | 1 Edge Chromium | 2026-10-25 | N/A | 7.1 HIGH |
| Relative path traversal in Microsoft Edge (Chromium-based) allows an unauthorized attacker to execute code over a network. | |||||
| CVE-2026-55474 | 1 Snipeitapp | 1 Snipe-it | 2026-10-25 | N/A | 6.5 MEDIUM |
| Snipe-IT is an IT asset/license management system. Prior to 8.5.0, ActionlogController::displaySig concatenates the route filename parameter into a private upload-directory path without sanitization, allowing an authenticated attacker to traverse outside the intended directory and read arbitrary files accessible to the web server process. This issue is fixed in version 8.5.0. | |||||
| CVE-2026-58522 | 2 Google, Microsoft | 2 Android, Edge Chromium | 2026-10-25 | N/A | 6.8 MEDIUM |
| Relative path traversal in Microsoft Edge for Android allows an unauthorized attacker to disclose information locally. | |||||
| CVE-2026-59792 | 1 Jetbrains | 1 Intellij Idea | 2026-10-24 | N/A | 9.6 CRITICAL |
| In JetBrains IntelliJ IDEA before 2026.1.4, 2026.2 code execution via path traversal in project workspace ID handling was possible | |||||
| CVE-2026-14903 | 1 Ivanti | 1 Xtraction | 2026-10-24 | N/A | 7.7 HIGH |
| Path traversal in Ivanti Xtraction before version 2026.2.1 allows a remote authenticated attacker to read arbitrary files outside the web root. | |||||
| CVE-2026-50663 | 1 Microsoft | 1 Age Of Empires Ii | 2026-10-24 | N/A | 8.8 HIGH |
| Relative path traversal in Age of Empires II: Definitive Edition Game allows an unauthorized attacker to execute code over a network. | |||||
| CVE-2026-56196 | 1 Microsoft | 1 Windows Admin Center | 2026-10-24 | N/A | 8.8 HIGH |
| Relative path traversal in Windows Admin Center allows an authorized attacker to execute code over a network. | |||||
| CVE-2026-54910 | 2026-10-24 | N/A | 7.7 HIGH | ||
| FileBrowser Quantum is a free, self-hosted, web-based file manager. Prior to version 1.4.3-beta, the `subtitlesHandler` endpoint (`GET /api/media/subtitles`) accepts two user-controlled query parameters: `path` and `name`, both of which are used in filesystem operations without sanitization, creating two independent path traversal vectors. The primary vector is the `path` parameter: it is passed directly to `idx.GetRealPath()` without calling `SanitizeUserPath()`, allowing an attacker to escape the storage root and set `parentDir` to any directory on the host. No existing anchor file is required. The secondary vector is the `name` parameter: it is joined with `parentDir` via `filepath.Join(parentDir, name)` without stripping directory components, allowing traversal relative to any resolved `parentDir`. Any authenticated user (regardless of role or permissions) can exploit either vector to read any text file readable by the server process, including `/etc/passwd`, SSH keys, database credentials, and JWT signing keys. Version 1.4.3-beta patches the issue. | |||||
| CVE-2026-58413 | 1 Network-ai | 1 Network-ai | 2026-10-24 | N/A | 6.1 MEDIUM |
| Network-AI is a TypeScript/Node.js multi-agent orchestrator. Prior to version 5.12.2, `EnvironmentManager.restore(env, backupId)` computes the backup path with `join(envDir, '.backups', backupId)` and only checks that this path exists. It does not resolve the result or verify that it remains under `data/<env>/.backups`. A caller can pass a traversal backup ID such as `../../../outside/source-dir` to restore files from an arbitrary directory into the target environment data directory. The issue is fixed in v5.12.2. `restore()` now validates `backupId` against `/^[\w\-]+$/` and asserts `dirname(resolve(join(backupsDir, backupId))) === resolve(backupsDir)` before touching the filesystem. Backup IDs containing path separators or `..` are rejected, so a crafted ID can no longer copy directories from outside `.backups/` into the environment. | |||||
| CVE-2026-15415 | 2026-10-24 | N/A | 5.5 MEDIUM | ||
| AWS HealthOmics is a HIPAA-eligible service that fully manages the compute, storage, and workflow engine infrastructure required to run bioinformatics analyses at scale for clinical diagnostics, drug discovery, and agricultural research. Improper limitation of a pathname to a restricted directory in the linting tools of the AWS HealthOmics MCP Server (aws-healthomics-mcp-server) before version 0.0.36 might allow an actor who can influence the MCP agent to write an actor-controlled content to arbitrary locations outside the intended workflow bundle directory, via directory traversal sequences in the workflow_files input. To remediate this issue, users should upgrade to version 0.0.36 or later. | |||||
| CVE-2026-58481 | 1 Network-ai | 1 Network-ai | 2026-10-24 | N/A | 6.5 MEDIUM |
| Network-AI is a TypeScript/Node.js multi-agent orchestrator. Prior to version 5.12.2, `AgentRuntime` promises scoped file access under a configured sandbox `basePath`, but its path containment checks use raw string prefix tests. A sandbox base such as `/tmp/network-ai-sandbox` also matches a sibling path such as `/tmp/network-ai-sandbox_evil/secret.txt`. An agent/user that can call `AgentRuntime.readFile()` or `AgentRuntime.listDir()` can read or list files outside the intended sandbox when the target path is in a sibling directory sharing the base path prefix. This breaks the documented sandbox boundary. The issue is fixed in v5.12.2. `SandboxPolicy.resolvePath()` and `isPathAllowed()` now use separator-anchored prefix checks (`resolved === base || resolved.startsWith(base + path.sep)`) for both the allow-list and block-list. A sibling directory that merely shares a name prefix (e.g. `/srv/app-evil` vs base `/srv/app`) is no longer treated as in-scope. | |||||
| CVE-2026-66897 | 1 Canonical | 1 Lxd | 2026-10-24 | N/A | 9.9 CRITICAL |
| A path traversal vulnerability in LXD's instance template processing allows an attacker with container edit permissions, or any user launching a crafted image, to overwrite arbitrary files on the host system as root. When processing target template paths specified in metadata.yaml, LXD validates the path against a confined os.Root directory handle but subsequently opens and creates the file using os.Create with an unconfined string path. This discrepancy between path resolution checks and file creation allows an attacker to escape directory confinement, overwrite root-owned host files, and achieve host root code execution. | |||||
| CVE-2026-66881 | 1 Livebook | 1 Livebook | 2026-10-24 | N/A | 8.1 HIGH |
| Relative Path Traversal vulnerability in livebook-dev livebook allows an attacker-authored notebook to write a file with attacker-controlled content to an arbitrary path. A .livemd notebook can declare file_entries metadata, each entry carrying a name. Every path that creates a file entry through the user interface validates that name with Livebook.Notebook.validate_file_entry_name/2, which requires a flat filename of alphanumerics, dashes, underscores and dots, ending in an extension. The import path does not: Livebook.LiveMarkdown.Import.file_entry_metadata_to_attrs/1 in lib/livebook/live_markdown/import.ex takes the name verbatim from the notebook source. For a URL-type file entry, Livebook.Session.file_entry_cache_file/2 in lib/livebook/session.ex resolves that name beneath the session's temporary directory without checking that the result stays inside it, and Livebook.FileSystem.Utils.resolve_unix_like_path/2 collapses parent-directory segments while clamping only at the filesystem root. When the entry's content is requested and no cached copy exists, Livebook fetches the entry's URL and writes the response body to the resolved path, creating parent directories as needed. The attacker therefore controls both the destination and the contents of the written file, which may land anywhere the Livebook process can write. The same missing containment check is present in Livebook.Session.to_attachment_file_entry/2. A victim who opens an attacker-supplied notebook and causes the entry to be fetched triggers the write within their own authenticated session; the attacker needs no account on the target instance. URL-type entries are also not placed under notebook stamping quarantine on import, so no warning is shown. This issue affects livebook: from 0.11.0 before 0.18.7 and from 0.19.0 before 0.19.9. | |||||
| CVE-2026-66907 | 1 Apache | 1 Camel | 2026-10-24 | N/A | 7.5 HIGH |
| Relative path traversal vulnerability in Apache Camel Google Storage component. This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-google-storage consumer downloads Google Cloud Storage objects to the local filesystem when the downloadFileName option is set. That option is documented as a folder or a filename, and when its value contains no expression token the consumer builds the local destination by appending the object name to it: evaluateFileExpression sets the Exchange file-name header to the remote object name and evaluates downloadFileName + "/${file:name}". The ${file:name} token returns the file-name header verbatim, unlike ${file:onlyname}, which applies FileUtil.stripPath to it. The resulting string was passed directly to new File(result) and blob.downloadTo(file.toPath()) with no lexical normalization and no check that the destination stayed inside the configured directory. The object name is not route-controlled data: the consumer lists the bucket, iterates every returned blob and creates one exchange per object from blob.getBlobId().getName() verbatim, and the filter option that could restrict those names is not applied at all unless it has been explicitly set. Google Cloud Storage object names are opaque UTF-8 keys that the service stores and lists exactly as written, with no server-side canonicalization, and a forward slash is only a display convention for pseudo-directories, so a key containing parent-directory segments survives round-tripping intact. An object name containing such segments therefore resolved to a location outside the configured downloadFileName directory, letting anyone able to influence the names present in the consumed bucket cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. The downloadFileName option is an ordinary consumer parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. The defect is consumer-only; the producer has no download-to-file sink. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp, camel-azure-files and the Azure Storage download paths - already constrained their local downloads to the configured directory using a path-segment boundary check; camel-google-storage was the remaining object-store download sink not covered by that work. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, set the filter option to a regular expression that accepts only simple single-segment object names, so that any name carrying a path separator or a parent-directory segment is excluded before an exchange is created; note that no filtering whatsoever is applied when the option is left unset, and that the expression is matched against the whole object name. Alternatively, give downloadFileName an explicit expression that does not carry the remote path through, for example one built on ${file:onlyname} rather than the implicit ${file:name}, keeping in mind that a downloadFileName containing an expression is treated as route-author-controlled and is not covered by the containment check added in the fix. As defence in depth, treat the object names in any externally writable bucket as untrusted input and do not derive local filesystem paths from them. | |||||
| CVE-2026-53416 | 2026-10-24 | N/A | 7.1 HIGH | ||
| Path traversal in Zoom VDI Client and Plugins may allow an authenticated user to conduct information disclosure via local access. | |||||
| CVE-2026-41551 | 2026-10-24 | N/A | 9.1 CRITICAL | ||
| A vulnerability has been identified in ROS# (All versions < V2.2.2). Affected versions contain a path traversal vulnerability because user input is not properly sanitized. This could allow a remote attacker to access arbitrary files on the device. | |||||
| CVE-2026-63303 | 2026-10-24 | N/A | N/A | ||
| A Path Traversal vulnerability exists in Quick.CMS through the URI path component of HTTP requests, where the server fails to normalize dot-dot-slash (../) sequences before resolving and serving the requested file. An authenticated attacker with admin privileges can use this vulnerability to read contents of files located in the sibling directory of the webroot via a crafted HTTP request containing ../ sequences in the URI. The vendor assessed the likelihood of exploitation as very low and determined that a fix is not necessary. | |||||