Common Weakness Enumeration

CWE-23

Allowed

Relative Path Traversal

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.

905 vulnerabilities reference this CWE, most recent first.

GHSA-59JX-WQFR-2938

Vulnerability from github – Published: 2026-08-11 18:31 – Updated: 2026-08-11 18:31
VLAI
Details

Relative path traversal in .NET Framework allows an unauthorized attacker to elevate privileges locally.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-65810"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T17:19:00Z",
    "severity": "HIGH"
  },
  "details": "Relative path traversal in .NET Framework allows an unauthorized attacker to elevate privileges locally.",
  "id": "GHSA-59jx-wqfr-2938",
  "modified": "2026-08-11T18:31:40Z",
  "published": "2026-08-11T18:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65810"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-65810"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5CM2-9H8C-RVFX

Vulnerability from github – Published: 2022-07-21 21:39 – Updated: 2022-08-10 23:48
VLAI
Summary
TZInfo relative path traversal vulnerability allows loading of arbitrary files
Details

Impact

Affected versions

  • 0.3.60 and earlier.
  • 1.0.0 to 1.2.9 when used with the Ruby data source (tzinfo-data).

Vulnerability

With the Ruby data source (the tzinfo-data gem for tzinfo version 1.0.0 and later and built-in to earlier versions), time zones are defined in Ruby files. There is one file per time zone. Time zone files are loaded with require on demand. In the affected versions, TZInfo::Timezone.get fails to validate time zone identifiers correctly, allowing a new line character within the identifier. With Ruby version 1.9.3 and later, TZInfo::Timezone.get can be made to load unintended files with require, executing them within the Ruby process.

For example, with version 1.2.9, you can run the following to load a file with path /tmp/payload.rb:

TZInfo::Timezone.get("foo\n/../../../../../../../../../../../../../../../../tmp/payload")

The exact number of parent directory traversals needed will vary depending on the location of the tzinfo-data gem.

TZInfo versions 1.2.6 to 1.2.9 can be made to load files from outside of the Ruby load path. Versions up to and including 1.2.5 can only be made to load files from directories within the load path.

This could be exploited in, for example, a Ruby on Rails application using tzinfo version 1.2.9, that allows file uploads and has a time zone selector that accepts arbitrary time zone identifiers. The CVSS score and severity have been set on this basis.

Versions 2.0.0 and later are not vulnerable.

Patches

Versions 0.3.61 and 1.2.10 include fixes to correctly validate time zone identifiers (commit 9eddbb5c0e682736f61d0dd803b6031a5db9eadf for 0.3.x and commit 9905ca93abf7bf3e387bd592406e403cd18334c7 for 1.2.x).

Note that version 0.3.61 can still load arbitrary files from the Ruby load path if their name follows the rules for a valid time zone identifier and the file has a prefix of tzinfo/definition within a directory in the load path. For example if /tmp/upload was in the load path, then TZInfo::Timezone.get('foo') could load a file with path /tmp/upload/tzinfo/definition/foo.rb. Applications should ensure that untrusted files are not placed in a directory on the load path.

Workarounds

As a workaround, the time zone identifier can be validated before passing to TZInfo::Timezone.get by ensuring it matches the regular expression \A[A-Za-z0-9+\-_]+(?:\/[A-Za-z0-9+\-_]+)*\z.

For more information

