Common Weakness Enumeration

CWE-470

Allowed

Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')

Abstraction: Base · Status: Draft

The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.

212 vulnerabilities reference this CWE, most recent first.

GHSA-FPMM-W3HP-7F39

Vulnerability from github – Published: 2026-09-10 18:31 – Updated: 2026-09-10 18:31
VLAI
Details

A remote, authenticated, non-admin Craft CMS Control Panel user with only the accessCp permission can execute operating system commands as the PHP web worker.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-79987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-10T16:17:56Z",
    "severity": "HIGH"
  },
  "details": "A remote, authenticated, non-admin Craft CMS Control Panel user with only the\u00a0accessCp\u00a0permission can execute operating system commands as the PHP web worker.",
  "id": "GHSA-fpmm-w3hp-7f39",
  "modified": "2026-09-10T18:31:44Z",
  "published": "2026-09-10T18:31:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-9c4j-cjw3-r3xx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79987"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/releases/tag/5.10.13"
    },
    {
      "type": "WEB",
      "url": "https://www.hckrt.com/hacktivity/HCKRT-9TSYY2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FXCW-5G46-3PJV

Vulnerability from github – Published: 2024-10-09 15:32 – Updated: 2025-11-03 21:31
VLAI
Details

In Progress Telerik Reporting versions prior to 2024 Q3 (18.2.24.924), a code execution attack is possible using object injection via insecure expression evaluation.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-8048"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-09T15:15:17Z",
    "severity": "HIGH"
  },
  "details": "In Progress Telerik Reporting versions prior to 2024 Q3 (18.2.24.924), a code execution attack is possible using object injection via insecure expression evaluation.",
  "id": "GHSA-fxcw-5g46-3pjv",
  "modified": "2025-11-03T21:31:15Z",
  "published": "2024-10-09T15:32:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8048"
    },
    {
      "type": "WEB",
      "url": "https://docs.telerik.com/reporting/knowledge-base/insecure-expression-evaluation-cve-2024-8048"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250425-0004"
    }
  ],
  "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"
    }
  ]
}

GHSA-G2M5-6X74-9MV6

Vulnerability from github – Published: 2024-07-24 15:31 – Updated: 2025-04-26 00:30
VLAI
Details

In Progress® Telerik® Reporting versions prior to 18.1.24.709, a code execution attack is possible through object injection via an insecure type resolution vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-6096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-24T14:15:06Z",
    "severity": "HIGH"
  },
  "details": "In Progress\u00ae Telerik\u00ae Reporting versions prior to 18.1.24.709, a code execution attack is possible through object injection via an insecure type resolution vulnerability.",
  "id": "GHSA-g2m5-6x74-9mv6",
  "modified": "2025-04-26T00:30:23Z",
  "published": "2024-07-24T15:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6096"
    },
    {
      "type": "WEB",
      "url": "https://docs.telerik.com/reporting/knowledge-base/unsafe-reflection-CVE-2024-6096"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20250425-0003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G39R-HH73-78XJ

Vulnerability from github – Published: 2024-01-16 21:31 – Updated: 2024-01-23 21:30
VLAI
Details

An unsafe reflection vulnerability was identified in GitHub Enterprise Server that could lead to reflection injection. This vulnerability could lead to the execution of user-controlled methods and remote code execution. To exploit this bug, an actor would need to be logged into an account on the GHES instance with the organization owner role. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.12 and was fixed in versions 3.8.13, 3.9.8, 3.10.5, and 3.11.3. This vulnerability was reported via the GitHub Bug Bounty program.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-0200"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-16T19:15:08Z",
    "severity": "HIGH"
  },
  "details": "An unsafe reflection vulnerability was identified in GitHub Enterprise Server that could lead to reflection injection. This vulnerability\u00a0could lead to the execution of user-controlled methods and remote code execution. To\u00a0exploit this bug, an actor would need to be logged into an account on the GHES instance with the organization owner role.\u00a0This vulnerability affected all versions of GitHub Enterprise Server prior to 3.12 and was fixed in versions 3.8.13, 3.9.8, 3.10.5, and 3.11.3. This vulnerability was reported via the GitHub Bug Bounty program.\n\n",
  "id": "GHSA-g39r-hh73-78xj",
  "modified": "2024-01-23T21:30:20Z",
  "published": "2024-01-16T21:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0200"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.10/admin/release-notes#3.10.5"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.3"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.8/admin/release-notes#3.8.13"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.9/admin/release-notes#3.9.8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GMJG-HV98-QGGQ

