CWE-41

Windows HTML Platforms Security Feature Bypass Vulnerability

Improper resolution of path equivalence in Windows MapUrlToZone allows an unauthorized attacker to bypass a security feature over a network.

MapUrlToZone Security Feature Bypass Vulnerability

MapUrlToZone Security Feature Bypass Vulnerability

Windows Deployment Services Information Disclosure Vulnerability

MapUrlToZone Security Feature Bypass Vulnerability

Windows Compressed Folder Remote Code Execution Vulnerability

MapUrlToZone Security Feature Bypass Vulnerability

MapUrlToZone Security Feature Bypass Vulnerability

MapUrlToZone Security Feature Bypass Vulnerability

An Improper Resolution of Path Equivalence vulnerability [CWE-41] in FortiPortal 7.4.0 through 7.4.2, 7.2.0 through 7.2.6, 7.0.0 through 7.0.11 may allow a remote unauthenticated attacker to retrieve source code via crafted HTTP requests.

Improper resolution of path equivalence in Windows MapUrlToZone allows an unauthorized attacker to bypass a security feature over a network.

Improper Resolution of Path Equivalence in GitHub repository microweber-dev/whmcs_plugin prior to 0.0.4.

Windows Security Zone Mapping Security Feature Bypass Vulnerability

Improper resolution of path equivalence in Windows MapUrlToZone allows an unauthorized attacker to bypass a security feature over a network.

In lunary-ai/lunary, the privilege check mechanism is flawed in version git afc5df4. The system incorrectly identifies certain endpoints as public if the path contains '/auth/' anywhere within it. This allows unauthenticated attackers to access sensitive endpoints by including '/auth/' in the path. As a result, attackers can obtain and modify sensitive data and utilize other organizations' resources without proper authentication.

corydolphin/flask-cors version 4.0.1 contains an improper regex path matching vulnerability. The plugin prioritizes longer regex patterns over more specific ones when matching paths, which can lead to less restrictive CORS policies being applied to sensitive endpoints. This mismatch in regex pattern priority allows unauthorized cross-origin access to sensitive data or functionality, potentially exposing confidential information and increasing the risk of unauthorized actions by malicious actors.

A vulnerability in the gradio-app/gradio repository, version git 67e4044, allows for path traversal on Windows OS. The implementation of the blocked_path functionality, which is intended to disallow users from reading certain files, is flawed. Specifically, while the application correctly blocks access to paths like 'C:/tmp/secret.txt', it fails to block access when using NTFS Alternate Data Streams (ADS) syntax, such as 'C:/tmp/secret.txt::$DATA'. This flaw can lead to unauthorized reading of blocked file paths.

IBM DS8900F HMC 89.21.19.0, 89.21.31.0, 89.30.68.0, 89.32.40.0, and 89.33.48.0 could allow an authenticated user to arbitrarily delete a file. IBM X-Force ID: 269406.

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.10 before 18.10.4 and 18.11 before 18.11.1 that could have allowed an unauthenticated user to execute arbitrary JavaScript in a user's browser session due to improper path validation under certain conditions.

OpenClaw before 2026.3.22 contains a path traversal vulnerability in Windows media loaders that accepts remote-host file URLs and UNC-style paths before local-path validation. Attackers can exploit this by providing network-hosted file targets that are treated as local content, bypassing intended access restrictions.

Claude SDK for TypeScript provides access to the Claude API from server-side TypeScript or JavaScript applications. From version 0.79.0 to before version 0.81.0, the local filesystem memory tool in the Anthropic TypeScript SDK validated model-supplied paths using a string prefix check that did not append a trailing path separator. A model steered by prompt injection could supply a crafted path that resolved to a sibling directory sharing the memory root's name as a prefix, allowing reads and writes outside the sandboxed memory directory. This issue has been patched in version 0.81.0.