If you have any questions or comments about this advisory: - Open an issue in the tzinfo repository.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "tzinfo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.3.61"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "tzinfo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0"
            },
            {
              "fixed": "1.2.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-31163"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-07-21T21:39:29Z",
    "nvd_published_at": "2022-07-22T04:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\n#### Affected versions\n\n  - 0.3.60 and earlier.\n  - 1.0.0 to 1.2.9 when used with the Ruby data source (tzinfo-data).\n\n#### Vulnerability \n\nWith the Ruby data source (the tzinfo-data gem for tzinfo version 1.0.0 and later and built-in to earlier versions), time zones are defined in Ruby files. There is one file per time zone. Time zone files are loaded with `require` on demand. In the affected versions, `TZInfo::Timezone.get` fails to validate time zone identifiers correctly, allowing a new line character within the identifier. With Ruby version 1.9.3 and later, `TZInfo::Timezone.get` can be made to load unintended files with `require`, executing them within the Ruby process.\n\nFor example, with version 1.2.9, you can run the following to load a file with path `/tmp/payload.rb`:\n\n```ruby\nTZInfo::Timezone.get(\"foo\\n/../../../../../../../../../../../../../../../../tmp/payload\")\n```\n\nThe exact number of parent directory traversals needed will vary depending on the location of the tzinfo-data gem.\n\nTZInfo versions 1.2.6 to 1.2.9 can be made to load files from outside of the Ruby load path. Versions up to and including 1.2.5 can only be made to load files from directories within the load path. \n\nThis could be exploited in, for example, a Ruby on Rails application using tzinfo version 1.2.9, that allows file uploads and has a time zone selector that accepts arbitrary time zone identifiers. The CVSS score and severity have been set on this basis.\n\nVersions 2.0.0 and later are not vulnerable.\n\n### Patches\n\nVersions 0.3.61 and 1.2.10 include fixes to correctly validate time zone identifiers (commit 9eddbb5c0e682736f61d0dd803b6031a5db9eadf for 0.3.x and commit 9905ca93abf7bf3e387bd592406e403cd18334c7 for 1.2.x).\n\nNote that version 0.3.61 can still load arbitrary files from the Ruby load path if their name follows the rules for a valid time zone identifier and the file has a prefix of `tzinfo/definition` within a directory in the load path. For example if `/tmp/upload` was in the load path, then `TZInfo::Timezone.get(\u0027foo\u0027)` could load a file with path `/tmp/upload/tzinfo/definition/foo.rb`. Applications should ensure that untrusted files are not placed in a directory on the load path.\n\n### Workarounds\n\nAs a workaround, the time zone identifier can be validated before passing to `TZInfo::Timezone.get` by ensuring it matches the regular expression `\\A[A-Za-z0-9+\\-_]+(?:\\/[A-Za-z0-9+\\-_]+)*\\z`.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n  - Open an issue in [the tzinfo repository](https://github.com/tzinfo/tzinfo).",
  "id": "GHSA-5cm2-9h8c-rvfx",
  "modified": "2022-08-10T23:48:58Z",
  "published": "2022-07-21T21:39:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tzinfo/tzinfo/security/advisories/GHSA-5cm2-9h8c-rvfx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31163"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tzinfo/tzinfo/commit/9905ca93abf7bf3e387bd592406e403cd18334c7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tzinfo/tzinfo/commit/9eddbb5c0e682736f61d0dd803b6031a5db9eadf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/tzinfo/CVE-2022-31163.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tzinfo/tzinfo"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tzinfo/tzinfo/releases/tag/v0.3.61"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tzinfo/tzinfo/releases/tag/v1.2.10"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2022/08/msg00009.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "TZInfo relative path traversal vulnerability allows loading of arbitrary files"
}

GHSA-5FX4-FFFC-MC96

Vulnerability from github – Published: 2025-04-25 15:31 – Updated: 2025-04-25 15:31
VLAI
Details

In JetBrains TeamCity before 2025.03.1 improper path validation in loggingPreset parameter was possible

Severity
4.9 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-46433"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-25T15:15:40Z",
    "severity": "MODERATE"
  },
  "details": "In JetBrains TeamCity before 2025.03.1 improper path validation in loggingPreset parameter was possible",
  "id": "GHSA-5fx4-fffc-mc96",
  "modified": "2025-04-25T15:31:24Z",
  "published": "2025-04-25T15:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46433"
    },
    {
      "type": "WEB",
      "url": "https://www.jetbrains.com/privacy-security/issues-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5G94-C2WX-8PXW

Vulnerability from github – Published: 2026-02-03 23:57 – Updated: 2026-02-04 21:55
VLAI
Summary
apko has a path traversal in apko dirFS which allows filesystem writes outside base
Details

A Path Traversal vulnerability was discovered in apko's dirFS filesystem abstraction. An attacker who can supply a malicious APK package (e.g., via a compromised or typosquatted repository) could create directories or symlinks outside the intended installation root. The MkdirAll, Mkdir, and Symlink methods in pkg/apk/fs/rwosfs.go use filepath.Join() without validating that the resulting path stays within the base directory.

Fix: Fixed by d8b7887. Merged into release.

Acknowledgements

apko thanks Oleh Konko from 1seal for discovering and reporting this issue.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "chainguard.dev/apko"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.14.8"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25121"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-03T23:57:48Z",
    "nvd_published_at": "2026-02-04T19:16:14Z",
    "severity": "HIGH"
  },
  "details": "A Path Traversal vulnerability was discovered in apko\u0027s dirFS filesystem abstraction. An attacker who can supply a malicious APK package (e.g., via a compromised or typosquatted repository) could create directories or symlinks outside the intended installation root. The MkdirAll, Mkdir, and Symlink methods in pkg/apk/fs/rwosfs.go use filepath.Join() without validating that the resulting path stays within the base directory.\n\n**Fix:** Fixed by [d8b7887](https://github.com/chainguard-dev/apko/commit/d8b7887a968a527791b3c591ae83928cb49a9f14). Merged into release. \n\n**Acknowledgements**                                                                                                                                                                        \n                                                                                                                                                                                              \napko thanks Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.",
  "id": "GHSA-5g94-c2wx-8pxw",
  "modified": "2026-02-04T21:55:44Z",
  "published": "2026-02-03T23:57:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/chainguard-dev/apko/security/advisories/GHSA-5g94-c2wx-8pxw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25121"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chainguard-dev/apko/commit/d8b7887a968a527791b3c591ae83928cb49a9f14"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/chainguard-dev/apko"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "apko has a path traversal in apko dirFS which allows filesystem writes outside base"
}

