If your project has Handlebars 4.0.0 to 4.7.9 anywhere in your dependency tree, you’re using a vulnerable version: 4.7.10 fixes two critical JavaScript injection flaws. The version was released on October 5, 2026, and also fixes a third moderate-severity flaw—it’s already the latest version on npm. The good news is that each vulnerability requires a specific condition to be exploitable, so checking if you’re exposed takes just a couple of minutes.
What does Handlebars 4.7.10 fix?
It fixes three security advisories. All three affect versions >= 4.0.0, <= 4.7.9:
| Advisory | CVE | Severity | What it allows |
|---|---|---|---|
| GHSA-8r5x-fm3f-whwj | CVE-2026-106446 (per GitLab) | Critical, CVSS 3.1 9.8 | JavaScript injection when an object, not a string, reaches compile() or precompile(). It’s a bypass of the CVE-2026-33937 fix that landed in 4.7.9 in March. |
| GHSA-p8wg-vrv2-v86f | CVE-2026-106445 | Critical, CVSS v4 9.2 (GitLab: 9.8) | Remote code execution via the Function constructor when allowProtoMethodsByDefault: true is enabled. |
| GHSA-xw65-4hp5-5hc7 | CVE-2026-106444 | Moderate, CVSS 4.7 | A </script> inside a precompiled template closes the script tag containing it when the result is inserted inline into HTML. |
The version also includes hardening work:
- The compiler now only accepts node types produced by the parser.
- Partials are only compiled from strings.
- Whitespace stripping now runs in linear time.
Do Handlebars vulnerabilities affect me?
You’re only exposed if your code matches one of these three patterns. Updating is still the right call either way, but this tells you how urgent it is.
You pass request data directly to compile()
This is the pattern the advisory warns against. Something like Handlebars.compile(req.body.text) is dangerous because a JSON body can turn text into an object instead of a string.
- With
compile(), injected code runs on your server. - With
precompile(), it ends up inside the generated template and runs wherever that template loads, including your users’ browsers.
The advisory is explicit: applications that only pass templates as strings are not affected.
You enabled allowProtoMethodsByDefault: true
That option is disabled by default. If you enabled it and also render templates an attacker can control, the attacker can reach Function and execute commands on your server.
You precompile untrusted templates and insert them inline in a <script>
Normal server-side rendering is not affected. Neither are precompiled templates you serve as external .js files.
If none of these cases describe your application, your real exposure is low. Still, update: a dependency you can’t audit well could match one of these patterns.
How do I know if my project uses Handlebars?
Run this in your project root:
npm ls handlebars
npm ls shows every path leading to the package you specify, including nested copies, with the installed version of each. If any line shows a version lower than 4.7.10, you’re affected.
To see why Handlebars is in your tree—that is, what dependency brings it—use:
npm explain handlebars
How do I use npm audit to detect it?
Let the npm registry tell you what it knows:
npm audit
npm audit sends your dependency tree to the registry and reports known vulnerabilities, including those in transitive dependencies. It exits with a non-zero code when it finds something, so it can fail a CI pipeline.
If you only want it to fail above a certain severity, use --audit-level:
npm audit --audit-level=high
How do I update Handlebars to 4.7.10?
If Handlebars is a direct dependency, install the patched version:
npm install handlebars@4.7.10
What if Handlebars is a transitive dependency?
If it arrives through another package, start with:
npm audit fix
That command updates vulnerable packages whenever the fix fits within the version ranges your dependencies declare. 4.7.10 is a patch version, so most ^4.x ranges accept it.
If the parent package pins an old version, force it with overrides in your root package.json:
{
"overrides": {
"handlebars": "^4.7.10"
}
}
Then run npm install and check again with npm ls handlebars. Keep two npm rules in mind:
- Overrides are only read from the root
package.json. - If Handlebars is also a direct dependency, npm requires the override spec to match exactly the direct dependency spec; if not, it throws an
EOVERRIDEerror. In that case, update the direct dependency.
Why doesn’t npm audit fix install the patch?
If your npm setup uses min-release-age to delay newly published versions, npm audit fix refuses to install a patch released very recently. 4.7.10 is days old. In that case npm keeps the vulnerable version, shows a warning, and exits with a non-zero code. Add handlebars to min-release-age-exclude to let the patch through.
Can updating to Handlebars 4.7.10 break things?
It can break things in some edge cases. The release notes and PR describe three behavior changes:
{{#each}}now iterates iterables (Map,Set, generators) lazily, likefor...of. Values you add to the iterable while the block is rendering are now also visited.- Partials registered as AST are no longer compiled. You must pass them through
Handlebars.compile()first. - Only functions are treated as compiled partials. A partial function that returns nothing now throws a clear error.
If your templates depend on any of these behaviors, run your tests before deploying.
What if I can’t update today?
There’s a mitigation for each flaw.
For GHSA-8r5x, make sure the argument to compile() is always a string. The advisory suggests this check:
if (typeof templateInput !== 'string') {
throw new TypeError('Template must be a string');
}
If you precompile at build time, the advisory also suggests using the runtime-only build (handlebars/runtime) on your server. There, compile() doesn’t exist, so this attack vector disappears.
For GHSA-p8wg, don’t enable allowProtoMethodsByDefault: true when rendering untrusted templates with untrusted data.
For GHSA-xw65, serve precompiled templates as external JavaScript files instead of inserting them inline.
Why does the GitHub advisory say there’s no patch?
It’s a gap in the metadata, not a missing fix.
As of when this note was published (October 11, 2026), the GHSA-8r5x advisory page still showed “Patched versions: None” and no CVE. However, the 4.7.10 release notes mark commit 703fdcc as the fix for GHSA-8r5x, and GitLab’s advisory database already lists it as CVE-2026-106446, with 4.7.10 as the patched version.
On the same date, the downloads section of handlebarsjs.com still showed 4.7.8 as the latest version.
Don’t use either of those two pages as a signal. Use npm ls and npm audit.
What about you? How do you find out that one of your transitive dependencies has a security fix?
- npm audit in CI
- Dependabot or Renovate
- I check manually when I hear about it
- I prefer another option (tell us which)
Comment below or, if this article reached you by email, reply directly to the email: your reply gets published here.
Related: Axios compromised on npm: what every JS dev needs to verify now