Common Weakness Enumeration

CWE-693

Discouraged

Protection Mechanism Failure

Abstraction: Pillar · Status: Draft

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

978 vulnerabilities reference this CWE, most recent first.

GHSA-V558-FHW2-V46W

Vulnerability from github – Published: 2022-05-24 22:00 – Updated: 2023-10-26 16:14
VLAI
Summary
Unsafe entry in Script Security list of approved signatures in Pipeline Remote Loader Plugin
Details

Jenkins Pipeline Remote Loader Plugin before 1.5 provided a custom whitelist for script security that allowed attackers to invoke arbitrary methods, bypassing typical sandbox protection.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:workflow-remote-loader"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-08-30T18:21:15Z",
    "nvd_published_at": "2019-05-31T15:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Jenkins Pipeline Remote Loader Plugin before 1.5 provided a custom whitelist for script security that allowed attackers to invoke arbitrary methods, bypassing typical sandbox protection.",
  "id": "GHSA-v558-fhw2-v46w",
  "modified": "2023-10-26T16:14:43Z",
  "published": "2022-05-24T22:00:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10328"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/workflow-remote-loader-plugin/commit/6f9d60f614359720ec98e22b80ba15e8bf88e712"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHBA-2019:1605"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:1636"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/workflow-remote-loader-plugin"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-05-31/#SECURITY-921"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/05/31/2"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108540"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Unsafe entry in Script Security list of approved signatures in Pipeline Remote Loader Plugin"
}

GHSA-V5CR-HWCX-R95M

Vulnerability from github – Published: 2023-11-21 09:30 – Updated: 2023-11-21 09:30
VLAI
Details

During internal Axis Security Development Model (ASDM) threat-modelling, a flaw was found in the protection for device tampering (commonly known as Secure Boot) in AXIS OS making it vulnerable to a sophisticated attack to bypass this protection. To Axis' knowledge, there are no known exploits of the vulnerability at this time. Axis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-5553"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-21T07:15:11Z",
    "severity": "HIGH"
  },
  "details": "During internal Axis Security Development Model (ASDM) threat-modelling, a flaw was found in the protection for device tampering (commonly known as Secure Boot) in AXIS OS making it vulnerable to a sophisticated attack to bypass this protection. To Axis\u0027 knowledge, there are no known exploits of the vulnerability at this time. Axis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.\n\n",
  "id": "GHSA-v5cr-hwcx-r95m",
  "modified": "2023-11-21T09:30:23Z",
  "published": "2023-11-21T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5553"
    },
    {
      "type": "WEB",
      "url": "https://www.axis.com/dam/public/0a/66/25/cve-2023-5553-en-US-417789.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V63G-V339-2673

Vulnerability from github – Published: 2024-05-02 15:30 – Updated: 2024-07-03 20:09
VLAI
Summary
Jenkins Script Security Plugin has sandbox bypass vulnerability involving crafted constructor bodies
Details

Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed.

Multiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier:

  • Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts.

  • Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type.

These vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

Script Security Plugin 1336.vf33a_a_9863911 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox:

  • Calls to to other constructors using this are now intercepted by the sandbox.

  • Classes in packages that can be shadowed by Groovy-defined classes are no longer ignored by the sandbox when intercepting super constructor calls.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:script-security"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1336.vf33a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-34144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-03T20:14:29Z",
    "nvd_published_at": "2024-05-02T14:15:10Z",
    "severity": "HIGH"
  },
  "details": "Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed.\n\nMultiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier:\n\n- Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts.\n\n- Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type.\n\nThese vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.\n\n- These issues are caused by an incomplete fix of [SECURITY-2824](https://www.jenkins.io/security/advisory/2022-10-19/#SECURITY-2824%20(1)).\n\nScript Security Plugin 1336.vf33a_a_9863911 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox:\n\n- Calls to to other constructors using this are now intercepted by the sandbox.\n\n- Classes in packages that can be shadowed by Groovy-defined classes are no longer ignored by the sandbox when intercepting super constructor calls.\n\n",
  "id": "GHSA-v63g-v339-2673",
  "modified": "2024-07-03T20:09:30Z",
  "published": "2024-05-02T15:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34144"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/script-security-plugin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/script-security-plugin/releases/tag/1336.vf33a_a_9863911"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2024-05-02/#SECURITY-3341"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2024/05/02/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Script Security Plugin has sandbox bypass vulnerability involving crafted constructor bodies"
}

GHSA-V6F5-J8RP-3FRR

Vulnerability from github – Published: 2023-02-09 18:30 – Updated: 2025-03-24 21:30
VLAI
Details

The HwContacts module has a logic bypass vulnerability. Successful exploitation of this vulnerability may affect data integrity.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-48287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-09T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "The HwContacts module has a logic bypass vulnerability. Successful exploitation of this vulnerability may affect data integrity.",
  "id": "GHSA-v6f5-j8rp-3frr",
  "modified": "2025-03-24T21:30:26Z",
  "published": "2023-02-09T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48287"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2023/2"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202302-0000001454769474"
    }
  ],
  "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"
    }
  ]
}

GHSA-V847-HXXW-3PXG

Vulnerability from github – Published: 2026-06-18 13:53 – Updated: 2026-06-18 13:53
VLAI
Summary
PraisonAI recipe.run_stream skips dangerous-tool policy enforcement
Details

