Common Weakness Enumeration

CWE-426

Allowed-with-Review

Untrusted Search Path

Abstraction: Base · Status: Stable

The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.

892 vulnerabilities reference this CWE, most recent first.

GHSA-29W7-7V82-G4CW

Vulnerability from github – Published: 2022-05-14 02:21 – Updated: 2022-05-14 02:21

Details

Untrusted search path vulnerability in Microsoft Auto Updater for Mac allows local users to gain privileges via a Trojan horse executable file, aka "Microsoft (MAU) Office Elevation of Privilege Vulnerability."

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2016-7300"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2016-12-20T06:59:00Z",
    "severity": "HIGH"
  },
  "details": "Untrusted search path vulnerability in Microsoft Auto Updater for Mac allows local users to gain privileges via a Trojan horse executable file, aka \"Microsoft (MAU) Office Elevation of Privilege Vulnerability.\"",
  "id": "GHSA-29w7-7v82-g4cw",
  "modified": "2022-05-14T02:21:48Z",
  "published": "2022-05-14T02:21:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-7300"
    },
    {
      "type": "WEB",
      "url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-148"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94784"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1037441"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2CR4-36RR-4464

Vulnerability from github – Published: 2022-05-14 01:39 – Updated: 2022-05-14 01:39

Details

Untrusted search path vulnerability in Installer of INplc SDK Express 3.08 and earlier and Installer of INplc SDK Pro+ 3.08 and earlier allows an attacker to gain privileges via a Trojan horse DLL in an unspecified directory.

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2018-0667"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-09T23:29:00Z",
    "severity": "HIGH"
  },
  "details": "Untrusted search path vulnerability in Installer of INplc SDK Express 3.08 and earlier and Installer of INplc SDK Pro+ 3.08 and earlier allows an attacker to gain privileges via a Trojan horse DLL in an unspecified directory.",
  "id": "GHSA-2cr4-36rr-4464",
  "modified": "2022-05-14T01:39:42Z",
  "published": "2022-05-14T01:39:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0667"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN59624986/index.html"
    },
    {
      "type": "WEB",
      "url": "http://www.mnc.co.jp/INplc/info_20180907_E.htm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-2FRG-67W9-883J

Vulnerability from github – Published: 2025-10-29 18:30 – Updated: 2025-10-29 18:30

Details

Potential privilege escalation issue in Revenera InstallShield version 2023 R1 running a renamed Setup.exe on Windows. When a local administrator executes a renamed Setup.exe, the MPR.dll may get loaded from an insecure location and can result in a privilege escalation. The issue has been fixed in versions 2023 R2 and later.

Severity

7.3 (High)


                  
                    CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-14012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-29T16:15:32Z",
    "severity": "HIGH"
  },
  "details": "Potential privilege escalation issue in Revenera InstallShield version 2023 R1 running a renamed Setup.exe on Windows. When a local administrator executes a renamed Setup.exe, the MPR.dll may get loaded from an insecure location and can result in a privilege escalation. The issue has been fixed in versions 2023 R2 and later.",
  "id": "GHSA-2frg-67w9-883j",
  "modified": "2025-10-29T18:30:32Z",
  "published": "2025-10-29T18:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-14012"
    },
    {
      "type": "WEB",
      "url": "https://community.revenera.com/s/article/CVE-2024-14012-Potential-Privilege-Escalation-in-InstallShield-2023-R1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-2G3W-CPC4-CHR4

Vulnerability from github – Published: 2026-04-10 19:26 – Updated: 2026-04-10 19:26

Summary

PraisonAI Vulnerable to Implicit Execution of Arbitrary Code via Automatic `tools.py` Loading

Details

PraisonAI automatically loads a file named tools.py from the current working directory to discover and register custom agent tools. This loading process uses importlib.util.spec_from_file_location and immediately executes module-level code via spec.loader.exec_module() without explicit user consent, validation, or sandboxing.

The tools.py file is loaded implicitly, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named tools.py in the working directory is sufficient to trigger code execution.

This behavior violates the expected security boundary between user-controlled project files (e.g., YAML configurations) and executable code, as untrusted content in the working directory is treated as trusted and executed automatically.

If an attacker can place a malicious tools.py file into a directory where a user or automated system (e.g., CI/CD pipeline) runs praisonai, arbitrary code execution occurs immediately upon startup, before any agent logic begins.

Vulnerable Code Location

src/praisonai/praisonai/tool_resolver.py → ToolResolver._load_local_tools

tools_path = Path(self._tools_py_path)  # defaults to "tools.py" in CWD
...
spec = importlib.util.spec_from_file_location("tools", str(tools_path))
module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module)  # Executes arbitrary code

