CWE-470
AllowedUse 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:31A remote, authenticated, non-admin Craft CMS Control Panel user with only the accessCp permission can execute operating system commands as the PHP web worker.
{
"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:31In 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.
{
"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:30In 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.
{
"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:30An 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.
{
"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:59Summary
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:
[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)asserts that a defaultAgenthas_perm_allow is None.test_permissions.pyexplicitly checks thatagent._check_tool_approval_sync("my_custom_tool", {})passes for an undeclared tool name.
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.
{
"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:30Microsoft 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.
{
"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:33The 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.
{
"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:25A 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.
{
"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:35A 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.
{
"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:29Impact
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.
{
"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
Refactor your code to avoid using reflection.
Mitigation
Do not use user-controlled inputs to select and load classes or code.
Mitigation
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.