Vulnerability from github – Published: 2026-05-11 13:59 – Updated: 2026-05-11 13:59
VLAI
Summary
PraisonAI has unsafe tool resolution in `ToolExecutionMixin.execute_tool`: undeclared `__main__` callables execute
Details

Summary

praisonaiagents resolves unresolved tool names against module globals and __main__ after it fails to match the declared tool list and the registry. With the default agent configuration, _perm_allow is None, so undeclared non-dangerous tool names are not rejected by the permission gate. An attacker who can influence tool-call names can therefore invoke unintended application callables that were never declared as tools.

Details

The vulnerable resolution path is in [tool_execution.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/tool_execution.py:734). After searching declared tools and the registry, execution falls back to globals() and then __main__:

func = None
for tool in self.tools if isinstance(self.tools, (list, tuple)) else []:
    ...

if func is None:
    try:
        from ..tools.registry import get_registry
        registry = get_registry()
        func = registry.get(function_name)
    except ImportError:
        pass

if func is None:
    func = globals().get(function_name)
    if not func:
        import __main__
        func = getattr(__main__, function_name, None)

If a callable is found, it is executed directly:

elif callable(func):
    casted_arguments = self._cast_arguments(func, arguments)
    return func(**casted_arguments)

The permission gate does not enforce a declared-tool allowlist by default. In [tool_execution.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/tool_execution.py:550), execution is only rejected if _perm_allow is non-None:

if self._perm_deny and function_name in self._perm_deny:
    return {"error": f"Tool '{function_name}' blocked by permission policy", "permission_denied": True}
if self._perm_allow is not None and function_name not in self._perm_allow:
    return {"error": f"Tool '{function_name}' not in allowed tools list", "permission_denied": True}

Default agent initialization sets _perm_allow = None, which means "allow all" rather than "allow only declared tools" in [agent.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/agent.py:1749):

self._perm_deny = frozenset()  # Permission tier deny set (empty = no denials)
self._perm_allow = None        # Permission tier allow set (None = allow all)

The project's own tests confirm that default agents have no allowlist and that undeclared custom tool names pass approval:

Empirical verification:

I verified the bypass locally on commit d8a8a786915dc67a7c3021e24f72458f2eac5d9c (v4.6.35) by defining a callable only in __main__, giving the agent an empty tools list, and invoking execute_tool() with that undeclared name. The tool executor ran the __main__ function anyway.

PoC

Environment - Repo: MervinPraison/PraisonAI - Commit: d8a8a786915dc67a7c3021e24f72458f2eac5d9c - Verified against PyPI package versions available on May 3, 2026: - praisonaiagents 1.6.35 - PraisonAI 4.6.35 - Python 3

Steps 1. From the repository root, run:

python3 - <<'PY'
import sys
from unittest.mock import MagicMock, patch

sys.path.insert(0, '/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents')
from praisonaiagents.agent.tool_execution import ToolExecutionMixin

def sneaky(msg='ok'):
    return {'ran': msg}

class HookRunner:
    def execute_sync(self, *args, **kwargs):
        return []
    def is_blocked(self, results):
        return False

class Dummy(ToolExecutionMixin):
    def __init__(self):
        self.name = 'demo'
        self.tools = []
        self.chat_history = []
        self._hook_runner = HookRunner()
        self.context_manager = None
        self._doom_loop_tracker = None
        self._perm_deny = frozenset()
        self._perm_allow = None
        self._approval_backend = None

mock_registry = MagicMock()
mock_registry.approve_sync.return_value = MagicMock(approved=True, reason='mock', modified_args=None)
mock_registry.mark_approved = MagicMock()

with patch('praisonaiagents.approval.get_approval_registry', return_value=mock_registry):
    agent = Dummy()
    print(agent.execute_tool('sneaky', {'msg': 'hello'}))
    print(mock_registry.approve_sync.call_args)
PY

Expected output

{'ran': 'hello'}
call('demo', 'sneaky', {'msg': 'hello'})

The important point is that sneaky was never declared in self.tools and was only present in __main__.