PraisonAI recipe.run_stream() skips dangerous-tool policy enforcement

Summary

PraisonAI recipe execution blocks default-denied dangerous tools unless the caller explicitly passes allow_dangerous_tools=True. The normal recipe.run() path enforces this with _check_tool_policy(). The streaming path, recipe.run_stream(), loads the same recipe, checks dependencies, and then calls _execute_recipe() without running the dangerous-tool policy check.

As a result, a recipe that honestly declares execute_command in TEMPLATE.yaml requires.tools is denied by recipe.run(), but reaches the execution engine through recipe.run_stream() with allow_dangerous_tools=False.

The local PoV uses a harmless printf canary, explicitly unsets PRAISONAI_AUTO_APPROVE, and avoids network access.

Affected Product

  • Repository: MervinPraison/PraisonAI
  • Package: praisonai
  • Components:
  • src/praisonai/praisonai/recipe/core.py
  • src/praisonai/praisonai/recipe/serve.py
  • src/praisonai/praisonai/cli/features/recipe.py
  • src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py
  • src/praisonai-agents/praisonaiagents/workflows/workflows.py

Validated affected:

  • current main 2f9677abb2ea68eab864ee8b6a828fd0141612e1 (v4.6.57-4-g2f9677ab)
  • v4.6.57
  • v4.6.56
  • v4.6.10
  • v4.6.9
  • v4.5.128
  • v4.5.120
  • v4.5.96
  • v4.5.87

Suggested affected range: >= 4.5.87, <= 4.6.57.

PyPI lists PraisonAI 4.6.57 as the latest release on 2026-06-13.

Earlier tested tags through v4.5.85 failed in this source checkout before the tested workflow path due an unrelated praisonaiagents.output.models import error. They are not claimed fixed or unaffected.

Root Cause

recipe.run() enforces the dangerous-tool gate:

if not options.get("allow_dangerous_tools", False):
    policy_error = _check_tool_policy(recipe_config)
    if policy_error:
        return RecipeResult(..., status=RecipeStatus.POLICY_DENIED, ...)

recipe.run_stream() has a sibling execution path. It loads the recipe and checks dependencies, but then goes directly to execution:

recipe_config = _load_recipe(name, offline=options.get("offline", False))
...
output = _execute_recipe(recipe_config, merged_config, session_id, options)

There is no equivalent _check_tool_policy() call in run_stream() before execution or before the dry-run shortcut.

The CLI exposes this path via praisonai recipe run <recipe> --stream, and the recipe HTTP server exposes it as POST /v1/recipes/stream.

Why This Is Not Intended Behavior

The normal recipe path clearly treats declared dangerous tools as denied by default. A control recipe with TEMPLATE.yaml requires.tools: [execute_command] returns:

Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.

That operator-facing override should not depend on whether the caller requests streaming output. PraisonAI's own docs describe approval as requiring a human or configured channel before risky tools run, describe security environment variables as opt-in access for dangerous operations with secure defaults, and describe policy controls as blocking dangerous operations.

This is distinct from the prior report PRAI-CAND-011:

  • PRAI-CAND-011 covers workflow tool declarations that are omitted from TEMPLATE.yaml requires.tools.
  • This report covers a sibling entrypoint that skips the policy check even when TEMPLATE.yaml correctly declares the dangerous tool.

It is also distinct from the published Recipe-server authentication fail-open advisory. That advisory covers missing authentication secrets. This report assumes the attacker has whatever access is already needed to invoke recipe streaming and focuses on the missing dangerous-tool policy guard.

Local PoV

Run:

python3 poc/pov_prai_cand_012_stream_policy_bypass.py

Expected output includes:

{
  "ok": true,
  "policy_error": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
  "control_recipe_status": "policy_denied",
  "execution_reached": [
    {
      "recipe": "declared-dangerous-stream",
      "declared_required_tools": ["execute_command"],
      "allow_dangerous_tools": false
    }
  ],
  "workflow_approve_tools": ["execute_command"],
  "runner_tool_names": ["execute_command"],
  "command_stdout": "PRAI-CAND-012-CANARY",
  "operator_env_auto_approve": null
}

The PoV creates a temporary recipe that declares execute_command in TEMPLATE.yaml requires.tools.

Control:

  • recipe.run(..., options={"force": True}) returns policy_denied.

Bypass:

  • recipe.run_stream(..., options={"force": True}) emits the executing event and reaches _execute_recipe() while allow_dangerous_tools remains false.
  • The same recipe workflow resolves execute_command and preserves approve: [execute_command].
  • With the workflow approval context installed, the resolved tool runs the harmless local command printf PRAI-CAND-012-CANARY.

The PoV monkey-patches _execute_recipe() only to prove that run_stream() crosses the policy boundary without invoking an LLM. The command canary is executed directly through the same resolved workflow tool and approval context to keep the proof deterministic and local-only.

Impact

If an operator runs an untrusted recipe through streaming mode, or exposes the recipe streaming API to users who can choose recipe names or URIs, the recipe can reach execution with default-denied tools even though the caller did not set allow_dangerous_tools=True.

If the workflow reaches the approved execute_command tool call, commands run with the privileges of the PraisonAI process. The exact trigger depends on the workflow and model/tool-call path, but the dangerous-tool policy boundary is already bypassed before execution.

