Se seu projeto tiver Handlebars 4.0.0 a 4.7.9 em qualquer lugar da árvore de dependências, estará usando uma versão vulnerável: a 4.7.10 corrige dois falhos críticos de injeção de JavaScript. A versão foi lançada em 5 de outubro de 2026, também corrige um terceiro fallo de severidade moderada e já é a versão latest no npm. A boa notícia é que cada vulnerabilidade precisa de uma condição específica para ser explorável, então verificar se você está exposto leva alguns minutos.
O que corrige a versão Handlebars 4.7.10?
Corrige três avisos de segurança (security advisories). Os três afetam as versões >= 4.0.0, <= 4.7.9:
| Aviso | CVE | Severidade | O que permite |
|---|---|---|---|
| GHSA-8r5x-fm3f-whwj | CVE-2026-106446 (segundo GitLab) | Crítica, CVSS 3.1 9.8 | Injeção de JavaScript quando um objeto, e não uma string, chega a compile() ou precompile(). É um bypass da correção de CVE-2026-33937 que chegou na 4.7.9 em março. |
| GHSA-p8wg-vrv2-v86f | CVE-2026-106445 | Crítica, CVSS v4 9.2 (GitLab: 9.8) | Execução remota de código através do construtor Function quando allowProtoMethodsByDefault: true está ativado. |
| GHSA-xw65-4hp5-5hc7 | CVE-2026-106444 | Moderada, CVSS 4.7 | Uma </script> dentro de um template precompilado fecha a tag script que o contém quando o resultado é inserido inline no HTML. |
A versão também traz trabalho de endurecimento:
- O compilador agora só aceita os tipos de nó que o parser produz.
- Os partials são compilados apenas a partir de strings.
- A limpeza de espaçamento em branco agora roda em tempo linear.
As vulnerabilidades do Handlebars afetam você?
Você está exposto apenas se seu código coincide com um destes três padrões. Atualizar ainda é a coisa correta em qualquer caso, mas isso diz o quanto de pressa você corre.
Você passa dados da requisição diretamente para compile()
Este é o padrão contra o qual o aviso alerta. Algo como Handlebars.compile(req.body.text) é perigoso, porque um corpo JSON pode converter text em um objeto em vez de uma string.
- Com
compile(), o código injetado é executado no seu servidor. - Com
precompile(), termina dentro do template gerado e é executado em qualquer lugar que esse template seja carregado, incluindo os navegadores de seus usuários.
O aviso é explícito: aplicações que apenas passam templates como strings não são afetadas.
Você ativou allowProtoMethodsByDefault: true
Essa opção vem desativada por padrão. Se você a ativou e além disso renderiza templates que um atacante pode controlar, o atacante pode chegar a Function e executar comandos no servidor.
Você precompila templates não confiáveis e os insere inline em uma <script>
A renderização normal no servidor não é afetada. Tampouco os templates precompilados que você serve como arquivos .js externos.
Se nenhum desses casos descreve sua aplicação, sua exposição real é baixa. Mesmo assim, atualize: uma dependência que você não consegue auditar bem poderia coincidir com um desses padrões.
Como saber se meu projeto usa Handlebars?
Execute isso na raiz do projeto:
npm ls handlebars
npm ls mostra cada caminho que leva ao pacote que você indica, incluindo cópias aninhadas, com a versão instalada de cada uma. Se alguma linha mostrar uma versão anterior a 4.7.10, você está afetado.
Para ver por que Handlebars está em sua árvore, ou seja, que dependência o traz, use:
npm explain handlebars
Como usar npm audit para detectar?
Deixe o registro do npm te contar o que sabe:
npm audit
npm audit envia sua árvore de dependências para o registro e informa sobre vulnerabilidades conhecidas, incluindo as de dependências transitivas. Sai com um código diferente de zero quando encontra algo, então pode fazer um pipeline de CI falhar.
Se você só quer que falhe a partir de certa severidade, use --audit-level:
npm audit --audit-level=high
Como atualizar Handlebars para 4.7.10?
Se Handlebars é uma dependência direta, instale a versão corrigida:
npm install handlebars@4.7.10
E se Handlebars é uma dependência transitiva?
Se chegar através de outro pacote, comece com:
npm audit fix
Esse comando atualiza os pacotes vulneráveis sempre que a correção se encaixa nos intervalos de versão que suas dependências declaram. A 4.7.10 é uma versão de patch, então a maioria dos intervalos ^4.x a aceitam.
Se o pacote pai fixar uma versão antiga, force com overrides no package.json raiz:
{
"overrides": {
"handlebars": "^4.7.10"
}
}
Depois execute npm install e verifique novamente com npm ls handlebars. Tenha em mente duas regras do npm:
- Os overrides são lidos apenas do
package.jsonraiz. - Se Handlebars também for uma dependência direta, o npm exige que a especificação do override corresponda exatamente à da dependência direta; caso contrário, lança um erro
EOVERRIDE. Nesse caso, atualize a dependência direta.
Por que npm audit fix não instala a correção?
Se sua configuração do npm usa min-release-age para atrasar versões recém-publicadas, npm audit fix se recusa a instalar uma correção publicada há muito pouco. A 4.7.10 tem alguns dias. Nesse caso o npm mantém a versão vulnerável, mostra um aviso e sai com um código diferente de zero. Adicione handlebars a min-release-age-exclude para deixar a correção passar.
Atualizar para Handlebars 4.7.10 pode quebrar algo?
Pode quebrar algo em alguns casos limites. As notas da versão e o PR descrevem três mudanças de comportamento:
{{#each}}agora itera sobre iteráveis (Map,Set, geradores) de forma preguiçosa, comofor...of. Os valores que você adiciona ao iterável enquanto o bloco está sendo renderizado agora também são visitados.- Os partials registrados como AST não são mais compilados. Você precisa passá-los antes por
Handlebars.compile(). - Apenas funções são tratadas como partials compilados. Uma partial de função que não retorna nada agora lança um erro claro.
Se seus templates dependem de algum desses comportamentos, execute seus testes antes de fazer o deploy.
E se não puder atualizar hoje?
Há uma mitigação para cada fallo.
Para GHSA-8r5x, certifique-se de que o argumento de compile() seja sempre uma string. O aviso sugere esta verificação:
if (typeof templateInput !== 'string') {
throw new TypeError('Template must be a string');
}
Se você precompila no tempo de build, o aviso também sugere usar no servidor apenas o build de runtime (handlebars/runtime). Ali compile() não existe, então essa via de ataque desaparece.
Para GHSA-p8wg, não ative allowProtoMethodsByDefault: true quando renderizar templates não confiáveis com dados não confiáveis.
Para GHSA-xw65, sirva os templates precompilados como arquivos JavaScript externos em vez de inseri-los inline.
Por que o aviso do GitHub diz que não há patch?
É uma lacuna nos metadados, não uma correção que falta.
No momento de publicar esta nota (11 de outubro de 2026), a página do aviso GHSA-8r5x ainda indicava “Patched versions: None” e nenhum CVE. No entanto, as notas da 4.7.10 marcam o commit 703fdcc como a correção de GHSA-8r5x, e o banco de dados de avisos do GitLab já o registra como CVE-2026-106446, com a 4.7.10 como versão corrigida.
Na mesma data, a seção de downloads de handlebarsjs.com ainda mostrava a 4.7.8 como versão mais recente.
Não use nenhuma dessas duas páginas como referência. Use npm ls e npm audit.
E você? Como fica sabendo que uma de suas dependências transitivas tem uma correção de segurança?
- npm audit em CI
- Dependabot ou Renovate
- Verifico a mão quando fico sabendo
- Prefiro outra opção (nos conta qual)
Comente abaixo ou, se este artigo chegou para você por email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: Axios comprometido no npm: o que todo dev JS precisa verificar agora