Reproducing the Attack

Create a malicious tools.py in the target directory:

import os

# Executes immediately on import
print("[PWNED] Running arbitrary attacker code")
os.system("echo RCE confirmed > pwned.txt")

def dummy_tool():
    return "ok"

Create any valid agents.yaml.
Run:

praisonai agents.yaml

Observe:
[PWNED] is printed
pwned.txt is created
No warning or confirmation is shown

Real-world Impact

This issue introduces a software supply chain risk. If an attacker introduces a malicious tools.py into a repository (e.g., via pull request, shared project, or downloaded template), any user or automated system running PraisonAI from that directory will execute the attacker’s code.

Affected scenarios include:

CI/CD pipelines processing untrusted repositories
Shared development environments
AI workflow automation systems
Public project templates or examples

Successful exploitation can lead to:

Execution of arbitrary commands
Exfiltration of environment variables and credentials
Persistence mechanisms on developer or CI systems

Remediation Steps

Require explicit opt-in for loading tools.py
Introduce a CLI flag (e.g., --load-tools) or config option
Disable automatic loading by default
Add pre-execution user confirmation
Warn users before executing local tools.py
Allow users to decline execution
Restrict trusted paths
Only load tools from explicitly defined project directories
Avoid defaulting to the current working directory
Avoid executing module-level code during discovery
Use static analysis (e.g., AST parsing) to identify tool functions
Require explicit registration functions instead of import side effects
Optional hardening
Support sandboxed execution (subprocess / restricted environment)
Provide hash verification or signing for trusted tool files

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.128"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40156"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426",
      "CWE-829",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T19:26:44Z",
    "nvd_published_at": "2026-04-10T17:17:13Z",
    "severity": "HIGH"
  },
  "details": "PraisonAI automatically loads a file named `tools.py` from the current working directory to discover and register custom agent tools. This loading process uses `importlib.util.spec_from_file_location` and immediately executes module-level code via `spec.loader.exec_module()` **without explicit user consent, validation, or sandboxing**.\n\nThe `tools.py` file is loaded **implicitly**, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named `tools.py` in the working directory is sufficient to trigger code execution.\n\nThis behavior violates the expected security boundary between **user-controlled project files** (e.g., YAML configurations) and **executable code**, as untrusted content in the working directory is treated as trusted and executed automatically.\n\nIf an attacker can place a malicious `tools.py` file into a directory where a user or automated system (e.g., CI/CD pipeline) runs `praisonai`, arbitrary code execution occurs immediately upon startup, before any agent logic begins.\n\n---\n\n## Vulnerable Code Location\n\n`src/praisonai/praisonai/tool_resolver.py` \u2192 `ToolResolver._load_local_tools`\n\n```python\ntools_path = Path(self._tools_py_path)  # defaults to \"tools.py\" in CWD\n...\nspec = importlib.util.spec_from_file_location(\"tools\", str(tools_path))\nmodule = importlib.util.module_from_spec(spec)\nspec.loader.exec_module(module)  # Executes arbitrary code\n```\n\n---\n\n## Reproducing the Attack\n\n1. Create a malicious `tools.py` in the target directory:\n\n```python\nimport os\n\n# Executes immediately on import\nprint(\"[PWNED] Running arbitrary attacker code\")\nos.system(\"echo RCE confirmed \u003e pwned.txt\")\n\ndef dummy_tool():\n    return \"ok\"\n```\n\n2. Create any valid `agents.yaml`.\n\n3. Run:\n\n```bash\npraisonai agents.yaml\n```\n\n4. Observe:\n\n* `[PWNED]` is printed\n* `pwned.txt` is created\n* No warning or confirmation is shown\n\n---\n\n## Real-world Impact\n\nThis issue introduces a **software supply chain risk**. If an attacker introduces a malicious `tools.py` into a repository (e.g., via pull request, shared project, or downloaded template), any user or automated system running PraisonAI from that directory will execute the attacker\u2019s code.\n\nAffected scenarios include:\n\n* CI/CD pipelines processing untrusted repositories\n* Shared development environments\n* AI workflow automation systems\n* Public project templates or examples\n\nSuccessful exploitation can lead to:\n\n* Execution of arbitrary commands\n* Exfiltration of environment variables and credentials\n* Persistence mechanisms on developer or CI systems\n\n---\n\n## Remediation Steps\n\n1. **Require explicit opt-in for loading `tools.py`**\n\n   * Introduce a CLI flag (e.g., `--load-tools`) or config option\n   * Disable automatic loading by default\n\n2. **Add pre-execution user confirmation**\n\n   * Warn users before executing local `tools.py`\n   * Allow users to decline execution\n\n3. **Restrict trusted paths**\n\n   * Only load tools from explicitly defined project directories\n   * Avoid defaulting to the current working directory\n\n4. **Avoid executing module-level code during discovery**\n\n   * Use static analysis (e.g., AST parsing) to identify tool functions\n   * Require explicit registration functions instead of import side effects\n\n5. **Optional hardening**\n\n   * Support sandboxed execution (subprocess / restricted environment)\n   * Provide hash verification or signing for trusted tool files",
  "id": "GHSA-2g3w-cpc4-chr4",
  "modified": "2026-04-10T19:26:44Z",
  "published": "2026-04-10T19:26:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2g3w-cpc4-chr4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40156"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.5.128"
    }
  ],
  "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"
    }
  ],
  "summary": "PraisonAI Vulnerable to Implicit Execution of Arbitrary Code via Automatic `tools.py` Loading"
}