GHSA-5H5V-HW44-F6GG

Vulnerability from github – Published: 2024-05-14 20:13 – Updated: 2024-05-14 20:13
VLAI
Summary
Oceanic allows unsanitized user input to lead to path traversal in URLs
Details

Impact

Input to functions such as Client.rest.channels.removeBan is not url-encoded, resulting in specially crafted input such as ../../../channels/{id} being normalized into the url /api/v10/channels/{id}, and deleting a channel rather than removing a ban.

Workarounds

  • Sanitizing user input, ensuring strings are valid for the purpose they are being used for.
  • Encoding input with encodeURIComponent before providing it to the library.

References

OceanicJS/Oceanic@8bf8ee8373b8c565fbdbf70a609aba4fbc1a1ffe

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "oceanic.js"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34712"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-14T20:13:58Z",
    "nvd_published_at": "2024-05-14T16:17:26Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nInput to functions such as `Client.rest.channels.removeBan` is not url-encoded, resulting in specially crafted input such as `../../../channels/{id}` being normalized into the url `/api/v10/channels/{id}`, and deleting a channel rather than removing a ban.\n\n### Workarounds\n* Sanitizing user input, ensuring strings are valid for the purpose they are being used for.\n* Encoding input with `encodeURIComponent` before providing it to the library.\n\n### References\nOceanicJS/Oceanic@8bf8ee8373b8c565fbdbf70a609aba4fbc1a1ffe",
  "id": "GHSA-5h5v-hw44-f6gg",
  "modified": "2024-05-14T20:13:58Z",
  "published": "2024-05-14T20:13:58Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/OceanicJS/Oceanic/security/advisories/GHSA-5h5v-hw44-f6gg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34712"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OceanicJS/Oceanic/commit/8bf8ee8373b8c565fbdbf70a609aba4fbc1a1ffe"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/OceanicJS/Oceanic"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Oceanic allows unsanitized user input to lead to path traversal in URLs"
}

GHSA-5H78-3W3C-QH32

Vulnerability from github – Published: 2025-11-28 09:30 – Updated: 2025-11-28 09:30
VLAI
Details

WebITR developed by Uniong has an Arbitrary File Read vulnerability, allowing authenticated remote attackers to exploit Relative Path Traversal to download arbitrary system files.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-13771"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-28T08:15:54Z",
    "severity": "HIGH"
  },
  "details": "WebITR developed by Uniong has an Arbitrary File Read vulnerability, allowing authenticated remote attackers to exploit Relative Path Traversal to download arbitrary system files.",
  "id": "GHSA-5h78-3w3c-qh32",
  "modified": "2025-11-28T09:30:17Z",
  "published": "2025-11-28T09:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13771"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/en/cp-139-10539-21f45-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-10538-6a26d-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/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:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5Q32-895V-VF2F

Vulnerability from github – Published: 2024-03-08 15:30 – Updated: 2025-06-10 09:30
VLAI
Details

A vulnerability was found in ZKTeco ZKBio Media 2.0.0_x64_2024-01-29-1028. It has been classified as problematic. Affected is an unknown function of the file /pro/common/download of the component Service Port 9999. The manipulation of the argument fileName with the input ../../../../zkbio_media.sql leads to path traversal: '../filedir'. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-256272. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
2.1 (Low)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-2318"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23",
      "CWE-24"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-08T13:15:07Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in ZKTeco ZKBio Media 2.0.0_x64_2024-01-29-1028. It has been classified as problematic. Affected is an unknown function of the file /pro/common/download of the component Service Port 9999. The manipulation of the argument fileName with the input ../../../../zkbio_media.sql leads to path traversal: \u0027../filedir\u0027. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-256272. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-5q32-895v-vf2f",
  "modified": "2025-06-10T09:30:30Z",
  "published": "2024-03-08T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-2318"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/whiteman007/a3b25a7ddf38774329d72930e0cd841a"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.256272"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.256272"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.288530"
    },
    {
      "type": "WEB",
      "url": "https://www.zkteco.com/en/Security_Bulletinsibs/11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P/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:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5Q6C-FFVG-XCM9

Vulnerability from github – Published: 2024-06-06 21:30 – Updated: 2025-04-08 22:00
VLAI
Summary
Remote code execution in mlflow
Details

A vulnerability in mlflow/mlflow version 8.2.1 allows for remote code execution due to improper neutralization of special elements used in an OS command ('Command Injection') within the mlflow.data.http_dataset_source.py module. Specifically, when loading a dataset from a source URL with an HTTP scheme, the filename extracted from the Content-Disposition header or the URL path is used to generate the final file path without proper sanitization. This flaw enables an attacker to control the file path fully by utilizing path traversal or absolute path techniques, such as '../../tmp/poc.txt' or '/tmp/poc.txt', leading to arbitrary file write. Exploiting this vulnerability could allow a malicious user to execute commands on the vulnerable machine, potentially gaining access to data and model information. The issue is fixed in version 2.9.0.

Severity
10.0 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "mlflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-0520"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-06T22:15:31Z",
    "nvd_published_at": "2024-06-06T19:15:51Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability in mlflow/mlflow version 8.2.1 allows for remote code execution due to improper neutralization of special elements used in an OS command (\u0027Command Injection\u0027) within the `mlflow.data.http_dataset_source.py` module. Specifically, when loading a dataset from a source URL with an HTTP scheme, the filename extracted from the `Content-Disposition` header or the URL path is used to generate the final file path without proper sanitization. This flaw enables an attacker to control the file path fully by utilizing path traversal or absolute path techniques, such as \u0027../../tmp/poc.txt\u0027 or \u0027/tmp/poc.txt\u0027, leading to arbitrary file write. Exploiting this vulnerability could allow a malicious user to execute commands on the vulnerable machine, potentially gaining access to data and model information. The issue is fixed in version 2.9.0.",
  "id": "GHSA-5q6c-ffvg-xcm9",
  "modified": "2025-04-08T22:00:47Z",
  "published": "2024-06-06T21:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0520"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mlflow/mlflow/commit/400c226953b4568f4361bc0a0c223511652c2b9d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mlflow/mlflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/mlflow/PYSEC-2024-239.yaml"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/93e470d7-b6f0-409b-af63-49d3e2a26dbc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Remote code execution in mlflow"
}