`gix-path` is a crate of the `gitoxide` project (an implementation of `git` written in Rust) dealing paths and their conversions. Prior to version 0.10.11, `gix-path` runs `git` to find the path of a configuration file associated with the `git` installation, but improperly resolves paths containing unusual or non-ASCII characters, in rare cases enabling a local attacker to inject configuration leading to code execution. Version 0.10.11 contains a patch for the issue. In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` to find the path of a file to treat as belonging to the `git` installation. Affected versions of `gix-path` do not pass `-z`/`--null` to cause `git` to report literal paths. Instead, to cover the occasional case that `git` outputs a quoted path, they attempt to parse the path by stripping the quotation marks. The problem is that, when a path is quoted, it may change in substantial ways beyond the concatenation of quotation marks. If not reversed, these changes can result in another valid path that is not equivalent to the original. On a single-user system, it is not possible to exploit this, unless `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` have been set to unusual values or Git has been installed in an unusual way. Such a scenario is not expected. Exploitation is unlikely even on a multi-user system, though it is plausible in some uncommon configurations or use cases. In general, exploitation is more likely to succeed if users are expected to install `git` themselves, and are likely to do so in predictable locations; locations where `git` is installed, whether due to usernames in their paths or otherwise, contain characters that `git` quotes by default in paths, such as non-English letters and accented letters; a custom `system`-scope configuration file is specified with the `GIT_CONFIG_SYSTEM` environment variable, and its path is in an unusual location or has strangely named components; or a `system`-scope configuration file is absent, empty, or suppressed by means other than `GIT_CONFIG_NOSYSTEM`. Currently, `gix-path` can treat a `global`-scope configuration file as belonging to the installation if no higher scope configuration file is available. This increases the likelihood of exploitation even on a system where `git` is installed system-wide in an ordinary way. However, exploitation is expected to be very difficult even under any combination of those factors.

A parsing issue in the handling of directory paths was addressed with improved path validation. This issue is fixed in macOS Sequoia 15.7, macOS Sonoma 14.8, macOS Tahoe 26. An app may be able to gain root privileges.

A vulnerability in the Palo Alto Networks PAN-OS software enables an authenticated admin on the PAN-OS CLI to read arbitrary files. The attacker must have network access to the management interface (web, SSH, console, or telnet) and successfully authenticate to exploit this issue. You can greatly reduce the risk of this issue by restricting access to the management interface to only trusted users and internal IP addresses according to our recommended critical deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 . This issue does not affect Cloud NGFW or Prisma Access.

Fission is an open-source, Kubernetes-native serverless framework that simplifies the deployment of functions and applications on Kubernetes. Prior to version 1.25.0, SanitizeFilePath in pkg/utils/utils.go validated that a path stayed under a safe directory by calling strings.HasPrefix(path, safedir). This is a lexical check, not a directory boundary check: /packages-extra/evil starts with /packages, so it passed. The function did not enforce a path-separator boundary, so any sibling directory whose name began with the safe-directory string was accepted. Callers included the builder's Clean handler (pkg/builder/builder.go:208) and the fetcher's Fetch / Upload handlers (pkg/fetcher/fetcher.go). A tenant who could pre-create or control a sibling directory under the fetcher / builder's shared volume could induce a write or read outside the intended safe directory. This issue has been patched in version 1.25.0.

Denial of service (DoS) vulnerability in the office service. Successful exploitation of this vulnerability may affect availability.

## Summary Deno's permission system enforces filesystem and execution restrictions by comparing the requested path against the path supplied to `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi`. On macOS, that comparison was done at the raw-byte level while the APFS filesystem treats different Unicode spellings of the same name as the same file. That means a program could reach a denied path by spelling it differently than the deny rule. For example, with `--deny-read=/secrets/passwörter.txt`, a script could still read the file by opening `/secrets/passwo\u0308rter.txt` (NFD instead of NFC), or `/SECRETS/PASSWÖRTER.txt` (different case, since default APFS volumes are case-insensitive). Other forms include ligature characters (`fi` vs `fi`, `ff` vs `ff`, …) and German `ß` vs `ss`. The denied path and the requested path differed at the byte level, so Deno's permission check passed; the kernel then resolved them to the same inode and served the file anyway. The same flaw affected `--deny-write`, `--deny-run`, and `--deny-ffi`, which share the same path-comparison code. ## Am I affected? You are potentially affected if **all** of the following are true: 1. You run Deno on **macOS** (the issue is specific to APFS path-equivalence rules; Linux and Windows are not affected by this variant). 2. You rely on `--deny-read`, `--deny-write`, `--deny-run`, or `--deny-ffi` as a security boundary against less-trusted code — a dependency, plugin, or attacker-controlled input. 3. The protected path contains characters that have alternate Unicode spellings — most commonly accented characters (`é`, `ñ`, `ö`, …), German `ß`, or Latin ligatures — or you rely on case-sensitivity on a default APFS volume. If you only run fully trusted code, or your deny rules cover paths that are pure ASCII with no case-sensitive aliases, you are not exposed to this specific bypass. ## Impact A program running with broad `--allow-read` (or `--allow-write` / `--allow-run` / `--allow-ffi`) but with `--deny-*` carve-outs for specific paths could read, write, execute, or load via FFI those denied paths by referring to them through a Unicode- or case-equivalent spelling. The sandbox model on macOS was weaker than the flags suggested. ## Workaround If you cannot upgrade immediately: - Prefer `--allow-*` allowlists over `--deny-*` denylists. Allow rules match against the original specifier, so an attacker-supplied alternate spelling will not match a path you didn't explicitly grant. - Do not rely on case-sensitivity of paths on macOS for security boundaries; default APFS volumes are case-insensitive. ## Fix On macOS, Deno now normalizes both the deny-rule path and the requested path to NFC and applies Unicode case folding before comparing them. This matches how APFS resolves paths at the inode level, so byte-different but equivalent spellings are now rejected by the same deny rule.