Impact

  • Any deployment that lets an untrusted party influence tool-call names: undeclared application callables can run even though they were never registered as tools.
  • Operators who rely on the declared tool list as a security boundary: that boundary is broken because unresolved names fall through to globals() and __main__.
  • Applications that keep privileged helper functions in process scope: the attacker can reuse those helpers with the application's own privileges, which can lead to unauthorized state changes and, depending on what is loaded, data exposure or command execution.
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.36"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonaiagents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.37"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.6.36"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "PraisonAI"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.6.37"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-11T13:59:17Z",
    "nvd_published_at": "2026-05-08T14:16:46Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n`praisonaiagents` resolves unresolved tool names against module globals and `__main__` after it fails to match the declared tool list and the registry. With the default agent configuration, `_perm_allow` is `None`, so undeclared non-dangerous tool names are not rejected by the permission gate. An attacker who can influence tool-call names can therefore invoke unintended application callables that were never declared as tools.\n\n### Details\nThe vulnerable resolution path is in [`[tool_execution.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/tool_execution.py:734)`](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/tool_execution.py:734). After searching declared tools and the registry, execution falls back to `globals()` and then `__main__`:\n\n```python\nfunc = None\nfor tool in self.tools if isinstance(self.tools, (list, tuple)) else []:\n    ...\n\nif func is None:\n    try:\n        from ..tools.registry import get_registry\n        registry = get_registry()\n        func = registry.get(function_name)\n    except ImportError:\n        pass\n\nif func is None:\n    func = globals().get(function_name)\n    if not func:\n        import __main__\n        func = getattr(__main__, function_name, None)\n```\n\nIf a callable is found, it is executed directly:\n\n```python\nelif callable(func):\n    casted_arguments = self._cast_arguments(func, arguments)\n    return func(**casted_arguments)\n```\n\nThe permission gate does not enforce a declared-tool allowlist by default. In [`[tool_execution.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/tool_execution.py:550)`](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/tool_execution.py:550), execution is only rejected if `_perm_allow` is non-`None`:\n\n```python\nif self._perm_deny and function_name in self._perm_deny:\n    return {\"error\": f\"Tool \u0027{function_name}\u0027 blocked by permission policy\", \"permission_denied\": True}\nif self._perm_allow is not None and function_name not in self._perm_allow:\n    return {\"error\": f\"Tool \u0027{function_name}\u0027 not in allowed tools list\", \"permission_denied\": True}\n```\n\nDefault agent initialization sets `_perm_allow = None`, which means \"allow all\" rather than \"allow only declared tools\" in [`[agent.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/agent.py:1749)`](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/praisonaiagents/agent/agent.py:1749):\n\n```python\nself._perm_deny = frozenset()  # Permission tier deny set (empty = no denials)\nself._perm_allow = None        # Permission tier allow set (None = allow all)\n```\n\nThe project\u0027s own tests confirm that default agents have no allowlist and that undeclared custom tool names pass approval:\n\n- [`[test_permissions.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/tests/unit/test_permissions.py:56)`](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/tests/unit/[test_permissions.py](https://github.com/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/tests/unit/test_permissions.py:142):56) asserts that a default `Agent` has `_perm_allow is None`.\n- [`test_permissions.py`](/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents/tests/unit/test_permissions.py:142) explicitly checks that `agent._check_tool_approval_sync(\"my_custom_tool\", {})` passes for an undeclared tool name.\n\n**Empirical verification:**\n\nI verified the bypass locally on commit `d8a8a786915dc67a7c3021e24f72458f2eac5d9c` (`v4.6.35`) by defining a callable only in `__main__`, giving the agent an empty `tools` list, and invoking `execute_tool()` with that undeclared name. The tool executor ran the `__main__` function anyway.\n\n### PoC\n**Environment**\n- Repo: `MervinPraison/PraisonAI`\n- Commit: `d8a8a786915dc67a7c3021e24f72458f2eac5d9c`\n- Verified against PyPI package versions available on May 3, 2026:\n  - `praisonaiagents` `1.6.35`\n  - `PraisonAI` `4.6.35`\n- Python 3\n\n**Steps**\n1. From the repository root, run:\n\n```bash\npython3 - \u003c\u003c\u0027PY\u0027\nimport sys\nfrom unittest.mock import MagicMock, patch\n\nsys.path.insert(0, \u0027/Users/shmulc/Documents/Codex/2026-05-03/please-go-over-tmp-tp-advisories/repos/PraisonAI/src/praisonai-agents\u0027)\nfrom praisonaiagents.agent.tool_execution import ToolExecutionMixin\n\ndef sneaky(msg=\u0027ok\u0027):\n    return {\u0027ran\u0027: msg}\n\nclass HookRunner:\n    def execute_sync(self, *args, **kwargs):\n        return []\n    def is_blocked(self, results):\n        return False\n\nclass Dummy(ToolExecutionMixin):\n    def __init__(self):\n        self.name = \u0027demo\u0027\n        self.tools = []\n        self.chat_history = []\n        self._hook_runner = HookRunner()\n        self.context_manager = None\n        self._doom_loop_tracker = None\n        self._perm_deny = frozenset()\n        self._perm_allow = None\n        self._approval_backend = None\n\nmock_registry = MagicMock()\nmock_registry.approve_sync.return_value = MagicMock(approved=True, reason=\u0027mock\u0027, modified_args=None)\nmock_registry.mark_approved = MagicMock()\n\nwith patch(\u0027praisonaiagents.approval.get_approval_registry\u0027, return_value=mock_registry):\n    agent = Dummy()\n    print(agent.execute_tool(\u0027sneaky\u0027, {\u0027msg\u0027: \u0027hello\u0027}))\n    print(mock_registry.approve_sync.call_args)\nPY\n```\n\n**Expected output**\n```text\n{\u0027ran\u0027: \u0027hello\u0027}\ncall(\u0027demo\u0027, \u0027sneaky\u0027, {\u0027msg\u0027: \u0027hello\u0027})\n```\n\nThe important point is that `sneaky` was never declared in `self.tools` and was only present in `__main__`.\n\n### Impact\n- **Any deployment that lets an untrusted party influence tool-call names**: undeclared application callables can run even though they were never registered as tools.\n- **Operators who rely on the declared tool list as a security boundary**: that boundary is broken because unresolved names fall through to `globals()` and `__main__`.\n- **Applications that keep privileged helper functions in process scope**: the attacker can reuse those helpers with the application\u0027s own privileges, which can lead to unauthorized state changes and, depending on what is loaded, data exposure or command execution.",
  "id": "GHSA-gmjg-hv98-qggq",
  "modified": "2026-05-11T13:59:17Z",
  "published": "2026-05-11T13:59:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-gmjg-hv98-qggq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44339"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI has unsafe tool resolution in `ToolExecutionMixin.execute_tool`: undeclared `__main__` callables execute"
}

