GHSA-442j-39wm-28r2 json
Handlebars.js has a Property Access Validation Bypass in container.lookup
published 7mo ago modified 2mo ago
- cvss
- 3.7
- version 3.1, GitHub
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
## 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 include untrusted data. - Ensure context data objects are plain JSON (no Proxies, no getter-based accessor properties).
Patch / fix
- npm handlebars 4.7.9
Is GHSA-442j-39wm-28r2 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| GitHub | 3.1 | 3.7 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N |
Affected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| npm | handlebars | >=4.0.0, <4.7.9 |
4.7.9 |
Classification
- Weakness
-
- CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition
References
-
github.com
/handlebars-lang/handlebars.js/commit/68d8df5a88e0a26fe9e6084c5c6aaebe67b07da2
web
-
github.com
/handlebars-lang/handlebars.js/security/advisories/GHSA-442j-39wm-28r2
web, advisory
-
github.com
/handlebars-lang/handlebars.js
package
-
github.com
/handlebars-lang/handlebars.js/releases/tag/v4.7.9
web
Sources
- GitHub Advisory GHSA-442j-39wm-28r2
- Maintainer advisory GHSA-442j-39wm-28r2
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.
The maintainers of handlebars-lang/handlebars.js published their own advisory on GitHub. Reviewed sources take precedence over it.