GHSA-2GW2-8Q9W-CW8P

Vulnerability from github – Published: 2018-08-31 14:55 – Updated: 2023-01-25 22:55

Summary

Ruby-ffi has a DLL loading issue

Details

ruby-ffi version 1.9.23 and earlier has a DLL loading issue which can be hijacked on Windows OS, when a Symbol is used as DLL name instead of a String This vulnerability appears to have been fixed in v1.9.24 and later.

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "ffi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1000201"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T20:52:04Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "ruby-ffi version 1.9.23 and earlier has a DLL loading issue which can be hijacked on Windows OS, when a Symbol is used as DLL name instead of a String This vulnerability appears to have been fixed in v1.9.24 and later.",
  "id": "GHSA-2gw2-8q9w-cw8p",
  "modified": "2023-01-25T22:55:50Z",
  "published": "2018-08-31T14:55:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000201"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffi/ffi/commit/09e0c6076466b4383da7fa4e13f714311109945a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffi/ffi/commit/e0fe486df0e117ed67b0282b6ada04b7214ca05c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ffi/ffi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ffi/ffi/releases/tag/1.9.24"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/ffi/CVE-2018-1000201.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Ruby-ffi has a DLL loading issue "
}

GHSA-2H83-2WFH-373X

Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-05-24 19:08

Details

