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.
8377 vulnerabilities reference this CWE, most recent first.
GHSA-7QQ8-3VQQ-3796
Vulnerability from github – Published: 2026-07-24 15:33 – Updated: 2026-07-24 18:31Improper control of generation of code ('Code Injection') in the schedule feature in Devolutions PowerShell Universal 2026.2.2 and earlier allows an authenticated user with schedule creation permission to execute arbitrary PowerShell code via crafted schedule parameter names concatenated into a script invocation.
{
"affected": [],
"aliases": [
"CVE-2026-16800"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-24T15:17:12Z",
"severity": "HIGH"
},
"details": "Improper control of generation of code (\u0027Code Injection\u0027) in the schedule feature in Devolutions PowerShell Universal 2026.2.2 and earlier allows an authenticated user with schedule creation permission to execute arbitrary PowerShell code via crafted schedule parameter names concatenated into a script invocation.",
"id": "GHSA-7qq8-3vqq-3796",
"modified": "2026-07-24T18:31:25Z",
"published": "2026-07-24T15:33:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16800"
},
{
"type": "WEB",
"url": "https://devolutions.net/security/advisories/DEVO-2026-0025"
}
],
"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"
}
]
}
GHSA-7QQG-RVF9-85WW
Vulnerability from github – Published: 2026-05-13 00:48 – Updated: 2026-05-13 00:48The The Advanced Custom Fields: Extended plugin for WordPress is vulnerable to arbitrary shortcode execution in all versions up to, and including, 0.9.2.3. This is due to the software allowing users to execute an action that does not properly validate a value before running do_shortcode. This makes it possible for unauthenticated attackers to execute arbitrary shortcodes.
{
"affected": [],
"aliases": [
"CVE-2025-15463"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-12T23:16:15Z",
"severity": "MODERATE"
},
"details": "The The Advanced Custom Fields: Extended plugin for WordPress is vulnerable to arbitrary shortcode execution in all versions up to, and including, 0.9.2.3. This is due to the software allowing users to execute an action that does not properly validate a value before running do_shortcode. This makes it possible for unauthenticated attackers to execute arbitrary shortcodes.",
"id": "GHSA-7qqg-rvf9-85ww",
"modified": "2026-05-13T00:48:14Z",
"published": "2026-05-13T00:48:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15463"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/acf-extended/tags/0.9.2.2/includes/modules/form/module-form-action-email.php#L111"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/acf-extended/tags/0.9.2.2/includes/modules/form/module-form-front-render.php#L35"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f8544784-1994-47e2-be39-568d0ab9ee00?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7QQQ-MVM4-R635
Vulnerability from github – Published: 2023-01-18 21:30 – Updated: 2025-04-04 18:30A remote OScript execution issue was discovered in OpenText Content Suite Platform 22.1 (16.2.19.1803). Multiple endpoints allow the user to pass the parameter htmlFile, which is included in the HTML output rendering pipeline of a request. Because the Content Server evaluates and executes Oscript code in HTML files, it is possible for an attacker to execute Oscript code. The Oscript scripting language allows the attacker (for example) to manipulate files on the filesystem, create new network connections, or execute OS commands.
{
"affected": [],
"aliases": [
"CVE-2022-45928"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-18T21:15:00Z",
"severity": "HIGH"
},
"details": "A remote OScript execution issue was discovered in OpenText Content Suite Platform 22.1 (16.2.19.1803). Multiple endpoints allow the user to pass the parameter htmlFile, which is included in the HTML output rendering pipeline of a request. Because the Content Server evaluates and executes Oscript code in HTML files, it is possible for an attacker to execute Oscript code. The Oscript scripting language allows the attacker (for example) to manipulate files on the filesystem, create new network connections, or execute OS commands.",
"id": "GHSA-7qqq-mvm4-r635",
"modified": "2025-04-04T18:30:32Z",
"published": "2023-01-18T21:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-45928"
},
{
"type": "WEB",
"url": "https://sec-consult.com/vulnerability-lab/advisory/multiple-post-authentication-vulnerabilities-including-rce-opentexttm-extended-ecm"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/170615/OpenText-Extended-ECM-22.3-File-Deletion-LFI-Privilege-Escsalation.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2023/Jan/14"
}
],
"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"
}
]
}
GHSA-7QRW-VMPF-XJ75
Vulnerability from github – Published: 2023-08-05 03:30 – Updated: 2024-04-04 06:34ShuiZe_0x727 v1.0 was discovered to contain a remote command execution (RCE) vulnerability via the component /iniFile/config.ini.
{
"affected": [],
"aliases": [
"CVE-2023-38943"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-05T02:15:11Z",
"severity": "HIGH"
},
"details": "ShuiZe_0x727 v1.0 was discovered to contain a remote command execution (RCE) vulnerability via the component /iniFile/config.ini.",
"id": "GHSA-7qrw-vmpf-xj75",
"modified": "2024-04-04T06:34:12Z",
"published": "2023-08-05T03:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38943"
},
{
"type": "WEB",
"url": "https://github.com/0x727/ShuiZe_0x727/issues/160"
},
{
"type": "WEB",
"url": "https://github.com/0x727/ShuiZe_0x727"
}
],
"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"
}
]
}
GHSA-7QW2-W5RC-37X2
Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-07-20 21:28Summary
PraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes allow_dangerous_tools=True. That policy only checks tools declared in TEMPLATE.yaml requires.tools.
For steps-based recipes, the actual execution path loads workflow.yaml with YAMLWorkflowParser. That parser resolves agent-level tools: declarations and preserves top-level approve:. Workflow.start() then installs those YAML-approved tools into the approval context.
As a result, an untrusted recipe can omit execute_command from TEMPLATE.yaml requires.tools, declare it in workflow.yaml agents.*.tools, and add top-level approve: [execute_command]. The caller did not set allow_dangerous_tools=True, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool.
The local PoV uses a harmless printf canary and explicitly unsets PRAISONAI_AUTO_APPROVE.
Technical Details
recipe.run() checks the recipe policy unless options["allow_dangerous_tools"] is true. _check_tool_policy() gets the required tool list from recipe_config.get_required_tools(), which is backed by TEMPLATE.yaml requires.tools.
The steps workflow execution path is separate:
_execute_steps_workflow()parses the workflow file withYAMLWorkflowParser.YAMLWorkflowParserresolvesagents.*.tools.- The same parser reads top-level
approve:and stores it onworkflow.approve_tools. Workflow.start()callsset_yaml_approved_tools(approve_tools).- The approval registry treats YAML-approved tools as approved.
execute_command is listed as a default dangerous tool with critical risk and is decorated with @require_approval(risk_level="critical"). The policy gap is that recipe-level dangerous-tool enforcement does not inspect the workflow file that actually supplies and approves the tool.
Why This Is Not Intended Behavior
YAML approve: is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.
The unintended behavior is that the recipe dangerous-tool policy exposes an operator-facing explicit override, allow_dangerous_tools=True, but a recipe can avoid that policy by moving the dangerous tool declaration from TEMPLATE.yaml requires.tools into the steps workflow. The recipe still runs through the standard recipe runner path, and the same workflow can self-approve the critical tool.
This conflicts with the documented safety model:
- PraisonAI's approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.
- The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.
- Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.
- Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.
A control recipe that declares requires.tools: [execute_command] is denied with:
Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.
The bypass recipe uses the same tool but omits it from requires.tools; it passes policy and reaches the recipe runner's dry-run state.
PoV
Run:
python3 poc/poc.py
Expected output:
{
"ok": true,
"control_policy": "Tool 'execute_command' is denied by default. Use allow_dangerous_tools=True to override.",
"control_recipe_status": "policy_denied",
"bypass_policy": null,
"bypass_recipe_dry_run_status": "dry_run",
"workflow_approve_tools": [
"execute_command"
],
"runner_tool_names": [
"execute_command"
],
"command_stdout": "poc",
"operator_env_auto_approve": null
}
The PoV creates two temporary recipes:
- A control recipe with
TEMPLATE.yaml requires.tools: [execute_command].recipe.run()returnspolicy_denied. - A bypass recipe with no dangerous tools in
TEMPLATE.yaml, but withworkflow.yamldeclaringexecute_commandunder an agent andapprove: [execute_command].recipe.run(..., dry_run=True)reachesdry_run, and the same parser/approval context permits a harmless `printf poc.
PoC
The PoV section above contains the local reproduction command, input, and decisive output.
Impact
If an operator runs an untrusted recipe, or exposes the recipe runner to users who can choose recipe names/URIs, the recipe can self-authorize a default-denied critical shell tool without the operator setting allow_dangerous_tools=True.
Successful exploitation lets the workflow run execute_command with the privileges of the PraisonAI process if the agent reaches the tool call. The exact trigger depends on the workflow and model/tool-call path, but the policy boundary is already bypassed before execution.
This can affect both local CLI use and HTTP recipe-runner deployments. The HTTP recipe runner defaults to localhost/no-auth and requires auth for non-localhost binding, so this report uses local/UI-required severity rather than claiming an unauthenticated network RCE by default.
The local HTTP sidecar documentation also frames the sidecar as a localhost REST API for local/polyglot integration. If a deployment exposes that API to authenticated users who can choose recipe names or URIs, the same policy bypass can become an authenticated remote recipe-execution issue, but that is not the default severity claim.
Severity
Suggested severity: High.
Suggested Fix
Normalize and validate the actual workflow tool graph before recipe execution:
- Parse the selected workflow file before or during
_check_tool_policy(). - Include
workflow.yaml agents.*.tools,roles.*.tools, included recipes, and other workflow-resolved tool lists in the dangerous-tool policy. - Treat
approve:as an operator-supplied approval policy, not a recipe-controlled bypass of the recipe-level dangerous-tool gate. - If
approve:remains recipe-controlled, ignore dangerous/default-denied tool entries unless the caller passedallow_dangerous_tools=Trueor an explicit external policy allowed that exact tool. - Add regression tests for:
- dangerous tool in
TEMPLATE.yaml requires.toolsis denied; - dangerous tool in
workflow.yaml agents.*.toolsis also denied; approve: [execute_command]does not bypass the recipe policy;allow_dangerous_tools=Truekeeps the intended opt-in behavior.
Affected Package/Versions
- Repository:
MervinPraison/PraisonAI - Package:
praisonai - Components:
src/praisonai/praisonai/recipe/core.pysrc/praisonai/praisonai/recipe/models.pysrc/praisonai-agents/praisonaiagents/workflows/yaml_parser.pysrc/praisonai-agents/praisonaiagents/workflows/workflows.pysrc/praisonai-agents/praisonaiagents/approval/registry.py
Validated affected:
- current main
2f9677abb2ea68eab864ee8b6a828fd0141612e1 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.
Advisory History
Checked visible PraisonAI advisories and prior submissions for the same root cause, affected entrypoint, and exploit preconditions. No exact duplicate is identified in this report text. Adjacent advisories, where relevant, are listed in References or discussed above.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "praisonai"
},
"ranges": [
{
"events": [
{
"introduced": "4.5.87"
},
{
"fixed": "4.6.61"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-57142"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-863",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T14:26:57Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nPraisonAI recipe execution has a dangerous-tool policy that is supposed to block default-denied tools unless the caller explicitly passes `allow_dangerous_tools=True`. That policy only checks tools declared in `TEMPLATE.yaml` `requires.tools`.\n\nFor steps-based recipes, the actual execution path loads `workflow.yaml` with `YAMLWorkflowParser`. That parser resolves agent-level `tools:` declarations and preserves top-level `approve:`. `Workflow.start()` then installs those YAML-approved tools into the approval context.\n\nAs a result, an untrusted recipe can omit `execute_command` from `TEMPLATE.yaml requires.tools`, declare it in `workflow.yaml agents.*.tools`, and add top-level `approve: [execute_command]`. The caller did not set `allow_dangerous_tools=True`, but the recipe policy allows the recipe and the workflow approval path self-approves the critical shell tool.\n\nThe local PoV uses a harmless `printf` canary and explicitly unsets `PRAISONAI_AUTO_APPROVE`.\n\n## Technical Details\n\n`recipe.run()` checks the recipe policy unless `options[\"allow_dangerous_tools\"]` is true. `_check_tool_policy()` gets the required tool list from `recipe_config.get_required_tools()`, which is backed by `TEMPLATE.yaml` `requires.tools`.\n\nThe steps workflow execution path is separate:\n\n1. `_execute_steps_workflow()` parses the workflow file with `YAMLWorkflowParser`.\n2. `YAMLWorkflowParser` resolves `agents.*.tools`.\n3. The same parser reads top-level `approve:` and stores it on `workflow.approve_tools`.\n4. `Workflow.start()` calls `set_yaml_approved_tools(approve_tools)`.\n5. The approval registry treats YAML-approved tools as approved.\n\n`execute_command` is listed as a default dangerous tool with `critical` risk and is decorated with `@require_approval(risk_level=\"critical\")`. The policy gap is that recipe-level dangerous-tool enforcement does not inspect the workflow file that actually supplies and approves the tool.\n\n### Why This Is Not Intended Behavior\n\nYAML `approve:` is an intended feature. This report is not claiming that workflow-level approval is inherently unintended.\n\nThe unintended behavior is that the recipe dangerous-tool policy exposes an operator-facing explicit override, `allow_dangerous_tools=True`, but a recipe can avoid that policy by moving the dangerous tool declaration from `TEMPLATE.yaml requires.tools` into the steps workflow. The recipe still runs through the standard recipe runner path, and the same workflow can self-approve the critical tool.\n\nThis conflicts with the documented safety model:\n\n- PraisonAI\u0027s approval docs describe approval as pausing an agent before a risky tool and asking a human or configured channel to allow or deny it.\n- The SDK approval docs describe a human-in-the-loop approval system for dangerous tool operations.\n- Security-environment documentation describes opt-in access for potentially dangerous operations and secure defaults for RCE prevention.\n- Policy-engine documentation describes policies that block dangerous operations and require approval for sensitive actions.\n\nA control recipe that declares `requires.tools: [execute_command]` is denied with:\n\n```text\nTool \u0027execute_command\u0027 is denied by default. Use allow_dangerous_tools=True to override.\n```\n\nThe bypass recipe uses the same tool but omits it from `requires.tools`; it passes policy and reaches the recipe runner\u0027s dry-run state.\n\n## PoV\n\nRun:\n\n```bash\npython3 poc/poc.py\n```\n\nExpected output:\n\n```json\n{\n \"ok\": true,\n \"control_policy\": \"Tool \u0027execute_command\u0027 is denied by default. Use allow_dangerous_tools=True to override.\",\n \"control_recipe_status\": \"policy_denied\",\n \"bypass_policy\": null,\n \"bypass_recipe_dry_run_status\": \"dry_run\",\n \"workflow_approve_tools\": [\n \"execute_command\"\n ],\n \"runner_tool_names\": [\n \"execute_command\"\n ],\n \"command_stdout\": \"poc\",\n \"operator_env_auto_approve\": null\n}\n```\n\nThe PoV creates two temporary recipes:\n\n1. A control recipe with `TEMPLATE.yaml requires.tools: [execute_command]`. `recipe.run()` returns `policy_denied`.\n2. A bypass recipe with no dangerous tools in `TEMPLATE.yaml`, but with `workflow.yaml` declaring `execute_command` under an agent and `approve: [execute_command]`. `recipe.run(..., dry_run=True)` reaches `dry_run`, and the same parser/approval context permits a harmless `printf poc.\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nIf an operator runs an untrusted recipe, or exposes the recipe runner to users who can choose recipe names/URIs, the recipe can self-authorize a default-denied critical shell tool without the operator setting `allow_dangerous_tools=True`.\n\nSuccessful exploitation lets the workflow run `execute_command` with the privileges of the PraisonAI process if the agent reaches the tool call. The exact trigger depends on the workflow and model/tool-call path, but the policy boundary is already bypassed before execution.\n\nThis can affect both local CLI use and HTTP recipe-runner deployments. The HTTP recipe runner defaults to localhost/no-auth and requires auth for non-localhost binding, so this report uses local/UI-required severity rather than claiming an unauthenticated network RCE by default.\n\nThe local HTTP sidecar documentation also frames the sidecar as a localhost REST API for local/polyglot integration. If a deployment exposes that API to authenticated users who can choose recipe names or URIs, the same policy bypass can become an authenticated remote recipe-execution issue, but that is not the default severity claim.\n\n### Severity\n\nSuggested severity: High.\n\n## Suggested Fix\n\nNormalize and validate the actual workflow tool graph before recipe execution:\n\n- Parse the selected workflow file before or during `_check_tool_policy()`.\n- Include `workflow.yaml agents.*.tools`, `roles.*.tools`, included recipes, and other workflow-resolved tool lists in the dangerous-tool policy.\n- Treat `approve:` as an operator-supplied approval policy, not a recipe-controlled bypass of the recipe-level dangerous-tool gate.\n- If `approve:` remains recipe-controlled, ignore dangerous/default-denied tool entries unless the caller passed `allow_dangerous_tools=True` or an explicit external policy allowed that exact tool.\n- Add regression tests for:\n - dangerous tool in `TEMPLATE.yaml requires.tools` is denied;\n - dangerous tool in `workflow.yaml agents.*.tools` is also denied;\n - `approve: [execute_command]` does not bypass the recipe policy;\n - `allow_dangerous_tools=True` keeps the intended opt-in behavior.\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Package: `praisonai`\n- Components:\n - `src/praisonai/praisonai/recipe/core.py`\n - `src/praisonai/praisonai/recipe/models.py`\n - `src/praisonai-agents/praisonaiagents/workflows/yaml_parser.py`\n - `src/praisonai-agents/praisonaiagents/workflows/workflows.py`\n - `src/praisonai-agents/praisonaiagents/approval/registry.py`\n\nValidated affected:\n\n- current main `2f9677abb2ea68eab864ee8b6a828fd0141612e1`\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 tested workflow path due an unrelated `praisonaiagents.output.models` import error. They are not claimed fixed or unaffected.\n\n## Advisory History\n\nChecked visible PraisonAI advisories and prior submissions for the same root cause, affected entrypoint, and exploit preconditions. No exact duplicate is identified in this report text. Adjacent advisories, where relevant, are listed in References or discussed above.",
"id": "GHSA-7qw2-w5rc-37x2",
"modified": "2026-07-20T21:28:14Z",
"published": "2026-06-18T14:26:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-7qw2-w5rc-37x2"
},
{
"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 workflow policy can be bypassed by declaring and YAML-approving dangerous tools outside TEMPLATE.yaml"
}
GHSA-7QW5-PQHC-XM4G
Vulnerability from github – Published: 2020-09-10 19:19 – Updated: 2021-11-19 15:29Impact
Any user with SCRIPT right (EDIT right before XWiki 7.4) can gain access to the application server Servlet context which contains tools allowing to instantiate arbitrary Java objects and invoke methods that may lead to arbitrary code execution.
Patches
It has been patched in both version XWiki 12.2.1 and XWiki 11.10.5.
Workarounds
The only workaround is to give SCRIPT right only to trusted users.
References
https://jira.xwiki.org/browse/XWIKI-17141 https://jira.xwiki.org/browse/XWIKI-17266
It's been reported by the GitHub Security Lab under #GHSL-2020-046.
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira XWiki * Email us at our security mailing list
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.10.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-oldcore"
},
"ranges": [
{
"events": [
{
"introduced": "12.0.0"
},
{
"fixed": "12.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-15171"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2020-09-10T19:18:59Z",
"nvd_published_at": "2020-09-10T20:15:00Z",
"severity": "LOW"
},
"details": "### Impact\n\nAny user with SCRIPT right (EDIT right before XWiki 7.4) can gain access to the application server Servlet context which contains tools allowing to instantiate arbitrary Java objects and invoke methods that may lead to arbitrary code execution.\n\n### Patches\n\nIt has been patched in both version XWiki 12.2.1 and XWiki 11.10.5.\n\n### Workarounds\n\nThe only workaround is to give SCRIPT right only to trusted users.\n\n### References\n\nhttps://jira.xwiki.org/browse/XWIKI-17141\nhttps://jira.xwiki.org/browse/XWIKI-17266\n\nIt\u0027s been reported by the GitHub Security Lab under #GHSL-2020-046.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki](https://jira.xwiki.org)\n* Email us at [our security mailing list](mailto:security@xwiki.org)",
"id": "GHSA-7qw5-pqhc-xm4g",
"modified": "2021-11-19T15:29:44Z",
"published": "2020-09-10T19:19:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-7qw5-pqhc-xm4g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-15171"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Users with SCRIPT right can execute arbitrary code in XWiki"
}
GHSA-7QW8-88J7-X8GR
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2022-05-24 16:44A potential security vulnerability has been identified in Micro Focus Network Automation Software 9.20, 9.21, 10.00, 10.10, 10.20, 10.30, 10.40, 10.50, 2018.05, 2018.08, 2018.11, and Micro Focus Network Operations Management (NOM) all versions. The vulnerability could be remotely exploited to Remote Code Execution.
{
"affected": [],
"aliases": [
"CVE-2019-3493"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-29T16:29:00Z",
"severity": "HIGH"
},
"details": "A potential security vulnerability has been identified in Micro Focus Network Automation Software 9.20, 9.21, 10.00, 10.10, 10.20, 10.30, 10.40, 10.50, 2018.05, 2018.08, 2018.11, and Micro Focus Network Operations Management (NOM) all versions. The vulnerability could be remotely exploited to Remote Code Execution.",
"id": "GHSA-7qw8-88j7-x8gr",
"modified": "2022-05-24T16:44:53Z",
"published": "2022-05-24T16:44:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3493"
},
{
"type": "WEB",
"url": "https://softwaresupport.softwaregrp.com/doc/KM03407763"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7QWG-FCPW-XG5G
Vulnerability from github – Published: 2024-06-05 15:10 – Updated: 2024-06-05 15:10Failing to properly dissociate system related configuration from user generated configuration, the Form Framework (system extension "form") is vulnerable to SQL injection and Privilege Escalation. Basically instructions can be persisted to a form definition file that were not configured to be modified - this applies to definitions managed using the form editor module as well as direct file upload using the regular file list module. A valid backend user account as well as having system extension form activated are needed in order to exploit this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms"
},
"ranges": [
{
"events": [
{
"introduced": "8.5.0"
},
{
"fixed": "8.7.17"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "typo3/cms"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-05T15:10:19Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Failing to properly dissociate system related configuration from user generated configuration, the Form Framework (system extension \"form\") is vulnerable to SQL injection and Privilege Escalation. Basically instructions can be persisted to a form definition file that were not configured to be modified - this applies to definitions managed using the form editor module as well as direct file upload using the regular file list module. A valid backend user account as well as having system extension form activated are needed in order to exploit this vulnerability.",
"id": "GHSA-7qwg-fcpw-xg5g",
"modified": "2024-06-05T15:10:19Z",
"published": "2024-06-05T15:10:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms/2018-07-12-3.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/TYPO3/typo3"
},
{
"type": "WEB",
"url": "https://typo3.org/security/advisory/typo3-core-sa-2018-003"
}
],
"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": "Privilege Escalation \u0026 SQL Injection in TYPO3 CMS"
}
GHSA-7R2F-G5XQ-C5M7
Vulnerability from github – Published: 2022-05-02 03:52 – Updated: 2022-05-02 03:52The Indeo codec in Microsoft Windows 2000 SP4, XP SP2 and SP3, and Server 2003 SP2 allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via crafted media content.
{
"affected": [],
"aliases": [
"CVE-2009-4210"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-12-13T01:30:00Z",
"severity": "HIGH"
},
"details": "The Indeo codec in Microsoft Windows 2000 SP4, XP SP2 and SP3, and Server 2003 SP2 allows remote attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact via crafted media content.",
"id": "GHSA-7r2f-g5xq-c5m7",
"modified": "2022-05-02T03:52:42Z",
"published": "2022-05-02T03:52:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-4210"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/54644"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/54645"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11677"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/37592"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1023302"
},
{
"type": "WEB",
"url": "http://support.microsoft.com/kb/954157"
},
{
"type": "WEB",
"url": "http://support.microsoft.com/kb/955759"
},
{
"type": "WEB",
"url": "http://support.microsoft.com/kb/976138"
},
{
"type": "WEB",
"url": "http://www.fortiguard.com/advisory/FGA-2009-45.html"
},
{
"type": "WEB",
"url": "http://www.microsoft.com/technet/security/advisory/954157.mspx"
},
{
"type": "WEB",
"url": "http://www.osvdb.org/60857"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/508323/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/37251"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/3440"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7R2W-QGMH-R769
Vulnerability from github – Published: 2022-05-17 04:45 – Updated: 2022-05-17 04:45The PlRPC module, possibly 0.2020 and earlier, for Perl uses the Storable module, which allows remote attackers to execute arbitrary code via a crafted request, which is not properly handled when it is deserialized.
{
"affected": [],
"aliases": [
"CVE-2013-7284"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2014-04-29T14:38:00Z",
"severity": "MODERATE"
},
"details": "The PlRPC module, possibly 0.2020 and earlier, for Perl uses the Storable module, which allows remote attackers to execute arbitrary code via a crafted request, which is not properly handled when it is deserialized.",
"id": "GHSA-7r2w-qgmh-r769",
"modified": "2022-05-17T04:45:23Z",
"published": "2022-05-17T04:45:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-7284"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734789"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1030572"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1051108"
},
{
"type": "WEB",
"url": "https://rt.cpan.org/Public/Bug/Display.html?id=90474"
},
{
"type": "WEB",
"url": "http://seclists.org/oss-sec/2014/q1/56"
},
{
"type": "WEB",
"url": "http://seclists.org/oss-sec/2014/q1/62"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.