GHSA-442j-39wm-28r2 — Handlebars.js has a Property Access Validation Bypass in container.lookup

Affected: npm: handlebars

## Summary

In `lib/handlebars/runtime.js`, the `container.lookup()` function uses `container.lookupProperty()` as a gate check to enforce prototype-access controls, but then discards the validated result and performs a second, unguarded property access (`depths[i][name]`). This Time-of-Check Time-of-Use (TOCTOU) pattern means the security check and the actual read are decoupled, and the raw access bypasses any sanitization that `lookupProperty` may perform.

Only relevant when the **compat** compile option is enabled (`{compat: true}`), which activates `depthedLookup` in `lib/handlebars/compiler/javascript-compiler.js`.

## Description

The vulnerable code in `lib/handlebars/runtime.js` (lines 137–144):

```javascript lookup: function (depths, name) { const len = depths.length; for (let i = 0; i < len; i++) { let result = depths[i] && container.lookupProperty(depths[i], name); if (result != null) { return depths[i][name]; // BUG: should be `return result;` } } }, ```

`container.lookupProperty()` (lines 119–136) enforces `hasOwnProperty` checks and `resultIsAllowed()` prototype-access controls. However, `container.lookup()` only uses `lookupProperty` as a boolean gate — if the gate passes (`result != null`), it then performs an independent, raw `depths[i][name]` access that circumvents any transformation or wrapped value that `lookupProperty` may have returned.

## Workarounds

- Avoid enabling `{ compat: true }` when rendering templates that includ…

Most recent entries from all

GHSA-442j-39wm-28r2 — Handlebars.js has a Property Access Validation Bypass in container.lookup