The HTTP recipe sidecar is documented as a localhost REST API with SSE streaming and optional API-key/JWT authentication. This report does not claim default unauthenticated network RCE. In authenticated or exposed sidecar deployments where lower-trust users can invoke /v1/recipes/stream, the same policy gap can become a remote recipe-execution issue.

Suggested Fix

Centralize recipe preflight enforcement so every execution mode uses the same guard:

  1. Run _check_tool_policy(recipe_config) in run_stream() unless options["allow_dangerous_tools"] is true.
  2. Perform that check before both dry-run and real execution, matching recipe.run().
  3. Prefer a shared helper for dependency checks, dangerous-tool policy checks, and dry-run handling so future entrypoints cannot drift.
  4. Add regression tests:
  5. declared dangerous tool is denied by recipe.run();
  6. the same declared dangerous tool is denied by recipe.run_stream();
  7. allow_dangerous_tools=True preserves the intended opt-in behavior;
  8. /v1/recipes/stream maps a policy denial to a non-success SSE event or equivalent HTTP failure.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.58"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.5.87"
            },
            {
              "fixed": "4.6.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-78",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:53:05Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "# PraisonAI `recipe.run_stream()` skips dangerous-tool policy enforcement\n\n## Summary\n\nPraisonAI recipe execution blocks default-denied dangerous tools unless the\ncaller explicitly passes `allow_dangerous_tools=True`. The normal `recipe.run()`\npath enforces this with `_check_tool_policy()`. The streaming path,\n`recipe.run_stream()`, loads the same recipe, checks dependencies, and then\ncalls `_execute_recipe()` without running the dangerous-tool policy check.\n\nAs a result, a recipe that honestly declares `execute_command` in\n`TEMPLATE.yaml requires.tools` is denied by `recipe.run()`, but reaches the\nexecution engine through `recipe.run_stream()` with\n`allow_dangerous_tools=False`.\n\nThe local PoV uses a harmless `printf` canary, explicitly unsets\n`PRAISONAI_AUTO_APPROVE`, and avoids network access.\n\n## Affected Product\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `praisonai`\n- Components:\n  - `src/praisonai/praisonai/recipe/core.py`\n  - `src/praisonai/praisonai/recipe/serve.py`\n  - `src/praisonai/praisonai/cli/features/recipe.py`\n  - `src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py`\n  - `src/praisonai-agents/praisonaiagents/workflows/workflows.py`\n\nValidated affected:\n\n- current main `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\n  (`v4.6.57-4-g2f9677ab`)\n- `v4.6.57`\n- `v4.6.56`\n- `v4.6.10`\n- `v4.6.9`\n- `v4.5.128`\n- `v4.5.120`\n- `v4.5.96`\n- `v4.5.87`\n\nSuggested affected range: `\u003e= 4.5.87, \u003c= 4.6.57`.\n\nPyPI lists `PraisonAI 4.6.57` as the latest release on 2026-06-13.\n\nEarlier tested tags through `v4.5.85` failed in this source checkout before the\ntested workflow path due an unrelated `praisonaiagents.output.models` import\nerror. They are not claimed fixed or unaffected.\n\n## Root Cause\n\n`recipe.run()` enforces the dangerous-tool gate:\n\n```python\nif not options.get(\"allow_dangerous_tools\", False):\n    policy_error = _check_tool_policy(recipe_config)\n    if policy_error:\n        return RecipeResult(..., status=RecipeStatus.POLICY_DENIED, ...)\n```\n\n`recipe.run_stream()` has a sibling execution path. It loads the recipe and\nchecks dependencies, but then goes directly to execution:\n\n```python\nrecipe_config = _load_recipe(name, offline=options.get(\"offline\", False))\n...\noutput = _execute_recipe(recipe_config, merged_config, session_id, options)\n```\n\nThere is no equivalent `_check_tool_policy()` call in `run_stream()` before\nexecution or before the dry-run shortcut.\n\nThe CLI exposes this path via `praisonai recipe run \u003crecipe\u003e --stream`, and the\nrecipe HTTP server exposes it as `POST /v1/recipes/stream`.\n\n## Why This Is Not Intended Behavior\n\nThe normal recipe path clearly treats declared dangerous tools as denied by\ndefault. A control recipe with `TEMPLATE.yaml requires.tools:\n[execute_command]` returns:\n\n```text\nTool \u0027execute_command\u0027 is denied by default. Use allow_dangerous_tools=True to override.\n```\n\nThat operator-facing override should not depend on whether the caller requests\nstreaming output. PraisonAI\u0027s own docs describe approval as requiring a human\nor configured channel before risky tools run, describe security environment\nvariables as opt-in access for dangerous operations with secure defaults, and\ndescribe policy controls as blocking dangerous operations.\n\nThis is distinct from the prior report `PRAI-CAND-011`:\n\n- `PRAI-CAND-011` covers workflow tool declarations that are omitted from\n  `TEMPLATE.yaml requires.tools`.\n- This report covers a sibling entrypoint that skips the policy check even when\n  `TEMPLATE.yaml` correctly declares the dangerous tool.\n\nIt is also distinct from the published Recipe-server authentication fail-open\nadvisory. That advisory covers missing authentication secrets. This report\nassumes the attacker has whatever access is already needed to invoke recipe\nstreaming and focuses on the missing dangerous-tool policy guard.\n\n## Local PoV\n\nRun:\n\n```bash\npython3 poc/pov_prai_cand_012_stream_policy_bypass.py\n```\n\nExpected output includes:\n\n```json\n{\n  \"ok\": true,\n  \"policy_error\": \"Tool \u0027execute_command\u0027 is denied by default. Use allow_dangerous_tools=True to override.\",\n  \"control_recipe_status\": \"policy_denied\",\n  \"execution_reached\": [\n    {\n      \"recipe\": \"declared-dangerous-stream\",\n      \"declared_required_tools\": [\"execute_command\"],\n      \"allow_dangerous_tools\": false\n    }\n  ],\n  \"workflow_approve_tools\": [\"execute_command\"],\n  \"runner_tool_names\": [\"execute_command\"],\n  \"command_stdout\": \"PRAI-CAND-012-CANARY\",\n  \"operator_env_auto_approve\": null\n}\n```\n\nThe PoV creates a temporary recipe that declares `execute_command` in\n`TEMPLATE.yaml requires.tools`.\n\nControl:\n\n- `recipe.run(..., options={\"force\": True})` returns `policy_denied`.\n\nBypass:\n\n- `recipe.run_stream(..., options={\"force\": True})` emits the `executing`\n  event and reaches `_execute_recipe()` while `allow_dangerous_tools` remains\n  false.\n- The same recipe workflow resolves `execute_command` and preserves\n  `approve: [execute_command]`.\n- With the workflow approval context installed, the resolved tool runs the\n  harmless local command `printf PRAI-CAND-012-CANARY`.\n\nThe PoV monkey-patches `_execute_recipe()` only to prove that\n`run_stream()` crosses the policy boundary without invoking an LLM. The command\ncanary is executed directly through the same resolved workflow tool and\napproval context to keep the proof deterministic and local-only.\n\n## Impact\n\nIf an operator runs an untrusted recipe through streaming mode, or exposes the\nrecipe streaming API to users who can choose recipe names or URIs, the recipe\ncan reach execution with default-denied tools even though the caller did not\nset `allow_dangerous_tools=True`.\n\nIf the workflow reaches the approved `execute_command` tool call, commands run\nwith the privileges of the PraisonAI process. The exact trigger depends on the\nworkflow and model/tool-call path, but the dangerous-tool policy boundary is\nalready bypassed before execution.\n\nThe HTTP recipe sidecar is documented as a localhost REST API with SSE\nstreaming and optional API-key/JWT authentication. This report does not claim\ndefault unauthenticated network RCE. In authenticated or exposed sidecar\ndeployments where lower-trust users can invoke `/v1/recipes/stream`, the same\npolicy gap can become a remote recipe-execution issue.\n\n## Suggested Fix\n\nCentralize recipe preflight enforcement so every execution mode uses the same\nguard:\n\n1. Run `_check_tool_policy(recipe_config)` in `run_stream()` unless\n   `options[\"allow_dangerous_tools\"]` is true.\n2. Perform that check before both dry-run and real execution, matching\n   `recipe.run()`.\n3. Prefer a shared helper for dependency checks, dangerous-tool policy checks,\n   and dry-run handling so future entrypoints cannot drift.\n4. Add regression tests:\n   - declared dangerous tool is denied by `recipe.run()`;\n   - the same declared dangerous tool is denied by `recipe.run_stream()`;\n   - `allow_dangerous_tools=True` preserves the intended opt-in behavior;\n   - `/v1/recipes/stream` maps a policy denial to a non-success SSE event or\n     equivalent HTTP failure.",
  "id": "GHSA-v847-hxxw-3pxg",
  "modified": "2026-06-18T13:53:05Z",
  "published": "2026-06-18T13:53:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-v847-hxxw-3pxg"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "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 recipe.run_stream skips dangerous-tool policy enforcement"
}