GHSA-GWR9-Q5W7-G798

Vulnerability from github – Published: 2026-04-04 15:30 – Updated: 2026-04-04 21:30
VLAI
Details

Microsoft Smart VPN 1.1.3.0 contains a denial of service vulnerability that allows local attackers to crash the application by submitting oversized input through the search interface. Attackers can paste a buffer of 2100 characters into the top right search bar to trigger an unhandled exception that crashes the application.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-25239"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-04T14:16:19Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Smart VPN 1.1.3.0 contains a denial of service vulnerability that allows local attackers to crash the application by submitting oversized input through the search interface. Attackers can paste a buffer of 2100 characters into the top right search bar to trigger an unhandled exception that crashes the application.",
  "id": "GHSA-gwr9-q5w7-g798",
  "modified": "2026-04-04T21:30:26Z",
  "published": "2026-04-04T15:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-25239"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/46272"
    },
    {
      "type": "WEB",
      "url": "https://www.microsoft.com/store/productId/9NH1G93D4HKR"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/microsoft-smart-vpn-denial-of-service-via-search"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/smart-vpn-denial-of-service-via-search"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-GWWH-WV9X-J72W

Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2024-04-04 05:33
VLAI
Details

The YouTube Embedded 1.2 SDK binds to a service within the YouTube Main App. After binding, a remote context is created with the flags Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY. This allows the client app to remotely load code from YouTube Main App by retrieving the Main App’s ClassLoader. A potential vulnerability in the binding logic used by the client SDK where the SDK ends up calling bindService() on a malicious app rather than YT Main App. This creates a vulnerability where the SDK can load the malicious app’s ClassLoader instead, allowing the malicious app to load arbitrary code into the calling app whenever the embedded SDK is invoked. In order to trigger this vulnerability, an attacker must masquerade the Youtube app and install it on a device, have a second app that uses the Embedded player and typically distribute both to the victim outside of the Play Store.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-0460"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-01T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "The YouTube Embedded 1.2 SDK binds to a service within the YouTube Main App. After binding, a remote context is created with the flags Context.CONTEXT_INCLUDE_CODE | Context.CONTEXT_IGNORE_SECURITY. This allows the client app to remotely load code from YouTube Main App by retrieving the Main App\u2019s ClassLoader. A potential vulnerability in the binding logic used by the client SDK where the SDK ends up calling bindService() on a malicious app rather than YT Main App. This creates a vulnerability where the SDK can load the malicious app\u2019s ClassLoader instead, allowing the malicious app to load arbitrary code into the calling app whenever the embedded SDK is invoked. In order to trigger this vulnerability, an attacker must masquerade the Youtube app and install it on a device, have a second app that uses the Embedded player and typically distribute both to the victim outside of the Play Store.",
  "id": "GHSA-gwwh-wv9x-j72w",
  "modified": "2024-04-04T05:33:48Z",
  "published": "2023-07-06T19:24:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0460"
    },
    {
      "type": "WEB",
      "url": "https://developers.google.com/youtube/android/player/downloads"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H47X-2J37-FW5M

Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-06-29 13:25
VLAI
Summary
Use of Externally-Controlled Input to Select Classes or Code in Infinispan
Details

A vulnerability was found in Infinispan such that the invokeAccessibly method from the public class ReflectionUtil allows any application class to invoke private methods in any class with Infinispan's privileges. The attacker can use reflection to introduce new, malicious behavior into the application.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 8.2.11.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.infinispan:infinispan-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.2.12.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.4.16.Final"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.infinispan:infinispan-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0.Final"
            },
            {
              "fixed": "9.4.17.Final"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10174"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-06-29T13:25:50Z",
    "nvd_published_at": "2019-11-25T11:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was found in Infinispan such that the invokeAccessibly method from the public class ReflectionUtil allows any application class to invoke private methods in any class with Infinispan\u0027s privileges. The attacker can use reflection to introduce new, malicious behavior into the application.",
  "id": "GHSA-h47x-2j37-fw5m",
  "modified": "2022-06-29T13:25:50Z",
  "published": "2022-05-24T17:01:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10174"
    },
    {
      "type": "WEB",
      "url": "https://github.com/infinispan/infinispan/commit/5dbb05cfaca01a1a66732b82a0f5ba615ccbd214"
    },
    {
      "type": "WEB",
      "url": "https://github.com/infinispan/infinispan/commit/7bdc2822ccf79127a488130239c49a5e944e3ca2"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0481"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2020:0727"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-10174"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/infinispan/infinispan"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20220210-0018"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Use of Externally-Controlled Input to Select Classes or Code in Infinispan"
}

