CWE-41
AllowedImproper Resolution of Path Equivalence
Abstraction: Base · Status: Incomplete
The product is vulnerable to file system contents disclosure through path equivalence. Path equivalence involves the use of special characters in file and directory names. The associated manipulations are intended to generate multiple names for the same object.
53 vulnerabilities reference this CWE, most recent first.
GHSA-GJ6X-VQPX-4P3C
Vulnerability from github – Published: 2026-04-22 18:31 – Updated: 2026-04-22 18:31GitLab 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.
{
"affected": [],
"aliases": [
"CVE-2026-5816"
],
"database_specific": {
"cwe_ids": [
"CWE-41"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T17:16:44Z",
"severity": "HIGH"
},
"details": "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\u0027s browser session due to improper path validation under certain conditions.",
"id": "GHSA-gj6x-vqpx-4p3c",
"modified": "2026-04-22T18:31:47Z",
"published": "2026-04-22T18:31:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5816"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3572231"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/04/22/patch-release-gitlab-18-11-1-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/592816"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J99Q-93C9-H869
Vulnerability from github – Published: 2026-06-18 14:30 – Updated: 2026-06-18 14:30On case-insensitive filesystems (macOS, Windows), PathFilter compiled its deny-list patterns case-sensitively and matched the path verbatim, so names like .Git/config, .GIT/config, or .oBsIdIaN/secrets.md slipped past the .git/.obsidian/node_modules restriction while the OS opened the real file. On Windows, trailing dots/spaces (.git./config, .git /config) bypassed it the same way. Affects both isAllowed (read/write/move/search) and isAllowedForListing. Vault-root .. containment is NOT affected. Fixed in 0.11.4 by case-insensitive matching plus per-segment canonicalization before the deny-list check. Reported privately by novice-22.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@bitbonsai/mcpvault"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.11.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-41"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:30:43Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "On case-insensitive filesystems (macOS, Windows), PathFilter compiled its deny-list patterns case-sensitively and matched the path verbatim, so names like `.Git/config`, `.GIT/config`, or `.oBsIdIaN/secrets.md` slipped past the `.git`/`.obsidian`/`node_modules` restriction while the OS opened the real file. On Windows, trailing dots/spaces (`.git./config`, `.git /config`) bypassed it the same way. Affects both `isAllowed` (read/write/move/search) and `isAllowedForListing`. Vault-root `..` containment is NOT affected. Fixed in 0.11.4 by case-insensitive matching plus per-segment canonicalization before the deny-list check. Reported privately by novice-22.",
"id": "GHSA-j99q-93c9-h869",
"modified": "2026-06-18T14:30:43Z",
"published": "2026-06-18T14:30:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/bitbonsai/mcpvault/security/advisories/GHSA-j99q-93c9-h869"
},
{
"type": "PACKAGE",
"url": "https://github.com/bitbonsai/mcpvault"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCPVault: PathFilter restricted-directory deny-list bypass via case and trailing dot/space equivalence"
}
GHSA-JF83-84H5-5CC4
Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2025-01-14 18:32Windows HTML Platforms Security Feature Bypass Vulnerability
{
"affected": [],
"aliases": [
"CVE-2025-21269"
],
"database_specific": {
"cwe_ids": [
"CWE-41"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T18:15:46Z",
"severity": "MODERATE"
},
"details": "Windows HTML Platforms Security Feature Bypass Vulnerability",
"id": "GHSA-jf83-84h5-5cc4",
"modified": "2025-01-14T18:32:03Z",
"published": "2025-01-14T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21269"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21269"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-M8RP-VV92-46C7
Vulnerability from github – Published: 2024-09-06 19:55 – Updated: 2024-09-18 22:48Summary
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.
Details
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 (650a1b5). Instead, to cover the occasional case that git outputs a quoted path, they attempt to parse the path by stripping the quotation marks:
https://github.com/Byron/gitoxide/blob/1cfe577d461293879e91538dbc4bbfe01722e1e8/gix-path/src/env/git/mod.rs#L138-L142
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.
This is not limited to paths with unusual characters such as quotation marks or newlines. Unless git is explicitly configured with core.quotePath set to false, it also happens when the path contains most non-ASCII characters, including accented or non-English letters. For example, é is transformed to \303\251, with literal backslashes. (This is an octal representation of the bytes in its UTF-8 encoding. This behavior is not limited to systems that encode paths with UTF-8 on disk.)
Rarely, the configuration file gix-path wrongly attempts to open can be created by an attacker who has a limited user account on the system. The attacker would often need to request an account username tailored to carrying out the attack.
PoC
Quick demonstration on Unix
On a Unix-like system in which Git supports no higher scope than system for configuration variables (i.e., not on macOS with Apple Git), in a locale that supports UTF-8, with gitoxide installed, run:
mkdir myrepo
cd myrepo
git init
printf '[real]\n\trealvar = realval\n' > 'é'
printf '[fake]\n\tfakevar = fakeval\n' > '\303\251'
GIT_CONFIG_SYSTEM='é' gix config
If the above conditions are satisfied and the gix command was built against an affected version of gix-path, then the last command's output looks something like this:
# From '\303\251' (GitInstallation)
[fake]
fakevar = fakeval
# From 'é' (System)
[real]
realvar = realval
# From '/home/ubuntu/.gitconfig' (User)
[init]
defaultBranch = main
# From './.git/config' (Local)
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
```
#### Demonstration across user accounts on Windows
On a test system running Windows on which Git for Windows is *not* installed system-wide—resembling a scenario in which users who wish to use Git are expected to install it themselves for their accounts—create two accounts, with these usernames:
- *Renée*, the target of the attack. This user may be a limited user or an administrator. Its user profile directory is assumed to be `C:\Users\Renée`.
- *Ren*, the user who carries out the attack. This user should be a limited user, since an administrator would not need to exploit this vulnerability to inject configuration. Its user profile directory is assumed to be `C:\Users\Ren`.
As *Ren*, run these commands in PowerShell:
```powershell
$d = "$HOME\303\251e\AppData\Local\Programs\Git\etc"
mkdir $d
git config --file $d\gitconfig core.sshCommand calc.exe
icacls $HOME\303 /grant 'Renée:(RX)' /T
(The gitconfig file can instead be written manually, in which case Ren need not have git.)
As Renée:
- Install Git for Windows in the default location for non-systemwide installations, which for that user account is inside
C:\Users\Renée\AppData\Local\Programs. For a non-administrative installation, Git for Windows will pick this location automatically. Allow the installer to place the directory containinggitin the user'sPATH, as it does by default.
(The scenario can be modified for any location the attacker can predict. So, for example, Renée can install Git for Windows with scoop, and Ren could carry out the attack with correspondingly modified path components in place of AppData\Local\Programs\Git.)
-
Install
gitoxideusing any common technique, such as by installing Rust and then runningcargo install gitoxide. -
Open a PowerShell window and run a
gixcommand that attempts to run the SSH client for transport. For example:pwsh gix clone ssh://localhost/myrepo.gitAt least one, and usually two, instances of the Windows calculator will pop up. This happens because
calc.exewas configured in the fake configuration file the user Ren was able to cause to be used, by placing it at the locationgix-pathwrongly resolved the path of Renée's own configuration file to.
The gitconfig file written by the attacker can be adjusted with an arbitrary choice of payload, or to set other configuration variables.
Impact
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. It is especially unlikely with Apple Git on macOS, due to its very high scoped configuration in /Library or /Applications that would be detected instead, as in CVE-2024-45305.
The likelihood of exploitation may be higher on Windows, where attacks such as those shown in the Windows proof-of-concept above can be performed due to the status of \ as a directory separator, and where there is no restriction on usernames containing accented or non-English letters (though the latter is also permitted on some other systems). Even then, complex user interaction is required. In most cases, a system administrator would have to approve an innocuous-seeming username, and then the targeted user (who could be the same or a different user) would have to use an application that uses gix-path.
In general, exploitation is more likely to succeed if at least one of the following applies:
- Users are expected to install
gitthemselves, and are likely to do so in predictable locations. - Locations where
gitis installed, whether due to usernames in their paths or otherwise, contain characters thatgitquotes by default in paths, such as non-English letters and accented letters. - A custom
system-scope configuration file is specified with theGIT_CONFIG_SYSTEMenvironment variable, and its path is in an unusual location or has strangely named components. - A
system-scope configuration file is absent, empty, or suppressed by means other thanGIT_CONFIG_NOSYSTEM. Currently,gix-pathcan treat aglobal-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 wheregitis installed system-wide in an ordinary way.
However, exploitation is expected to be very difficult even under any combination of those factors.
Although the effect here is similar to CVE-2022-24765 once exploited, a greater degree of user interaction would usually be required, and the attack complexity here is much higher because the necessary conditions are uncommon and challenging to predict.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.10.10"
},
"package": {
"ecosystem": "crates.io",
"name": "gix-path"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.10.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-45405"
],
"database_specific": {
"cwe_ids": [
"CWE-41"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-06T19:55:24Z",
"nvd_published_at": "2024-09-06T13:15:05Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`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.\n\n### Details\n\nIn `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.\n\nAffected versions of `gix-path` do not pass `-z`/`--null` to cause `git` to report literal paths ([`650a1b5`](https://github.com/Byron/gitoxide/commit/650a1b5cf25e086197cc55a68525a411e1c28031)). Instead, to cover the occasional case that `git` outputs a quoted path, they attempt to parse the path by stripping the quotation marks:\n\nhttps://github.com/Byron/gitoxide/blob/1cfe577d461293879e91538dbc4bbfe01722e1e8/gix-path/src/env/git/mod.rs#L138-L142\n\nThe 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.\n\nThis is not limited to paths with unusual characters such as quotation marks or newlines. Unless `git` is explicitly configured with `core.quotePath` set to `false`, it also happens when the path contains most non-ASCII characters, including accented or non-English letters. For example, `\u00e9` is transformed to `\\303\\251`, with literal backslashes. (This is an octal representation of the bytes in its UTF-8 encoding. This behavior is not limited to systems that encode paths with UTF-8 on disk.)\n\nRarely, the configuration file `gix-path` wrongly attempts to open can be created by an attacker who has a limited user account on the system. The attacker would often need to request an account username tailored to carrying out the attack.\n\n### PoC\n\n#### Quick demonstration on Unix\n\nOn a Unix-like system in which Git supports no higher scope than `system` for configuration variables (i.e., not on macOS with Apple Git), in a locale that supports UTF-8, with `gitoxide` installed, run:\n\n```sh\nmkdir myrepo\ncd myrepo\ngit init\nprintf \u0027[real]\\n\\trealvar = realval\\n\u0027 \u003e \u0027\u00e9\u0027\nprintf \u0027[fake]\\n\\tfakevar = fakeval\\n\u0027 \u003e \u0027\\303\\251\u0027\nGIT_CONFIG_SYSTEM=\u0027\u00e9\u0027 gix config\n```\n\nIf the above conditions are satisfied and the `gix` command was built against an affected version of `gix-path`, then the last command\u0027s output looks something like this:\n\n```text\n# From \u0027\\303\\251\u0027 (GitInstallation)\n[fake]\n fakevar = fakeval\n\n# From \u0027\u00e9\u0027 (System)\n[real]\n realvar = realval\n\n# From \u0027/home/ubuntu/.gitconfig\u0027 (User)\n[init]\n defaultBranch = main\n\n# From \u0027./.git/config\u0027 (Local)\n[core]\n repositoryformatversion = 0\n filemode = true\n bare = false\n logallrefupdates = true\n ```\n\n#### Demonstration across user accounts on Windows\n\nOn a test system running Windows on which Git for Windows is *not* installed system-wide\u2014resembling a scenario in which users who wish to use Git are expected to install it themselves for their accounts\u2014create two accounts, with these usernames:\n\n- *Ren\u00e9e*, the target of the attack. This user may be a limited user or an administrator. Its user profile directory is assumed to be `C:\\Users\\Ren\u00e9e`.\n- *Ren*, the user who carries out the attack. This user should be a limited user, since an administrator would not need to exploit this vulnerability to inject configuration. Its user profile directory is assumed to be `C:\\Users\\Ren`.\n\nAs *Ren*, run these commands in PowerShell:\n\n```powershell\n$d = \"$HOME\\303\\251e\\AppData\\Local\\Programs\\Git\\etc\"\nmkdir $d\ngit config --file $d\\gitconfig core.sshCommand calc.exe\nicacls $HOME\\303 /grant \u0027Ren\u00e9e:(RX)\u0027 /T\n```\n\n(The `gitconfig` file can instead be written manually, in which case *Ren* need not have `git`.)\n\nAs *Ren\u00e9e*:\n\n1. Install Git for Windows in the default location for non-systemwide installations, which for that user account is inside `C:\\Users\\Ren\u00e9e\\AppData\\Local\\Programs`. For a non-administrative installation, Git for Windows will pick this location automatically. Allow the installer to place the directory containing `git` in the user\u0027s `PATH`, as it does by default.\n\n (The scenario can be modified for any location the attacker can predict. So, for example, *Ren\u00e9e* can install Git for Windows with [`scoop`](https://scoop.sh/), and *Ren* could carry out the attack with correspondingly modified path components in place of `AppData\\Local\\Programs\\Git`.)\n \n 2. Install `gitoxide` using any common technique, such as by [installing Rust](https://www.rust-lang.org/tools/install) and then running `cargo install gitoxide`.\n\n3. Open a PowerShell window and run a `gix` command that attempts to run the SSH client for transport. For example:\n\n ```pwsh\n gix clone ssh://localhost/myrepo.git\n ```\n \n At least one, and usually two, instances of the Windows calculator will pop up. This happens because `calc.exe` was configured in the fake configuration file the user *Ren* was able to cause to be used, by placing it at the location `gix-path` wrongly resolved the path of *Ren\u00e9e*\u0027s own configuration file to.\n \n The `gitconfig` file written by the attacker can be adjusted with an arbitrary choice of payload, or to set other configuration variables.\n\n### Impact\n\nOn 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.\n\nExploitation is unlikely even on a multi-user system, though it is plausible in some uncommon configurations or use cases. It is especially unlikely with Apple Git on macOS, due to its very high scoped configuration in `/Library` or `/Applications` that would be detected instead, as in CVE-2024-45305.\n\nThe likelihood of exploitation may be higher on Windows, where attacks such as those shown in the Windows proof-of-concept above can be performed due to the status of `\\` as a directory separator, and where there is no restriction on usernames containing accented or non-English letters (though the latter is also permitted on some other systems). Even then, complex user interaction is required. In most cases, a system administrator would have to approve an innocuous-seeming username, and then the targeted user (who could be the same or a different user) would have to use an application that uses `gix-path`.\n\nIn general, exploitation is more likely to succeed if at least one of the following applies:\n\n- Users are expected to install `git` themselves, and are likely to do so in predictable locations.\n- 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.\n- 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.\n- 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.\n\nHowever, exploitation is expected to be very difficult even under any combination of those factors.\n\nAlthough the effect here is similar to [CVE-2022-24765](https://github.com/git-for-windows/git/security/advisories/GHSA-vw2c-22j4-2fh2) once exploited, a greater degree of user interaction would usually be required, and the attack complexity here is much higher because the necessary conditions are uncommon and challenging to predict.",
"id": "GHSA-m8rp-vv92-46c7",
"modified": "2024-09-18T22:48:07Z",
"published": "2024-09-06T19:55:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Byron/gitoxide/security/advisories/GHSA-m8rp-vv92-46c7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45405"
},
{
"type": "WEB",
"url": "https://github.com/Byron/gitoxide/commit/650a1b5cf25e086197cc55a68525a411e1c28031"
},
{
"type": "PACKAGE",
"url": "https://github.com/Byron/gitoxide"
},
{
"type": "WEB",
"url": "https://github.com/Byron/gitoxide/blob/1cfe577d461293879e91538dbc4bbfe01722e1e8/gix-path/src/env/git/mod.rs#L138-L142"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0371.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "gix-path improperly resolves configuration path reported by Git"
}
GHSA-MQW3-CRQW-FQ73
Vulnerability from github – Published: 2025-03-12 21:31 – Updated: 2025-03-12 21:31A vulnerability in the Palo Alto Networks PAN-OS software enables an authenticated admin on the PAN-OS CLI to read arbitrary files.
This issue does not affect Cloud NGFW or Prisma Access.
{
"affected": [],
"aliases": [
"CVE-2025-0115"
],
"database_specific": {
"cwe_ids": [
"CWE-41"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T19:15:37Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the Palo Alto Networks PAN-OS software enables an authenticated admin on the PAN-OS CLI to read arbitrary files.\n\nThis issue does not affect Cloud NGFW or Prisma Access.",
"id": "GHSA-mqw3-crqw-fq73",
"modified": "2025-03-12T21:31:29Z",
"published": "2025-03-12T21:31:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0115"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2025-0115"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:U/V:C/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-P2F3-RM9R-RXGJ
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32In 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.
{
"affected": [],
"aliases": [
"CVE-2024-8765"
],
"database_specific": {
"cwe_ids": [
"CWE-41"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-20T10:15:44Z",
"severity": "HIGH"
},
"details": "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 \u0027/auth/\u0027 anywhere within it. This allows unauthenticated attackers to access sensitive endpoints by including \u0027/auth/\u0027 in the path. As a result, attackers can obtain and modify sensitive data and utilize other organizations\u0027 resources without proper authentication.",
"id": "GHSA-p2f3-rm9r-rxgj",
"modified": "2025-03-20T12:32:48Z",
"published": "2025-03-20T12:32:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8765"
},
{
"type": "WEB",
"url": "https://github.com/lunary-ai/lunary/commit/7ff89b0304d191534b924cf063f3648206d497fa"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/4908cfcf-607a-412a-9635-966cbb08bb49"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-PGWQ-W27Q-QG7F
Vulnerability from github – Published: 2025-10-11 09:30 – Updated: 2025-10-16 15:30Denial of service (DoS) vulnerability in the office service. Successful exploitation of this vulnerability may affect availability.
{
"affected": [],
"aliases": [
"CVE-2025-58290"
],
"database_specific": {
"cwe_ids": [
"CWE-41"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-11T09:15:33Z",
"severity": "LOW"
},
"details": "Denial of service (DoS) vulnerability in the office service.\u00a0Successful exploitation of this vulnerability may affect availability.",
"id": "GHSA-pgwq-w27q-qg7f",
"modified": "2025-10-16T15:30:27Z",
"published": "2025-10-11T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58290"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/10"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-PQ58-CW5G-45JC
Vulnerability from github – Published: 2025-09-16 00:30 – Updated: 2025-11-03 21:34A 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.
{
"affected": [],
"aliases": [
"CVE-2025-43298"
],
"database_specific": {
"cwe_ids": [
"CWE-41"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-15T23:15:32Z",
"severity": "HIGH"
},
"details": "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.",
"id": "GHSA-pq58-cw5g-45jc",
"modified": "2025-11-03T21:34:29Z",
"published": "2025-09-16T00:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43298"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125110"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125111"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/125112"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Sep/53"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Sep/54"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Sep/55"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PRPG-P95C-32FV
Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-21 17:12A 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.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "gradio"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-12217"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-41"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-21T17:12:10Z",
"nvd_published_at": "2025-03-20T10:15:27Z",
"severity": "MODERATE"
},
"details": "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 \u0027C:/tmp/secret.txt\u0027, it fails to block access when using NTFS Alternate Data Streams (ADS) syntax, such as \u0027C:/tmp/secret.txt::$DATA\u0027. This flaw can lead to unauthorized reading of blocked file paths.",
"id": "GHSA-prpg-p95c-32fv",
"modified": "2025-03-21T17:12:10Z",
"published": "2025-03-20T12:32:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-12217"
},
{
"type": "PACKAGE",
"url": "https://github.com/gradio-app/gradio"
},
{
"type": "WEB",
"url": "https://github.com/gradio-app/gradio/blob/67e4044c9ca8358eceeb1fa72fa415df03397d20/gradio/utils.py#L1061-L1074"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/0439bf3d-cb38-43a5-8314-0fadf85cc5a0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Gradio Path Traversal vulnerability"
}
GHSA-VP5Q-499V-968R
Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2025-01-14 18:32MapUrlToZone Security Feature Bypass Vulnerability
{
"affected": [],
"aliases": [
"CVE-2025-21268"
],
"database_specific": {
"cwe_ids": [
"CWE-41"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T18:15:46Z",
"severity": "MODERATE"
},
"details": "MapUrlToZone Security Feature Bypass Vulnerability",
"id": "GHSA-vp5q-499v-968r",
"modified": "2025-01-14T18:32:03Z",
"published": "2025-01-14T18:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21268"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21268"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-30
Strategy: Output Encoding
Use and specify an output encoding that can be handled by the downstream component that is reading the output. Common encodings include ISO-8859-1, UTF-7, and UTF-8. When an encoding is not specified, a downstream component may choose a different encoding, either by assuming a default encoding or automatically inferring which encoding is being used, which can be erroneous. When the encodings are inconsistent, the downstream component might treat some character or byte sequences as special, even if they are not special in the original encoding. Attackers might then be able to exploit this discrepancy and conduct injection attacks; they even might be able to bypass protection mechanisms that assume the original encoding is also being used by the downstream component.
Mitigation MIT-20
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters
Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.