GHSA-V8VH-F89P-82W5

Vulnerability from github – Published: 2025-05-13 00:31 – Updated: 2025-11-03 21:33
VLAI
Details

A file quarantine bypass was addressed with additional checks. This issue is fixed in macOS Sequoia 15.5. An app may be able to break out of its sandbox.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-31244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-12T22:15:24Z",
    "severity": "HIGH"
  },
  "details": "A file quarantine bypass was addressed with additional checks. This issue is fixed in macOS Sequoia 15.5. An app may be able to break out of its sandbox.",
  "id": "GHSA-v8vh-f89p-82w5",
  "modified": "2025-11-03T21:33:53Z",
  "published": "2025-05-13T00:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31244"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/122716"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/May/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V9F3-9MFG-CC55

Vulnerability from github – Published: 2026-05-06 21:31 – Updated: 2026-05-07 01:05
VLAI
Details

Insufficient policy enforcement in DevTools in Google Chrome prior to 148.0.7778.96 allowed an attacker who convinced a user to install a malicious extension to bypass navigation restrictions via a crafted Chrome Extension. (Chromium security severity: Medium)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-7937"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T19:16:42Z",
    "severity": "LOW"
  },
  "details": "Insufficient policy enforcement in DevTools in Google Chrome prior to 148.0.7778.96 allowed an attacker who convinced a user to install a malicious extension to bypass navigation restrictions via a crafted Chrome Extension. (Chromium security severity: Medium)",
  "id": "GHSA-v9f3-9mfg-cc55",
  "modified": "2026-05-07T01:05:51Z",
  "published": "2026-05-06T21:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7937"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/491766258"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VC4P-4FPJ-C36P

