CWE-693
DiscouragedProtection 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:14Jenkins 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.
{
"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:30During 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.
{
"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:09Jenkins 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.
- These issues are caused by an incomplete fix of SECURITY-2824.
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.
{
"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:30The HwContacts module has a logic bypass vulnerability. Successful exploitation of this vulnerability may affect data integrity.
{
"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:53PraisonAI 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.pysrc/praisonai/praisonai/recipe/serve.pysrc/praisonai/praisonai/cli/features/recipe.pysrc/praisonai-agents/praisonaiagents/workflows/yaml_parser.pysrc/praisonai-agents/praisonaiagents/workflows/workflows.py
Validated affected:
- current main
2f9677abb2ea68eab864ee8b6a828fd0141612e1(v4.6.57-4-g2f9677ab) v4.6.57v4.6.56v4.6.10v4.6.9v4.5.128v4.5.120v4.5.96v4.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-011covers workflow tool declarations that are omitted fromTEMPLATE.yaml requires.tools.- This report covers a sibling entrypoint that skips the policy check even when
TEMPLATE.yamlcorrectly 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})returnspolicy_denied.
Bypass:
recipe.run_stream(..., options={"force": True})emits theexecutingevent and reaches_execute_recipe()whileallow_dangerous_toolsremains false.- The same recipe workflow resolves
execute_commandand preservesapprove: [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:
- Run
_check_tool_policy(recipe_config)inrun_stream()unlessoptions["allow_dangerous_tools"]is true. - Perform that check before both dry-run and real execution, matching
recipe.run(). - Prefer a shared helper for dependency checks, dangerous-tool policy checks, and dry-run handling so future entrypoints cannot drift.
- Add regression tests:
- declared dangerous tool is denied by
recipe.run(); - the same declared dangerous tool is denied by
recipe.run_stream(); allow_dangerous_tools=Truepreserves the intended opt-in behavior;/v1/recipes/streammaps a policy denial to a non-success SSE event or equivalent HTTP failure.
{
"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:33A 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.
{
"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:05Insufficient 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)
{
"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:05Inappropriate 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)
{
"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:48Heym 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.
{
"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:26Summary
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.jschecks onlybaseCmd.dist/cli/features/sandbox-executor.jslater invokesspawn("sh", ["-c", command]).dist/index.jsexportsSandboxExecutor,CommandValidator, andsandboxExec.
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 allowedis accepted. echo allowed; cat <marker>is accepted by the same allowlist and executes the non-allowlistedcat.- 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:
- Require callers to pass
{ command, args }, or parse command strings into argv with a shell-aware parser. - Execute with
spawn(command, args, { shell: false })/execFile()instead ofsh -c. - Apply
allowedCommandsto the exact executable after normalization. - Reject shell metacharacters (
;,&&,||,|, backticks,$(), newline, redirects) when a shell string API must be kept for compatibility. - Add regression tests proving
allowedCommands: ["echo"]allowsecho okbut rejectscat marker,echo ok; cat marker,echo ok && cat marker, andecho 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:SandboxExecutoris 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-pp7qcovers PyPISubprocessSandboxshell=Trueand blocklist bypass.GHSA-2763-cj5r-c79mcovers PyPIpraisonaiOS command injection.GHSA-v7px-3835-7gjxcovers PyPImemory/hooks.pyshell injection.GHSA-4wr3-f4p3-5wjhcovers Python agent tool approval allow-list manipulation.GHSA-4mr5-g6f9-cfrhcovers PyPI/Pythonexecute_codesandbox escape.GHSA-9qhq-v63v-fv3jcovers an incomplete fix for a Python command injection.GHSA-vmmj-pfw7-fjwpcovers npmcodeModehost-processnew Functionsandbox 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.
{
"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.