The OpenSSL component of the Teradici PCoIP Software Client prior to version 21.07.0 was compiled without the no-autoload-config option, which allowed an attacker to elevate to the privileges of the running process via placing a specially crafted dll in a build configuration directory.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-25699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-21T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "The OpenSSL component of the Teradici PCoIP Software Client prior to version 21.07.0 was compiled without the no-autoload-config option, which allowed an attacker to elevate to the privileges of the running process via placing a specially crafted dll in a build configuration directory.",
  "id": "GHSA-2h83-2wfh-373x",
  "modified": "2022-05-24T19:08:46Z",
  "published": "2022-05-24T19:08:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25699"
    },
    {
      "type": "WEB",
      "url": "https://advisory.teradici.com/security-advisories/102"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2MQJ-M65W-JGHX

Vulnerability from github – Published: 2024-01-10 15:46 – Updated: 2024-09-20 21:04

Summary

Untrusted search path under some conditions on Windows allows arbitrary code execution

Details

Summary

This issue exists because of an incomplete fix for CVE-2023-40590. On Windows, GitPython uses an untrusted search path if it uses a shell to run git, as well as when it runs bash.exe to interpret hooks. If either of those features are used on Windows, a malicious git.exe or bash.exe may be run from an untrusted repository.

Details

Although GitPython often avoids executing programs found in an untrusted search path since 3.1.33, two situations remain where this still occurs. Either can allow arbitrary code execution under some circumstances.

When a shell is used

GitPython can be told to run git commands through a shell rather than as direct subprocesses, by passing shell=True to any method that accepts it, or by both setting Git.USE_SHELL = True and not passing shell=False. Then the Windows cmd.exe shell process performs the path search, and GitPython does not prevent that shell from finding and running git in the current directory.

When GitPython runs git directly rather than through a shell, the GitPython process performs the path search, and currently omits the current directory by setting NoDefaultCurrentDirectoryInExePath in its own environment during the Popen call. Although the cmd.exe shell will honor this environment variable when present, GitPython does not currently pass it into the shell subprocess's environment.

Furthermore, because GitPython sets the subprocess CWD to the root of a repository's working tree, using a shell will run a malicious git.exe in an untrusted repository even if GitPython itself is run from a trusted location.

This also applies if Git.execute is called directly with shell=True (or after Git.USE_SHELL = True) to run any command.

When hook scripts are run

On Windows, GitPython uses bash.exe to run hooks that appear to be scripts. However, unlike when running git, no steps are taken to avoid finding and running bash.exe in the current directory.

This allows the author of an untrusted fork or branch to cause a malicious bash.exe to be run in some otherwise safe workflows. An example of such a scenario is if the user installs a trusted hook while on a trusted branch, then switches to an untrusted feature branch (possibly from a fork) to review proposed changes. If the untrusted feature branch contains a malicious bash.exe and the user's current working directory is the working tree, and the user performs an action that runs the hook, then although the hook itself is uncorrupted, it runs with the malicious bash.exe.

Note that, while bash.exe is a shell, this is a separate scenario from when git is run using the unrelated Windows cmd.exe shell.

PoC

On Windows, create a git.exe file in a repository. Then create a Repo object, and call any method through it (directly or indirectly) that supports the shell keyword argument with shell=True:

mkdir testrepo
git init testrepo
cp ... testrepo git.exe # Replace "..." with any executable of choice.
python -c "import git; print(git.Repo('testrepo').git.version(shell=True))"

The git.exe executable in the repository directory will be run.

Or use no Repo object, but do it from the location with the git.exe:

cd testrepo
python -c "import git; print(git.Git().version(shell=True))"

The git.exe executable in the current directory will be run.

For the scenario with hooks, install a hook in a repository, create a bash.exe file in the current directory, and perform an operation that causes GitPython to attempt to run the hook:

mkdir testrepo
cd testrepo
git init
mv .git/hooks/pre-commit.sample .git/hooks/pre-commit
cp ... bash.exe # Replace "..." with any executable of choice.
echo "Some text" >file.txt
git add file.txt
python -c "import git; git.Repo().index.commit('Some message')"

The bash.exe executable in the current directory will be run.

Impact

The greatest impact is probably in applications that set Git.USE_SHELL = True for historical reasons. (Undesired console windows had, in the past, been created in some kinds of applications, when it was not used.) Such an application may be vulnerable to arbitrary code execution from a malicious repository, even with no other exacerbating conditions. This is to say that, if a shell is used to run git, the full effect of CVE-2023-40590 is still present. Furthermore, as noted above, running the application itself from a trusted directory is not a sufficient mitigation.

An application that does not direct GitPython to use a shell to run git subprocesses thus avoids most of the risk. However, there is no such straightforward way to prevent GitPython from running bash.exe to interpret hooks. So while the conditions needed for that to be exploited are more involved, it may be harder to mitigate decisively prior to patching.

Possible solutions

A straightforward approach would be to address each bug directly:

When a shell is used, pass NoDefaultCurrentDirectoryInExePath into the subprocess environment, because in that scenario the subprocess is the cmd.exe shell that itself performs the path search.
Set NoDefaultCurrentDirectoryInExePath in the GitPython process environment during the Popen call made to run hooks with a bash.exe subprocess.

These need only be done on Windows.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

8.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "GitPython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.41"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-22190"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-10T15:46:00Z",
    "nvd_published_at": "2024-01-11T02:15:48Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThis issue exists because of an incomplete fix for CVE-2023-40590. On Windows, GitPython uses an untrusted search path if it uses a shell to run `git`, as well as when it runs `bash.exe` to interpret hooks. If either of those features are used on Windows, a malicious `git.exe` or `bash.exe` may be run from an untrusted repository.\n\n### Details\n\nAlthough GitPython often avoids executing programs found in an untrusted search path since 3.1.33, two situations remain where this still occurs. Either can allow arbitrary code execution under some circumstances.\n\n#### When a shell is used\n\nGitPython can be told to run `git` commands through a shell rather than as direct subprocesses, by passing `shell=True` to any method that accepts it, or by both setting `Git.USE_SHELL = True` and not passing `shell=False`. Then the Windows `cmd.exe` shell process performs the path search, and GitPython does not prevent that shell from finding and running `git` in the current directory.\n\nWhen GitPython runs `git` directly rather than through a shell, the GitPython process performs the path search, and currently omits the current directory by setting `NoDefaultCurrentDirectoryInExePath` in its own environment during the `Popen` call. Although the `cmd.exe` shell will honor this environment variable when present, GitPython does not currently pass it into the shell subprocess\u0027s environment.\n\nFurthermore, because GitPython sets the subprocess CWD to the root of a repository\u0027s working tree, using a shell will run a malicious `git.exe` in an untrusted repository even if GitPython itself is run from a trusted location.\n\nThis also applies if `Git.execute` is called directly with `shell=True` (or after `Git.USE_SHELL = True`) to run any command.\n\n#### When hook scripts are run\n\nOn Windows, GitPython uses `bash.exe` to run hooks that appear to be scripts. However, unlike when running `git`, no steps are taken to avoid finding and running `bash.exe` in the current directory.\n\nThis allows the author of an untrusted fork or branch to cause a malicious `bash.exe` to be run in some otherwise safe workflows. An example of such a scenario is if the user installs a trusted hook while on a trusted branch, then switches to an untrusted feature branch (possibly from a fork) to review proposed changes. If the untrusted feature branch contains a malicious `bash.exe` and the user\u0027s current working directory is the working tree, and the user performs an action that runs the hook, then although the hook itself is uncorrupted, it runs with the malicious `bash.exe`.\n\nNote that, while `bash.exe` is a shell, this is a separate scenario from when `git` is run using the unrelated Windows `cmd.exe` shell.\n\n### PoC\n\nOn Windows, create a `git.exe` file in a repository. Then create a `Repo` object, and call any method through it (directly or indirectly) that supports the `shell` keyword argument with `shell=True`:\n\n```powershell\nmkdir testrepo\ngit init testrepo\ncp ... testrepo git.exe # Replace \"...\" with any executable of choice.\npython -c \"import git; print(git.Repo(\u0027testrepo\u0027).git.version(shell=True))\"\n```\n\nThe `git.exe` executable in the repository directory will be run.\n\nOr use no `Repo` object, but do it from the location with the `git.exe`:\n\n```powershell\ncd testrepo\npython -c \"import git; print(git.Git().version(shell=True))\"\n```\n\nThe `git.exe` executable in the current directory will be run.\n\nFor the scenario with hooks, install a hook in a repository, create a `bash.exe` file in the current directory, and perform an operation that causes GitPython to attempt to run the hook:\n\n```powershell\nmkdir testrepo\ncd testrepo\ngit init\nmv .git/hooks/pre-commit.sample .git/hooks/pre-commit\ncp ... bash.exe # Replace \"...\" with any executable of choice.\necho \"Some text\" \u003efile.txt\ngit add file.txt\npython -c \"import git; git.Repo().index.commit(\u0027Some message\u0027)\"\n```\n\nThe `bash.exe` executable in the current directory will be run.\n\n### Impact\n\nThe greatest impact is probably in applications that set `Git.USE_SHELL = True` for historical reasons. (Undesired console windows had, in the past, been created in some kinds of applications, when it was not used.) Such an application may be vulnerable to arbitrary code execution from a malicious repository, even with no other exacerbating conditions. This is to say that, if a shell is used to run `git`, the full effect of CVE-2023-40590 is still present. Furthermore, as noted above, running the application itself from a trusted directory is not a sufficient mitigation.\n\nAn application that does not direct GitPython to use a shell to run `git` subprocesses thus avoids most of the risk. However, there is no such straightforward way to prevent GitPython from running `bash.exe` to interpret hooks. So while the conditions needed for that to be exploited are more involved, it may be harder to mitigate decisively prior to patching.\n\n### Possible solutions\n\nA straightforward approach would be to address each bug directly:\n\n- When a shell is used, pass `NoDefaultCurrentDirectoryInExePath` into the subprocess environment, because in that scenario the subprocess is the `cmd.exe` shell that itself performs the path search.\n- Set `NoDefaultCurrentDirectoryInExePath` in the GitPython process environment during the `Popen` call made to run hooks with a `bash.exe` subprocess.\n\nThese need only be done on Windows.",
  "id": "GHSA-2mqj-m65w-jghx",
  "modified": "2024-09-20T21:04:19Z",
  "published": "2024-01-10T15:46:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2mqj-m65w-jghx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22190"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/pull/1792"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/commit/ef3192cc414f2fd9978908454f6fd95243784c7f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gitpython-developers/GitPython"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2024-4.yaml"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Untrusted search path under some conditions on Windows allows arbitrary code execution"
}