Vulnerability from github – Published: 2026-05-06 21:31 – Updated: 2026-05-07 01:05
VLAI
Details

Inappropriate implementation in Companion in Google Chrome on Mac prior to 148.0.7778.96 allowed a remote attacker to perform OS-level privilege escalation via malicious network traffic. (Chromium security severity: Medium)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-7978"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-06T19:16:48Z",
    "severity": "HIGH"
  },
  "details": "Inappropriate implementation in Companion in Google Chrome on Mac prior to 148.0.7778.96 allowed a remote attacker to perform OS-level privilege escalation via malicious network traffic. (Chromium security severity: Medium)",
  "id": "GHSA-vc4p-4fpj-c36p",
  "modified": "2026-05-07T01:05:53Z",
  "published": "2026-05-06T21:31:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-7978"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/05/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/497828892"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VHHJ-J98H-XX8P

Vulnerability from github – Published: 2026-05-13 00:48 – Updated: 2026-05-13 00:48
VLAI
Details

Heym before 0.0.21 contains a sandbox escape vulnerability in the custom Python tool executor that allows authenticated workflow authors to bypass sandbox restrictions by using object-graph introspection primitives. Attackers can use Python introspection techniques to recover the unrestricted import function, import blocked modules such as os and subprocess, and access inherited backend environment variables containing database credentials and encryption keys to execute arbitrary host commands as the backend service user.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-45227"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-12T22:16:38Z",
    "severity": "HIGH"
  },
  "details": "Heym before 0.0.21 contains a sandbox escape vulnerability in the custom Python tool executor that allows authenticated workflow authors to bypass sandbox restrictions by using object-graph introspection primitives. Attackers can use Python introspection techniques to recover the unrestricted __import__ function, import blocked modules such as os and subprocess, and access inherited backend environment variables containing database credentials and encryption keys to execute arbitrary host commands as the backend service user.",
  "id": "GHSA-vhhj-j98h-xx8p",
  "modified": "2026-05-13T00:48:14Z",
  "published": "2026-05-13T00:48:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45227"
    },
    {
      "type": "WEB",
      "url": "https://github.com/heymrun/heym/pull/94"
    },
    {
      "type": "WEB",
      "url": "https://github.com/heymrun/heym/commit/32b7e809d987d9b018ec8daa2cdaf48f627f26f1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/heymrun/heym/releases/tag/v0.0.21"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/heym-sandbox-escape-via-python-introspection"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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-VJV9-7M7J-H833

Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-06-18 14:26
VLAI
Summary
npm PraisonAI SandboxExecutor allowedCommands bypass via shell chaining
Details

Summary

The published npm package praisonai exports SandboxExecutor, CommandValidator, and sandboxExec as "safe command execution with restrictions." When allowedCommands is configured, CommandValidator checks only the first whitespace-delimited token of the command string. SandboxExecutor then passes the entire original string to spawn("sh", ["-c", command]).

With a policy that allows only echo, this direct command is correctly rejected:

cat /tmp/marker

but this chained command is accepted and executed:

echo allowed; cat /tmp/marker

The shell executes cat even though cat is not allowlisted. This bypasses the command allowlist and can execute arbitrary shell commands with the PraisonAI process privileges when an application, CLI workflow, or agent pipeline exposes sandbox command execution to lower-trust users, prompts, or model output.

The PoV is deterministic and local-only. It creates and reads only a temporary marker file.

Technical Details

In src/praisonai-ts/src/cli/features/sandbox-executor.ts, CommandValidator.validate() normalizes the command and authorizes only the first whitespace token:

const normalized = command.toLowerCase().trim();

if (this.allowedCommands) {
  const baseCmd = normalized.split(/\s+/)[0];
  if (!this.allowedCommands.includes(baseCmd)) {
    return { valid: false, reason: `Command '${baseCmd}' not in allowlist` };
  }
}

The denylist does not generally reject shell separators. It blocks a few specific patterns such as ; rm, but not ; cat, &&, ||, backticks, $(), or newline as a general policy boundary.

SandboxExecutor.spawn() then executes the unmodified command string through a shell:

const proc = spawn('sh', ['-c', command], {
  cwd: this.config.cwd,
  env,
  timeout: this.config.timeout,
  stdio: ['pipe', 'pipe', 'pipe']
});

That creates a mismatch: the allowlist authorizes one command token, but the shell interprets the whole string as a script.

The published npm:praisonai@1.7.1 dist files preserve the same behavior:

  • dist/cli/features/sandbox-executor.js checks only baseCmd.
  • dist/cli/features/sandbox-executor.js later invokes spawn("sh", ["-c", command]).
  • dist/index.js exports SandboxExecutor, CommandValidator, and sandboxExec.

Why This Is Not Intended Behavior

PraisonAI's sandbox docs describe sandbox execution as a security feature for AI-generated commands, with command validation, resource limits, path restrictions, network isolation, and execution isolation. The TypeScript source also describes this component as "Safe command execution with restrictions."

With allowedCommands: ["echo"], PraisonAI correctly rejects cat <marker> when submitted directly. That proves the intended policy is to block non-allowlisted executables. The same policy allowing echo allowed; cat <marker> is therefore an authorization bypass, not merely a permissive configuration.

PoV

Run from a local reproduction checkout:

node poc/pov_poc.js 1.7.1

Expected output includes:

{
  "version": "1.7.1",
  "package": "npm:praisonai",
  "allowedCommands": ["echo"],
  "controls": {
    "directCatRejected": true,
    "benignEchoAllowed": true,
    "patchedControlRejectsChainedShell": true
  },
  "observed": {
    "directPolicy": {
      "allowed": false,
      "reason": "Command 'cat' not in allowlist"
    },
    "benignPolicy": {
      "allowed": true
    },
    "chainedPolicy": {
      "allowed": true
    },
    "chainedRun": {
      "success": true,
      "stdout": "allowed\npoc.7.1",
      "stderr": "",
      "exitCode": 0
    },
    "patchedControl": {
      "benign": {
        "allowed": true
      },
      "direct": {
        "allowed": false,
        "reason": "Command 'cat' not in allowlist"
      },
      "chained": {
        "allowed": false,
        "reason": "shell metacharacter rejected before execution"
      }
    }
  },
  "vulnerable": true
}

Interpretation:

  • Direct cat <marker> is rejected by the allowlist.
  • Benign echo allowed is accepted.
  • echo allowed; cat <marker> is accepted by the same allowlist and executes the non-allowlisted cat.
  • A patched-control validator that rejects shell metacharacters before execution blocks the chained command while still allowing benign echo.

The PoV installs npm:praisonai@1.7.1 into a temporary project, creates a temporary marker file, and reads only that file. It does not contact any live service or execute destructive commands.

PoC

The PoV section above contains the local reproduction command, input, and decisive output.

Impact

If lower-trust users, prompts, or model output can influence a command string sent to SandboxExecutor or sandboxExec, allowedCommands does not enforce the intended command boundary. An attacker can append arbitrary shell commands after an allowed first token and run them with the privileges of the PraisonAI process.

Concrete consequences depend on the hosting application and configured process privileges, but can include reading or modifying files, invoking local tools, using available credentials, or causing denial of service.

This report does not claim that npm PraisonAI exposes this as a default network service. It is a library-level sandbox/allowlist bypass in an exported TypeScript API that is explicitly designed for safe command execution.

Severity

Suggested severity: High.

Rationale:

  • AV: common deployment pattern is an application exposing agent prompts or command automation over a network.
  • AC: attacker only needs to induce or submit a command string that starts with an allowed command.
  • PR: conservative base score assumes the attacker can submit prompts or command requests to the application.
  • UI: no operator action is needed once the command reaches the executor.
  • S: impact is in the PraisonAI-hosting process.
  • C/I/A: arbitrary shell commands can affect confidentiality, integrity, and availability depending on process privileges.

If maintainers score only local CLI use, AV:L may be reasonable. If they score public unauthenticated prompt or command endpoints built on this API, PR:N may be reasonable.

Suggested Fix

Avoid passing policy-checked user strings to a shell.

Recommended:

  1. Require callers to pass { command, args }, or parse command strings into argv with a shell-aware parser.
  2. Execute with spawn(command, args, { shell: false }) / execFile() instead of sh -c.
  3. Apply allowedCommands to the exact executable after normalization.
  4. Reject shell metacharacters (;, &&, ||, |, backticks, $(), newline, redirects) when a shell string API must be kept for compatibility.
  5. Add regression tests proving allowedCommands: ["echo"] allows echo ok but rejects cat marker, echo ok; cat marker, echo ok && cat marker, and echo ok | cat marker.

Affected Package/Versions

  • Repository: MervinPraison/PraisonAI
  • Package: npm:praisonai
  • Component: TypeScript CLI feature SandboxExecutor
  • Current head validated: 1ad58ca02975ff1398efeda694ea2ab78f20cf3e
  • Current tag validated: v4.6.58
  • Latest npm package validated: 1.7.1

Suggested affected range:

npm:praisonai >= 1.2.3, <= 1.7.1

Selected version sweep:

  • 1.0.0: package main cannot be required in the selected test environment.
  • 1.2.0, 1.2.1, 1.2.2: SandboxExecutor is not exported.
  • 1.2.3: vulnerable.
  • 1.2.4: vulnerable.
  • 1.3.0: vulnerable.
  • 1.3.6: vulnerable.
  • 1.4.0: vulnerable.
  • 1.5.0: vulnerable.
  • 1.5.4: vulnerable.
  • 1.6.0: vulnerable.
  • 1.7.0: vulnerable.
  • 1.7.1: vulnerable.

Advisory History

This is distinct from known and previously submitted PraisonAI issues:

  • GHSA-r4f2-3m54-pp7q covers PyPI SubprocessSandbox shell=True and blocklist bypass.
  • GHSA-2763-cj5r-c79m covers PyPI praisonai OS command injection.
  • GHSA-v7px-3835-7gjx covers PyPI memory/hooks.py shell injection.
  • GHSA-4wr3-f4p3-5wjh covers Python agent tool approval allow-list manipulation.
  • GHSA-4mr5-g6f9-cfrh covers PyPI/Python execute_code sandbox escape.
  • GHSA-9qhq-v63v-fv3j covers an incomplete fix for a Python command injection.
  • GHSA-vmmj-pfw7-fjwp covers npm codeMode host-process new Function sandbox escape.

No visible local or GitHub advisory covers npm TypeScript SandboxExecutor, CommandValidator, allowedCommands, or the first-token allowlist followed by sh -c shell-chaining root cause.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.2.3"
            },
            {
              "fixed": "1.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-693",
      "CWE-78",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:26:34Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe published npm package `praisonai` exports `SandboxExecutor`, `CommandValidator`, and `sandboxExec` as \"safe command execution with restrictions.\" When `allowedCommands` is configured, `CommandValidator` checks only the first whitespace-delimited token of the command string. `SandboxExecutor` then passes the entire original string to `spawn(\"sh\", [\"-c\", command])`.\n\nWith a policy that allows only `echo`, this direct command is correctly rejected:\n\n```sh\ncat /tmp/marker\n```\n\nbut this chained command is accepted and executed:\n\n```sh\necho allowed; cat /tmp/marker\n```\n\nThe shell executes `cat` even though `cat` is not allowlisted. This bypasses the command allowlist and can execute arbitrary shell commands with the PraisonAI process privileges when an application, CLI workflow, or agent pipeline exposes sandbox command execution to lower-trust users, prompts, or model output.\n\nThe PoV is deterministic and local-only. It creates and reads only a temporary marker file.\n\n## Technical Details\n\nIn `src/praisonai-ts/src/cli/features/sandbox-executor.ts`, `CommandValidator.validate()` normalizes the command and authorizes only the first whitespace token:\n\n```ts\nconst normalized = command.toLowerCase().trim();\n\nif (this.allowedCommands) {\n  const baseCmd = normalized.split(/\\s+/)[0];\n  if (!this.allowedCommands.includes(baseCmd)) {\n    return { valid: false, reason: `Command \u0027${baseCmd}\u0027 not in allowlist` };\n  }\n}\n```\n\nThe denylist does not generally reject shell separators. It blocks a few specific patterns such as `; rm`, but not `; cat`, `\u0026\u0026`, `||`, backticks, `$()`, or newline as a general policy boundary.\n\n`SandboxExecutor.spawn()` then executes the unmodified command string through a shell:\n\n```ts\nconst proc = spawn(\u0027sh\u0027, [\u0027-c\u0027, command], {\n  cwd: this.config.cwd,\n  env,\n  timeout: this.config.timeout,\n  stdio: [\u0027pipe\u0027, \u0027pipe\u0027, \u0027pipe\u0027]\n});\n```\n\nThat creates a mismatch: the allowlist authorizes one command token, but the shell interprets the whole string as a script.\n\nThe published `npm:praisonai@1.7.1` dist files preserve the same behavior:\n\n- `dist/cli/features/sandbox-executor.js` checks only `baseCmd`.\n- `dist/cli/features/sandbox-executor.js` later invokes `spawn(\"sh\", [\"-c\", command])`.\n- `dist/index.js` exports `SandboxExecutor`, `CommandValidator`, and `sandboxExec`.\n\n### Why This Is Not Intended Behavior\n\nPraisonAI\u0027s sandbox docs describe sandbox execution as a security feature for AI-generated commands, with command validation, resource limits, path restrictions, network isolation, and execution isolation. The TypeScript source also describes this component as \"Safe command execution with restrictions.\"\n\nWith `allowedCommands: [\"echo\"]`, PraisonAI correctly rejects `cat \u003cmarker\u003e` when submitted directly. That proves the intended policy is to block non-allowlisted executables. The same policy allowing `echo allowed; cat \u003cmarker\u003e` is therefore an authorization bypass, not merely a permissive configuration.\n\n## PoV\n\nRun from a local reproduction checkout:\n\n```bash\nnode poc/pov_poc.js 1.7.1\n```\n\nExpected output includes:\n\n```json\n{\n  \"version\": \"1.7.1\",\n  \"package\": \"npm:praisonai\",\n  \"allowedCommands\": [\"echo\"],\n  \"controls\": {\n    \"directCatRejected\": true,\n    \"benignEchoAllowed\": true,\n    \"patchedControlRejectsChainedShell\": true\n  },\n  \"observed\": {\n    \"directPolicy\": {\n      \"allowed\": false,\n      \"reason\": \"Command \u0027cat\u0027 not in allowlist\"\n    },\n    \"benignPolicy\": {\n      \"allowed\": true\n    },\n    \"chainedPolicy\": {\n      \"allowed\": true\n    },\n    \"chainedRun\": {\n      \"success\": true,\n      \"stdout\": \"allowed\\npoc.7.1\",\n      \"stderr\": \"\",\n      \"exitCode\": 0\n    },\n    \"patchedControl\": {\n      \"benign\": {\n        \"allowed\": true\n      },\n      \"direct\": {\n        \"allowed\": false,\n        \"reason\": \"Command \u0027cat\u0027 not in allowlist\"\n      },\n      \"chained\": {\n        \"allowed\": false,\n        \"reason\": \"shell metacharacter rejected before execution\"\n      }\n    }\n  },\n  \"vulnerable\": true\n}\n```\n\nInterpretation:\n\n- Direct `cat \u003cmarker\u003e` is rejected by the allowlist.\n- Benign `echo allowed` is accepted.\n- `echo allowed; cat \u003cmarker\u003e` is accepted by the same allowlist and executes the non-allowlisted `cat`.\n- A patched-control validator that rejects shell metacharacters before execution blocks the chained command while still allowing benign `echo`.\n\nThe PoV installs `npm:praisonai@1.7.1` into a temporary project, creates a temporary marker file, and reads only that file. It does not contact any live service or execute destructive commands.\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nIf lower-trust users, prompts, or model output can influence a command string sent to `SandboxExecutor` or `sandboxExec`, `allowedCommands` does not enforce the intended command boundary. An attacker can append arbitrary shell commands after an allowed first token and run them with the privileges of the PraisonAI process.\n\nConcrete consequences depend on the hosting application and configured process privileges, but can include reading or modifying files, invoking local tools, using available credentials, or causing denial of service.\n\nThis report does not claim that npm PraisonAI exposes this as a default network service. It is a library-level sandbox/allowlist bypass in an exported TypeScript API that is explicitly designed for safe command execution.\n\n### Severity\n\nSuggested severity: High.\n\nRationale:\n\n- `AV`: common deployment pattern is an application exposing agent prompts or command automation over a network.\n- `AC`: attacker only needs to induce or submit a command string that starts with an allowed command.\n- `PR`: conservative base score assumes the attacker can submit prompts or command requests to the application.\n- `UI`: no operator action is needed once the command reaches the executor.\n- `S`: impact is in the PraisonAI-hosting process.\n- `C/I/A`: arbitrary shell commands can affect confidentiality, integrity, and availability depending on process privileges.\n\nIf maintainers score only local CLI use, `AV:L` may be reasonable. If they score public unauthenticated prompt or command endpoints built on this API, `PR:N` may be reasonable.\n\n## Suggested Fix\n\nAvoid passing policy-checked user strings to a shell.\n\nRecommended:\n\n1. Require callers to pass `{ command, args }`, or parse command strings into argv with a shell-aware parser.\n2. Execute with `spawn(command, args, { shell: false })` / `execFile()` instead of `sh -c`.\n3. Apply `allowedCommands` to the exact executable after normalization.\n4. Reject shell metacharacters (`;`, `\u0026\u0026`, `||`, `|`, backticks, `$()`, newline, redirects) when a shell string API must be kept for compatibility.\n5. Add regression tests proving `allowedCommands: [\"echo\"]` allows `echo ok` but rejects `cat marker`, `echo ok; cat marker`, `echo ok \u0026\u0026 cat marker`, and `echo ok | cat marker`.\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `npm:praisonai`\n- Component: TypeScript CLI feature `SandboxExecutor`\n- Current head validated: `1ad58ca02975ff1398efeda694ea2ab78f20cf3e`\n- Current tag validated: `v4.6.58`\n- Latest npm package validated: `1.7.1`\n\nSuggested affected range:\n\n```text\nnpm:praisonai \u003e= 1.2.3, \u003c= 1.7.1\n```\n\nSelected version sweep:\n\n- `1.0.0`: package main cannot be required in the selected test environment.\n- `1.2.0`, `1.2.1`, `1.2.2`: `SandboxExecutor` is not exported.\n- `1.2.3`: vulnerable.\n- `1.2.4`: vulnerable.\n- `1.3.0`: vulnerable.\n- `1.3.6`: vulnerable.\n- `1.4.0`: vulnerable.\n- `1.5.0`: vulnerable.\n- `1.5.4`: vulnerable.\n- `1.6.0`: vulnerable.\n- `1.7.0`: vulnerable.\n- `1.7.1`: vulnerable.\n\n## Advisory History\n\nThis is distinct from known and previously submitted PraisonAI issues:\n\n- `GHSA-r4f2-3m54-pp7q` covers PyPI `SubprocessSandbox` `shell=True` and blocklist bypass.\n- `GHSA-2763-cj5r-c79m` covers PyPI `praisonai` OS command injection.\n- `GHSA-v7px-3835-7gjx` covers PyPI `memory/hooks.py` shell injection.\n- `GHSA-4wr3-f4p3-5wjh` covers Python agent tool approval allow-list manipulation.\n- `GHSA-4mr5-g6f9-cfrh` covers PyPI/Python `execute_code` sandbox escape.\n- `GHSA-9qhq-v63v-fv3j` covers an incomplete fix for a Python command injection.\n- `GHSA-vmmj-pfw7-fjwp` covers npm `codeMode` host-process `new Function` sandbox escape.\n\nNo visible local or GitHub advisory covers npm TypeScript `SandboxExecutor`, `CommandValidator`, `allowedCommands`, or the first-token allowlist followed by `sh -c` shell-chaining root cause.",
  "id": "GHSA-vjv9-7m7j-h833",
  "modified": "2026-06-18T14:26:35Z",
  "published": "2026-06-18T14:26:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vjv9-7m7j-h833"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "npm PraisonAI SandboxExecutor allowedCommands bypass via shell chaining"
}

No mitigation information available for this CWE.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

CAPEC-107: Cross Site Tracing

Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.

CAPEC-127: Directory Indexing

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-20: Encryption Brute Forcing

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

CAPEC-480: Escaping Virtualization

An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.

CAPEC-51: Poison Web Service Registry

SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-65: Sniff Application Code

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.

CAPEC-74: Manipulating State

The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.

State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.

If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.

CAPEC-87: Forceful Browsing

An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.