GHSA-H4JP-RW7W-8X59

Vulnerability from github – Published: 2024-11-05 15:30 – Updated: 2024-11-10 00:35
VLAI
Details

A high-severity vulnerability that can lead to arbitrary code execution on the system hosting the Web SDK role was found in the Genetec Security Center product line.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-7059"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-11-05T13:15:03Z",
    "severity": "HIGH"
  },
  "details": "A high-severity vulnerability that can lead to arbitrary code execution on the system hosting the Web SDK role was found in the Genetec Security Center product line.",
  "id": "GHSA-h4jp-rw7w-8x59",
  "modified": "2024-11-10T00:35:34Z",
  "published": "2024-11-05T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7059"
    },
    {
      "type": "WEB",
      "url": "https://resources.genetec.com/security-advisories"
    },
    {
      "type": "WEB",
      "url": "https://resources.genetec.com/security-advisories/high-severity-vulnerability-affecting-security-center-web-sdk-role"
    },
    {
      "type": "WEB",
      "url": "https://ressources.genetec.com/bulletins-de-securite/vulnerabilite-de-haute-severite-affectant-le-role-sdk-web-de-security-center"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-H84G-69H7-MW6V

Vulnerability from github – Published: 2026-08-14 19:29 – Updated: 2026-08-14 19:29
VLAI
Summary
mchange-commons-java contains elements susceptible to abuse via JNDI injection and "deserialization gadgets"
Details

Impact

Prior to version 0.6.0, mchange-commons-java includes a JNDI ObjectFactory implementation (com.mchange.v2.naming.JavaBeanObjectFactory) willing to construct objects of arbitrary classes and initialize "JavaBean"-style properties. There are classes for which this kind of initialization is unsafe. For example, setting the "contentType" property of a Swing JEditorPane to text/html and the "text" property to HTML containing a stylesheet <link> will provoke an HTTP GET on an arbitrary URL, potentially from within a trusted security domain. This issue is aggravated by mchange-commons-java's ReferenceIndirector, by which malicious JNDI Reference objects could be smuggled in for dereferencing by applications anywhere a Java-serialized object might be read.

Prior to version 0.5.0, the same mchange-commons-java ObjectFactory would interpret BinaryRefAddress elements as Java-serialized objects, and deserialize unexpected objects that potentially execute malicious behavior on initialization. Although this author is unaware of any code within mchange-commons-java itself that can be abused to execute code on deserialization, this mechanism can be used to trigger well-known "deserialization gadget chains" involving other libraries. For example, in JVMs prior to Java 16 with Apache libraries commons-beanutils and commons-collections on the application CLASSPATH, objects can be crafted that will execute arbitrary commands on deserialization. (Thanks to Valerio Mulas for a proof-of-concept.)

Patches

mchange-commons-java v0.5.0 eliminates all support for deserializing Java objects in com.mchange.v2.naming.JavaBeanObjectFactory, unless an application explicitly extends that class to restore it. This prevents mchange-commons-java from enabling JNDI injection to trigger common "deserialization gadgets".

mchange-commons-java v0.6.0 imposes a whitelist upon what classes com.mchange.v2.naming.JavaBeanObjectFactory consents to materialize, preventing the use of maliciously constructed Reference instances to initialize arbitrary, potentially malicious, objects.

mchange-commons-java v0.6.0 disables the ReferenceIndirector mechanism by default. This mechanism has been abused by attackers to inject dangerous JNDI Reference objects by causing an application to deserialize a malicious Java-serialized object. (The functionality remains for applications that need it, gated behind a restrictive configuration parameter. This is "defense-in-depth"; the hardening of JavaBeanObjectFactory on its own should be sufficient to prevent known Reference-based attacks. But perhaps there are other insecure ObjectFactory implementations on the CLASSPATH or vulnerabilities as-yet-unknown.)

Workarounds

Upgrading to the current version of mchange-commons-java is strongly recommended. Most applications that install mchange-commons-java do so to support the c3p0 JDBC Connection pooling library. When upgrading mchange-commons-java, be sure to update c3p0 as well, or better yet, upgrade to c3p0 >=v0.14.0 and bring in a patched mchange-commons-java transitively.

Maintaining rigorous serialization filters can prevent many attacks (but not attacks requiring only construction of a named class and initialization of simple JavaBeans properties, as described for JEditorPane above).

The vulnerabilities that this advisory addresses all begin with arranging for an application to lookup a malicious JNDI Reference or deserialize a malicious Java-serialized object. Assiduously preventing an application from ever encountering such a Reference or serialized object is hypothetically a workaround. But relying upon perfection is usually bad planning.

The most common known attacks rely upon JVM-internal XSLT code that has been made inaccessible on Java 16 and beyond. Running on a more recent JVM is a mitigating workaround.

Resources

The vulnerabilities and security upgrades are documented in c3p0's manual. Please see c3p0's Security Note and Configuring Security.

Credits

mchange-commons-java thanks 4ra1n and unam4 on Github for a proof-of-concept.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.mchange:mchange-commons-java"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55153"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-470"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-14T19:29:20Z",
    "nvd_published_at": "2026-07-01T21:17:03Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nPrior to version 0.6.0, mchange-commons-java includes a JNDI `ObjectFactory` implementation (`com.mchange.v2.naming.JavaBeanObjectFactory`) willing to construct objects of arbitrary classes and initialize \"JavaBean\"-style properties. There are classes for which this kind of initialization is unsafe. For example, setting the \"contentType\" property of a Swing `JEditorPane` to `text/html` and the \"text\" property to HTML containing a stylesheet \u0026lt;link\u0026gt; will provoke an HTTP GET on an arbitrary URL, potentially from within a trusted security domain. This issue is aggravated by mchange-commons-java\u0027s `ReferenceIndirector`, by which malicious JNDI `Reference` objects could be smuggled in for dereferencing by applications anywhere a Java-serialized object might be read. \n\nPrior to version 0.5.0, the same mchange-commons-java `ObjectFactory` would interpret `BinaryRefAddress` elements as Java-serialized objects, and deserialize unexpected objects that potentially execute malicious behavior on initialization. Although this author is unaware of any code within mchange-commons-java itself that can be abused to execute code on deserialization, this mechanism can be used to trigger well-known \"deserialization gadget chains\" involving other libraries. For example, in JVMs prior to Java 16 with Apache libraries [`commons-beanutils`](https://commons.apache.org/proper/commons-beanutils/) and [`commons-collections`](https://commons.apache.org/proper/commons-collections/) on the application `CLASSPATH`, [objects can be crafted](https://gist.github.com/frohoff/9eb8811761ff989b3ac0) that will execute arbitrary commands on deserialization. (Thanks to Valerio Mulas for a proof-of-concept.)\n\n### Patches\nmchange-commons-java v0.5.0 eliminates all support for deserializing Java objects in `com.mchange.v2.naming.JavaBeanObjectFactory`, unless an application explicitly extends that class to restore it. This prevents mchange-commons-java from enabling JNDI injection to trigger common \"deserialization gadgets\".\n\nmchange-commons-java v0.6.0 imposes a whitelist upon what classes `com.mchange.v2.naming.JavaBeanObjectFactory` consents to materialize, preventing the use of maliciously constructed `Reference` instances to initialize arbitrary, potentially malicious, objects.\n\nmchange-commons-java v0.6.0 disables the `ReferenceIndirector` mechanism by default. This mechanism has been abused by attackers to inject dangerous JNDI `Reference` objects by causing an application to deserialize a malicious Java-serialized object. (The functionality remains for applications that need it, gated behind a restrictive configuration parameter. This is \"defense-in-depth\"; the hardening of `JavaBeanObjectFactory` on its own should be sufficient to prevent known `Reference`-based attacks. But perhaps there are other insecure `ObjectFactory` implementations on the `CLASSPATH` or vulnerabilities as-yet-unknown.)\n\n### Workarounds\nUpgrading to the current version of mchange-commons-java is strongly recommended. Most applications that install mchange-commons-java do so to support the c3p0 JDBC Connection pooling library. When upgrading mchange-commons-java, be sure to update c3p0 as well, or better yet, upgrade to c3p0 \u003e=v0.14.0 and bring in a patched mchange-commons-java transitively.\n\nMaintaining rigorous serialization filters can prevent many attacks (but not attacks requiring only construction of a named class and initialization of simple JavaBeans properties, as described for `JEditorPane` above).\n\nThe vulnerabilities that this advisory addresses all begin with arranging for an application to lookup a malicious JNDI `Reference` or deserialize a malicious Java-serialized object. Assiduously preventing an application from ever encountering such a `Reference` or serialized object is hypothetically a workaround. But relying upon perfection is usually bad planning.\n\nThe most common known attacks rely upon JVM-internal XSLT code that has been made inaccessible on Java 16 and beyond. Running on a more recent JVM is a mitigating workaround.\n\n### Resources\nThe vulnerabilities and security upgrades are documented in c3p0\u0027s manual. Please see c3p0\u0027s [Security Note](https://www.mchange.com/projects/c3p0/#security-note) and [Configuring Security](https://www.mchange.com/projects/c3p0/#configuring_security).\n\n### Credits\nmchange-commons-java thanks 4ra1n and unam4 on Github for a proof-of-concept.",
  "id": "GHSA-h84g-69h7-mw6v",
  "modified": "2026-08-14T19:29:20Z",
  "published": "2026-08-14T19:29:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/swaldman/mchange-commons-java/security/advisories/GHSA-h84g-69h7-mw6v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55153"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/swaldman/mchange-commons-java"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "mchange-commons-java contains elements susceptible to abuse via JNDI injection and \"deserialization gadgets\""
}

Mitigation
Architecture and Design

Refactor your code to avoid using reflection.

Mitigation
Architecture and Design

Do not use user-controlled inputs to select and load classes or code.

Mitigation
Implementation

Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.

CAPEC-138: Reflection Injection

An adversary supplies a value to the target application which is then used by reflection methods to identify a class, method, or field. For example, in the Java programming language the reflection libraries permit an application to inspect, load, and invoke classes and their components by name. If an adversary can control the input into these methods including the name of the class/method/field or the parameters passed to methods, they can cause the targeted application to invoke incorrect methods, read random fields, or even to load and utilize malicious classes that the adversary created. This can lead to the application revealing sensitive information, returning incorrect results, or even having the adversary take control of the targeted application.