GHSA-5Q89-432M-P2WV

Vulnerability from github – Published: 2025-09-24 15:31 – Updated: 2025-09-24 15:31
VLAI
Details

nncp before 8.12.0 allows path traversal (for reading or writing) during freqing and file saving via a crafted path in packet data.

Severity
6.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-60020"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-24T13:15:36Z",
    "severity": "MODERATE"
  },
  "details": "nncp before 8.12.0 allows path traversal (for reading or writing) during freqing and file saving via a crafted path in packet data.",
  "id": "GHSA-5q89-432m-p2wv",
  "modified": "2025-09-24T15:31:13Z",
  "published": "2025-09-24T15:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-60020"
    },
    {
      "type": "WEB",
      "url": "http://lists.cypherpunks.su/archive/nncp-devel/CAO-d-4riai9EZx4gVfekow-BCtTn07k8BB1ZdsopPVw=scWD1A@mail.gmail.com/T/#md678a00df1020bb811f47f42ef33c54b789cddd7"
    },
    {
      "type": "WEB",
      "url": "http://www.nncpgo.org/Release-8_005f12_005f0.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5RMQ-CHC7-M22F

Vulnerability from github – Published: 2026-10-02 22:44 – Updated: 2026-10-02 22:44
VLAI
Summary
Vibe-Trading file-read tools expose arbitrary server-readable files
Details

Summary:

2 findings — safe_user_path() accepts any path under Path.home() or Path.cwd(), which inside the shipped root container resolves to /root and /app (so all of root's home, including /root/.ssh/id_rsa, /root/.aws/credentials, /root/.kube/config, and /app/agent/.env, passes the check) (F9). read_document() has no sandbox call at all and returns the full content of any path the FastAPI process can read, including /etc/shadow, /etc/passwd, /proc/self/environ, and any secret file mounted into the container (F10). F10 is strictly broader than F9 but they have different fix scopes (F10 = a missing safe_path() call in one function; F9 = the envelope definition in path_utils.py), so both must be patched.

Shared baseline (applies to both findings)

The container has no USER directive (Dockerfile:15 — FROM python:3.11-slim AS runtime, no subsequent USER), so the FastAPI process runs as uid=0(root).

The two file-read tools described here are members of the auto-discovered LLM tool registry. Combined with GHSA-1 / F1, they are reachable from any anonymous TCP client to port 8899, but the same defects also apply to authenticated sessions and to prompt-injection in any document the agent processes. See GHSA-1's shared reproducer block for the install steps; the same docker compose up -d setup applies here.

Note on the HOST placeholder used throughout the per-finding "Steps to observe" blocks below: replace HOST with the address you reach the docker host on — typically localhost (or 127.0.0.1) if you are running the reproducer on the same machine as the container. All curl commands below assume this substitution.

Finding 9 — High: safe_user_path() accepts the entire user home directory and process CWD, allowing LLM tool calls to read /root credentials

  • Severity: High
  • CVSS v3.1: 7.5 — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
  • CVSS v4.0: 8.7 — AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
  • CWE: CWE-22 (Path Traversal); CWE-552 (Files Accessible to External Parties)

Affected file: agent/src/tools/path_utils.py - line 52 — def safe_user_path(p: str) -> Path: - line 73-77 — if resolved.is_relative_to(home) or resolved.is_relative_to(cwd): return resolved — home = Path.home(), cwd = Path.cwd()

Intent vs actual: safe_user_path() is intended to permit journal and shadow-account tools to open broker export files the operator may have placed anywhere under their home directory or the project folder. The intended invariant is that only user-owned broker data files are accessible — not system credential files or SSH keys. The actual envelope check accepts any path whose resolved form is inside Path.home() or Path.cwd(). Inside the shipped Docker container, Path.home() resolves to /root and Path.cwd() resolves to /app. Every file under either subtree passes the check, including:

  • /root/.ssh/id_rsa and any other SSH key files
  • /root/.aws/credentials, /root/.kube/config, /root/.docker/config.json
  • /app/agent/.env (the file containing the operator's real OPENROUTER_API_KEY, TUSHARE_TOKEN, and any other secrets)

A runtime probe inside the container confirmed that safe_user_path('/root/.aws/credentials') returned the path without raising ValueError. ExtractShadowStrategyTool was then invoked against /root/secrets/aws.csv (a planted credential file) and returned an error message containing the first line of the file via the parse-error channel.

Steps to observe:

  1. Per GHSA-1 shared reproducer, start the server with a working LLM API key and create an unauthenticated session.
  2. (Setup for safe demo: inside the container, docker exec a planted file: docker exec <container> sh -c 'mkdir -p /root/secrets && printf "broker_id,api_key,api_secret\nDEMO,FAKE_KEY,FAKE_SECRET\n" > /root/secrets/aws.csv'.)
  3. curl -s -X POST "http://HOST:8899/sessions/$SID/messages" -H 'Content-Type: application/json' -d '{"content":"Analyze the trade journal at the path /root/secrets/aws.csv and tell me what you find."}'
  4. Poll curl -s "http://HOST:8899/sessions/$SID/messages". Observe the agent invoke ExtractShadowStrategyTool with journal_path="/root/secrets/aws.csv", which passes safe_user_path() and attempts to parse the file as a trade journal CSV.
  5. Observe the error response — when the file's structure does not match the expected journal schema, the parse error often includes the first line (column names) verbatim, leaking the file's first line.
  6. Repeat with journal_path="/app/agent/.env" to confirm the .env file is within the accepted envelope.

Impact: Any unauthenticated caller can instruct the LLM to attempt to parse any file under /root or /app as a trade journal, extracting the file's first line via the parse-error message channel. Files with valid CSV-like first lines may leak multiple bytes. In the shipped root container, /root encompasses all credentials a careless operator may have mounted into the home directory; /app includes the agent's own secrets and any operator-staged data files.

Finding 10 — High: read_document() opens any server-readable file with no sandbox enforcement, returning full content of /etc/shadow and /proc/self/environ

  • Severity: High
  • CVSS v3.1: 7.5 — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
  • CVSS v4.0: 8.7 — AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
  • CWE: CWE-22 (Path Traversal); CWE-552 (Files Accessible to External Parties); CWE-200 (Information Exposure)

Affected file: agent/src/tools/doc_reader_tool.py - line 259 — def read_document(file_path: str, pages: str = "") -> str: - line 270 — path = Path(file_path) — followed only by path.exists() and path.is_file() checks before dispatching to format-specific readers - No call to safe_path, safe_user_path, or any other sandbox enforcement appears anywhere in the function

Intent vs actual: DocReaderTool is intended to allow the LLM agent to read documents and data files provided for analysis. Like other file-reading tools in the project, it should apply a sandbox check before opening the file. The actual implementation takes the LLM-emitted file_path string, runs only path.exists() and path.is_file(), and dispatches to the appropriate reader. No call to safe_path or safe_user_path exists in the function. A runtime probe confirmed:

  • read_document('/etc/passwd') returned HTTP 200 with 839 characters of content
  • read_document('/etc/shadow') returned the full shadow password file
  • read_document('/proc/self/environ') returned the full process environment, including OPENROUTER_API_KEY and TUSHARE_TOKEN in plaintext

This is strictly wider than F9: F9 is bounded to /root + /app via the (overly-broad) envelope; F10 has no envelope at all and reaches /etc, /proc, /var, and any other path the FastAPI process can read.

Steps to observe:

  1. Per GHSA-1 shared reproducer, start the server with a working LLM API key and create an unauthenticated session.
  2. curl -s -X POST "http://HOST:8899/sessions/$SID/messages" -H 'Content-Type: application/json' -d '{"content":"Please read and summarize the document at /proc/self/environ"}'
  3. Poll curl -s "http://HOST:8899/sessions/$SID/messages". Observe the agent invoke read_document with file_path="/proc/self/environ" and return the full process environment in the message stream.
  4. Observe OPENROUTER_API_KEY, TUSHARE_TOKEN, and any other variables in agent/.env appearing in plaintext.
  5. Repeat with file_path="/etc/shadow" to confirm shadow password file access.

Impact: An unauthenticated caller can retrieve any file the server process can read. Running as root, that includes /etc/shadow, /etc/passwd, /proc/self/environ (full plaintext API keys), /root/.ssh/id_rsa, and any secret files mounted into the container. This is the broadest file-read primitive in the codebase and provides a credential-extraction path that does not require shell execution — endpoint monitoring tuned to BashTool / shell signatures will miss it entirely.

Why F9 and F10 are listed separately

A maintainer might be tempted to fix only one, on the theory that F10 dominates F9. Two reasons to fix both:

  1. Different fix scope — F10's fix is a single missing call (safe_path(file_path) in read_document before line 270). F9's fix is in safe_user_path() itself: the envelope must be replaced with a strict allowlist of operator-configured directories, not Path.home() ∪ Path.cwd(). A fix that adds the missing safe_user_path call to read_document is insufficient because safe_user_path itself accepts /root and /app/agent/.env. Both surfaces need work.

  2. Different reachability classes — F9 is reachable through tools that already gate on safe_user_path (ExtractShadowStrategyTool and several journal tools), so even a hypothetical F10 fix that switched read_document to use safe_user_path would still leak /root/* because the envelope is broken. F9 is the structural defect; F10 is the missed call.

Suggested remediation

  1. F9 — In safe_user_path() at path_utils.py:52-77, replace the Path.home() ∪ Path.cwd() envelope with a strict allowlist of operator-configured directories (e.g. an explicit BROKER_EXPORTS_DIR env var defaulting to /app/data/broker_exports/). Reject /root, /app/agent/.env, and /app/agent/uploads/ (the latter to prevent F3-uploaded files from being subsequently parsed as a credential-leak vector via the parse-error channel).'

  2. F10 — Add a safe_path() (or safe_user_path()) call at doc_reader_tool.py:270 before the existing path.exists() / path.is_file() checks. Once F9 is patched, the same allowlist will apply uniformly to both read_document and the safe_user_path-gated tools.

  3. Defense-in-depth — Drop the FastAPI process to a non-root user. Add a RUN useradd -m vibe && chown -R vibe /app step to the Dockerfile and USER vibe before CMD. This does not fix the Path Traversal but materially reduces the credential-extraction blast radius of any successful exploit (and benefits every other finding in GHSA-1 and GHSA-2). See GHSA-1 / shared baseline for the matching USER recommendation.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vibe-trading-ai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.1.0"
            },
            {
              "fixed": "0.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-22",
      "CWE-23",
      "CWE-552"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-02T22:44:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary: \n2 findings \u2014 `safe_user_path()` accepts any path under `Path.home()` or `Path.cwd()`, which inside the shipped root container resolves to `/root` and `/app` (so all of root\u0027s home, including `/root/.ssh/id_rsa`, `/root/.aws/credentials`, `/root/.kube/config`, and `/app/agent/.env`, passes the check) (F9). `read_document()` has no sandbox call at all and returns the full content of any path the FastAPI process can read, including `/etc/shadow`, `/etc/passwd`, `/proc/self/environ`, and any secret file mounted into the container (F10). F10 is strictly broader than F9 but they have different fix scopes (F10 = a missing `safe_path()` call in one function; F9 = the envelope definition in `path_utils.py`), so both must be patched.\n\n---\n\n### Shared baseline (applies to both findings)\n\nThe container has no `USER` directive (Dockerfile:15 \u2014 `FROM python:3.11-slim AS runtime`, no subsequent `USER`), so the FastAPI process runs as `uid=0(root)`. \n\nThe two file-read tools described here are members of the auto-discovered LLM tool registry. \nCombined with GHSA-1 / F1, they are reachable from any anonymous TCP client to port 8899, but the same defects also apply to authenticated sessions and to prompt-injection in any document the agent processes. \nSee GHSA-1\u0027s shared reproducer block for the install steps; the same `docker compose up -d` setup applies here.\n\n\u003e **Note on the `HOST` placeholder used throughout the per-finding \"Steps to observe\" blocks below**: replace `HOST` with the address you reach the docker host on \u2014 typically `localhost` (or `127.0.0.1`) if you are running the reproducer on the same machine as the container. All `curl` commands below assume this substitution.\n\n---\n\n### Finding 9 \u2014 High: safe_user_path() accepts the entire user home directory and process CWD, allowing LLM tool calls to read /root credentials\n\n- **Severity**: High\n- **CVSS v3.1**: 7.5 \u2014 `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`\n- **CVSS v4.0**: 8.7 \u2014 `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N`\n- **CWE**: CWE-22 (Path Traversal); CWE-552 (Files Accessible to External Parties)\n\n**Affected file**: `agent/src/tools/path_utils.py`\n- line 52 \u2014 `def safe_user_path(p: str) -\u003e Path:`\n- line 73-77 \u2014 `if resolved.is_relative_to(home) or resolved.is_relative_to(cwd): return resolved` \u2014 `home = Path.home()`, `cwd = Path.cwd()`\n\n**Intent vs actual**: \n`safe_user_path()` is intended to permit journal and shadow-account tools to open broker export files the operator may have placed anywhere under their home directory or the project folder. The intended invariant is that only user-owned broker data files are accessible \u2014 not system credential files or SSH keys. The actual envelope check accepts any path whose resolved form is inside `Path.home()` or `Path.cwd()`. Inside the shipped Docker container, `Path.home()` resolves to `/root` and `Path.cwd()` resolves to `/app`. Every file under either subtree passes the check, including:\n\n- `/root/.ssh/id_rsa` and any other SSH key files\n- `/root/.aws/credentials`, `/root/.kube/config`, `/root/.docker/config.json`\n- `/app/agent/.env` (the file containing the operator\u0027s real `OPENROUTER_API_KEY`, `TUSHARE_TOKEN`, and any other secrets)\n\nA runtime probe inside the container confirmed that `safe_user_path(\u0027/root/.aws/credentials\u0027)` returned the path without raising `ValueError`. `ExtractShadowStrategyTool` was then invoked against `/root/secrets/aws.csv` (a planted credential file) and returned an error message containing the first line of the file via the parse-error channel.\n\n**Steps to observe**:\n\n1. Per GHSA-1 shared reproducer, start the server with a working LLM API key and create an unauthenticated session.\n2. (Setup for safe demo: inside the container, `docker exec` a planted file: `docker exec \u003ccontainer\u003e sh -c \u0027mkdir -p /root/secrets \u0026\u0026 printf \"broker_id,api_key,api_secret\\nDEMO,FAKE_KEY,FAKE_SECRET\\n\" \u003e /root/secrets/aws.csv\u0027`.)\n3. `curl -s -X POST \"http://HOST:8899/sessions/$SID/messages\" -H \u0027Content-Type: application/json\u0027 -d \u0027{\"content\":\"Analyze the trade journal at the path /root/secrets/aws.csv and tell me what you find.\"}\u0027`\n4. Poll `curl -s \"http://HOST:8899/sessions/$SID/messages\"`. Observe the agent invoke `ExtractShadowStrategyTool` with `journal_path=\"/root/secrets/aws.csv\"`, which passes `safe_user_path()` and attempts to parse the file as a trade journal CSV.\n5. Observe the error response \u2014 when the file\u0027s structure does not match the expected journal schema, the parse error often includes the first line (column names) verbatim, leaking the file\u0027s first line.\n6. Repeat with `journal_path=\"/app/agent/.env\"` to confirm the `.env` file is within the accepted envelope.\n\n**Impact**: \nAny unauthenticated caller can instruct the LLM to attempt to parse any file under `/root` or `/app` as a trade journal, extracting the file\u0027s first line via the parse-error message channel. Files with valid CSV-like first lines may leak multiple bytes. In the shipped root container, `/root` encompasses all credentials a careless operator may have mounted into the home directory; `/app` includes the agent\u0027s own secrets and any operator-staged data files.\n\n---\n\n### Finding 10 \u2014 High: read_document() opens any server-readable file with no sandbox enforcement, returning full content of /etc/shadow and /proc/self/environ\n\n- **Severity**: High\n- **CVSS v3.1**: 7.5 \u2014 `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N`\n- **CVSS v4.0**: 8.7 \u2014 `AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N`\n- **CWE**: CWE-22 (Path Traversal); CWE-552 (Files Accessible to External Parties); CWE-200 (Information Exposure)\n\n**Affected file**: `agent/src/tools/doc_reader_tool.py`\n- line 259 \u2014 `def read_document(file_path: str, pages: str = \"\") -\u003e str:`\n- line 270 \u2014 `path = Path(file_path)` \u2014 followed only by `path.exists()` and `path.is_file()` checks before dispatching to format-specific readers\n- No call to `safe_path`, `safe_user_path`, or any other sandbox enforcement appears anywhere in the function\n\n**Intent vs actual**: `DocReaderTool` is intended to allow the LLM agent to read documents and data files provided for analysis. Like other file-reading tools in the project, it should apply a sandbox check before opening the file. The actual implementation takes the LLM-emitted `file_path` string, runs only `path.exists()` and `path.is_file()`, and dispatches to the appropriate reader. No call to `safe_path` or `safe_user_path` exists in the function. A runtime probe confirmed:\n\n- `read_document(\u0027/etc/passwd\u0027)` returned HTTP 200 with 839 characters of content\n- `read_document(\u0027/etc/shadow\u0027)` returned the full shadow password file\n- `read_document(\u0027/proc/self/environ\u0027)` returned the full process environment, including `OPENROUTER_API_KEY` and `TUSHARE_TOKEN` in plaintext\n\nThis is strictly **wider** than F9: F9 is bounded to `/root` + `/app` via the (overly-broad) envelope; F10 has no envelope at all and reaches `/etc`, `/proc`, `/var`, and any other path the FastAPI process can read.\n\n**Steps to observe**:\n\n1. Per GHSA-1 shared reproducer, start the server with a working LLM API key and create an unauthenticated session.\n2. `curl -s -X POST \"http://HOST:8899/sessions/$SID/messages\" -H \u0027Content-Type: application/json\u0027 -d \u0027{\"content\":\"Please read and summarize the document at /proc/self/environ\"}\u0027`\n3. Poll `curl -s \"http://HOST:8899/sessions/$SID/messages\"`. Observe the agent invoke `read_document` with `file_path=\"/proc/self/environ\"` and return the full process environment in the message stream.\n4. Observe `OPENROUTER_API_KEY`, `TUSHARE_TOKEN`, and any other variables in `agent/.env` appearing in plaintext.\n5. Repeat with `file_path=\"/etc/shadow\"` to confirm shadow password file access.\n\n**Impact**: \nAn unauthenticated caller can retrieve any file the server process can read. Running as root, that includes `/etc/shadow`, `/etc/passwd`, `/proc/self/environ` (full plaintext API keys), `/root/.ssh/id_rsa`, and any secret files mounted into the container. This is the broadest file-read primitive in the codebase and provides a credential-extraction path that does **not** require shell execution \u2014 endpoint monitoring tuned to BashTool / shell signatures will miss it entirely.\n\n---\n\n### Why F9 and F10 are listed separately\n\nA maintainer might be tempted to fix only one, on the theory that F10 dominates F9. Two reasons to fix both:\n\n1. **Different fix scope** \u2014 F10\u0027s fix is a single missing call (`safe_path(file_path)` in `read_document` before line 270). F9\u0027s fix is in `safe_user_path()` itself: the envelope must be replaced with a strict allowlist of operator-configured directories, *not* `Path.home() \u222a Path.cwd()`. A fix that adds the missing `safe_user_path` call to `read_document` is **insufficient** because `safe_user_path` itself accepts `/root` and `/app/agent/.env`. Both surfaces need work.\n\n2. **Different reachability classes** \u2014 F9 is reachable through tools that already gate on `safe_user_path` (`ExtractShadowStrategyTool` and several journal tools), so even a hypothetical F10 fix that switched `read_document` to use `safe_user_path` would still leak `/root/*` because the envelope is broken. F9 is the structural defect; F10 is the missed call.\n\n---\n\n### Suggested remediation\n\n11. **F9** \u2014 In `safe_user_path()` at `path_utils.py:52-77`, replace the `Path.home() \u222a Path.cwd()` envelope with a strict allowlist of operator-configured directories (e.g. an explicit `BROKER_EXPORTS_DIR` env var defaulting to `/app/data/broker_exports/`). Reject `/root`, `/app/agent/.env`, and `/app/agent/uploads/` (the latter to prevent F3-uploaded files from being subsequently parsed as a credential-leak vector via the parse-error channel).\u0027\n\n12. **F10** \u2014 Add a `safe_path()` (or `safe_user_path()`) call at `doc_reader_tool.py:270` before the existing `path.exists()` / `path.is_file()` checks. Once F9 is patched, the same allowlist will apply uniformly to both `read_document` and the `safe_user_path`-gated tools.\n\n13. **Defense-in-depth** \u2014 Drop the FastAPI process to a non-root user. Add a `RUN useradd -m vibe \u0026\u0026 chown -R vibe /app` step to the Dockerfile and `USER vibe` before `CMD`. This does not fix the Path Traversal but materially reduces the credential-extraction blast radius of any successful exploit (and benefits every other finding in GHSA-1 and GHSA-2). See GHSA-1 / shared baseline for the matching `USER` recommendation.\n\n---",
  "id": "GHSA-5rmq-chc7-m22f",
  "modified": "2026-10-02T22:44:12Z",
  "published": "2026-10-02T22:44:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/Vibe-Trading/security/advisories/GHSA-5rmq-chc7-m22f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/Vibe-Trading/commit/9454d4a27a763b80e1d6eb5763b86c88e9e4e714"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/HKUDS/Vibe-Trading"
    },
    {
      "type": "WEB",
      "url": "https://github.com/HKUDS/Vibe-Trading/releases/tag/v0.1.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vibe-Trading file-read tools expose arbitrary server-readable files"
}
Mitigation MIT-5.1
Implementation

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.
  • When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
  • Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-20.1
Implementation

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.
  • Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:
  • realpath() in C
  • getCanonicalPath() in Java
  • GetFullPath() in ASP.NET
  • realpath() or abs_path() in Perl
  • realpath() in PHP
Mitigation MIT-29
Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

CAPEC-139: Relative Path Traversal

An attacker exploits a weakness in input validation on the target by supplying a specially constructed path utilizing dot and slash characters for the purpose of obtaining access to arbitrary files or resources. An attacker modifies a known path on the target in order to reach material that is not available through intended channels. These attacks normally involve adding additional path separators (/ or \) and/or dots (.), or encodings thereof, in various combinations in order to reach parent directories or entirely separate trees of the target's directory structure.

CAPEC-76: Manipulating Web Input to File System Calls

An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.

← Back to the CWE list