GHSA-2PVP-PX52-Q92C

Vulnerability from github – Published: 2022-05-17 03:47 – Updated: 2022-05-17 03:47

Details

Untrusted search path vulnerability in Foxit Reader before 5.0.2.0718 allows local users to gain privileges via a Trojan horse dwmapi.dll, dwrite.dll, or msdrm.dll in the current working directory.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2011-3691"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2011-09-27T19:55:00Z",
    "severity": "HIGH"
  },
  "details": "Untrusted search path vulnerability in Foxit Reader before 5.0.2.0718 allows local users to gain privileges via a Trojan horse dwmapi.dll, dwrite.dll, or msdrm.dll in the current working directory.",
  "id": "GHSA-2pvp-px52-q92c",
  "modified": "2022-05-17T03:47:31Z",
  "published": "2022-05-17T03:47:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3691"
    },
    {
      "type": "WEB",
      "url": "http://www.solutionary.com/index/SERT/Vuln-Disclosures/Foxit-Reader.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2RF8-G32V-WXM7

Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2023-03-29 18:30

Details

The Rapid7 InsightAppSec broker suffers from a DLL injection vulnerability in the 'prunsrv.exe' component of the product. If exploited, a local user of the system (who must already be authenticated to the operating system) can elevate their privileges with this vulnerability to the privilege level of InsightAppSec (usually, SYSTEM). This issue affects version 2019.06.24 and prior versions of the product.

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2019-5631"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-19T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Rapid7 InsightAppSec broker suffers from a DLL injection vulnerability in the \u0027prunsrv.exe\u0027 component of the product. If exploited, a local user of the system (who must already be authenticated to the operating system) can elevate their privileges with this vulnerability to the privilege level of InsightAppSec (usually, SYSTEM). This issue affects version 2019.06.24 and prior versions of the product.",
  "id": "GHSA-2rf8-g32v-wxm7",
  "modified": "2023-03-29T18:30:29Z",
  "published": "2022-05-24T16:53:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5631"
    },
    {
      "type": "WEB",
      "url": "https://help.rapid7.com/insightappsec/release-notes/archive/2019/07"
    }
  ],
  "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-2V36-CCWM-6XW3

Vulnerability from github – Published: 2022-05-17 00:32 – Updated: 2022-05-17 00:32

Details

Untrusted search path vulnerability in HIBUN Confidential File Decryption program prior to 10.50.0.5 allows an attacker to gain privileges via a Trojan horse DLL in an unspecified directory. Note this is a separate vulnerability from CVE-2017-10863.

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-10865"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-10-12T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "Untrusted search path vulnerability in HIBUN Confidential File Decryption program prior to 10.50.0.5 allows an attacker to gain privileges via a Trojan horse DLL in an unspecified directory. Note this is a separate vulnerability from CVE-2017-10863.",
  "id": "GHSA-2v36-ccwm-6xw3",
  "modified": "2022-05-17T00:32:07Z",
  "published": "2022-05-17T00:32:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10865"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN55516206/index.html"
    },
    {
      "type": "WEB",
      "url": "http://www.hitachi-solutions.co.jp/hibun/sp/support/importance/20170929.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation

Architecture and Design Implementation

Strategy: Attack Surface Reduction

Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.

Mitigation

Implementation

When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.

Mitigation

Implementation

Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.

Mitigation

Implementation

Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory.

Mitigation

Implementation

Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of it, while execl() and execv() require a full path.

CAPEC-38: Leveraging/Manipulating Configuration File Search Paths

This pattern of attack sees an adversary load a malicious resource into a program's standard path so that when a known command is executed then the system instead executes the malicious component. The adversary can either modify the search path a program uses, like a PATH variable or classpath, or they can manipulate resources on the path to point to their malicious components. J2EE applications and other component based applications that are built from multiple binaries can have very long list of dependencies to execute. If one of these libraries and/or references is controllable by the attacker then application controls can be circumvented by the attacker.

← Back to the CWE list