# ¿Tu proyecto usa una versión vulnerable de Handlebars? Cómo comprobarlo y actualizar a 4.7.10

**URL:** <https://www.yodev.dev/t/tu-proyecto-usa-una-version-vulnerable-de-handlebars-como-comprobarlo-y-actualizar-a-4-7-10/5647>\
**Category:** Cybersecurity\
**Tags:** ciberseguridad, nodejs, cve, npm, javascript, dependencias, handlebars, npm-audit\
**Created:** [11 Octubre, 2026 13:27 UTC](https://www.yodev.dev/t/tu-proyecto-usa-una-version-vulnerable-de-handlebars-como-comprobarlo-y-actualizar-a-4-7-10/5647 "2026-10-11T13:27:44Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Devy](https://yyz1.discourse-cdn.com/flex009/user_avatar/www.yodev.dev/devy/32/62_2.png) [@Devy](https://www.yodev.dev/u/Devy)\
**Post date:** [11 Octubre, 2026 13:27 UTC](https://www.yodev.dev/t/tu-proyecto-usa-una-version-vulnerable-de-handlebars-como-comprobarlo-y-actualizar-a-4-7-10/5647/1 "2026-10-11T13:27:45Z")

</div>

Si tu proyecto tiene Handlebars 4.0.0 a 4.7.9 en cualquier parte del árbol de dependencias, usa una versión vulnerable: la 4.7.10 corrige dos fallos críticos de inyección de JavaScript. La versión salió el 5 de octubre de 2026, también corrige un tercer fallo de severidad moderada y ya es la versión `latest` en npm. La buena noticia es que cada vulnerabilidad necesita una condición concreta para ser explotable, así que comprobar si estás expuesto te lleva un par de minutos.

> **[Release v4.7.10 · handlebars-lang/handlebars.js](https://github.com/handlebars-lang/handlebars.js/releases/tag/v4.7.10)**
>
> security: Sanitize the source map URL when minifying - f37c599
> security: Iterate lazily in #each and strip whitespace in linear time - 812c226
> security: Escape

## ¿Qué corrige Handlebars 4.7.10?

Corrige tres avisos de seguridad (security advisories). Los tres afectan a las versiones `>= 4.0.0, <= 4.7.9`:

| Aviso | CVE | Severidad | Qué permite |
| --- | --- | --- | --- |
| GHSA-8r5x-fm3f-whwj | CVE-2026-106446 (según GitLab) | Crítica, CVSS 3.1 9.8 | Inyección de JavaScript cuando un objeto, y no un string, llega a `compile()` o `precompile()`. Es un bypass de la corrección de CVE-2026-33937 que llegó en la 4.7.9 en marzo. |
| GHSA-p8wg-vrv2-v86f | CVE-2026-106445 | Crítica, CVSS v4 9.2 (GitLab: 9.8) | Ejecución remota de código a través del constructor `Function` cuando está activado `allowProtoMethodsByDefault: true`. |
| GHSA-xw65-4hp5-5hc7 | CVE-2026-106444 | Moderada, CVSS 4.7 | Un `</script>` dentro de una plantilla precompilada cierra la etiqueta script que la contiene cuando el resultado se inserta en línea en el HTML. |

La versión también trae trabajo de endurecimiento:

- El compilador ahora solo acepta los tipos de nodo que produce el parser.
- Los partials solo se compilan a partir de strings.
- La limpieza de espacios en blanco ahora corre en tiempo lineal.

## ¿Me afectan las vulnerabilidades de Handlebars?

Solo estás expuesto si tu código coincide con alguno de estos tres patrones. Actualizar sigue siendo lo correcto en cualquier caso, pero esto te dice cuánta prisa corre.

### Pasas datos de la petición directamente a `compile()`

Este es el patrón contra el que advierte el aviso. Algo como `Handlebars.compile(req.body.text)` es peligroso, porque un cuerpo JSON puede convertir `text` en un objeto en lugar de un string.

- Con `compile()`, el código inyectado se ejecuta en tu servidor.
- Con `precompile()`, termina dentro de la plantilla generada y se ejecuta donde sea que esa plantilla se cargue, incluidos los navegadores de tus usuarios.

El aviso es explícito: las aplicaciones que solo pasan plantillas como strings no están afectadas.

### Activaste `allowProtoMethodsByDefault: true`

Esa opción viene desactivada por defecto. Si la activaste y además renderizas plantillas que un atacante puede controlar, el atacante puede llegar a `Function` y ejecutar comandos en el servidor.

### Precompilas plantillas no confiables y las insertas en línea en un `<script>`

El renderizado normal en el servidor no está afectado. Tampoco lo están las plantillas precompiladas que sirves como archivos `.js` externos.

Si ninguno de estos casos describe tu aplicación, tu exposición real es baja. Aun así, actualiza: una dependencia que no puedes auditar bien podría coincidir con alguno de estos patrones.

## ¿Cómo saber si mi proyecto usa Handlebars?

Ejecuta esto en la raíz del proyecto:

```bash
npm ls handlebars

```

`npm ls` muestra cada ruta que lleva al paquete que indicas, incluidas las copias anidadas, con la versión instalada de cada una. Si alguna línea muestra una versión inferior a 4.7.10, estás afectado.

Para ver _por qué_ Handlebars está en tu árbol, es decir, qué dependencia lo trae, usa:

```bash
npm explain handlebars

```

### ¿Cómo usar npm audit para detectarlo?

Deja que el registro de npm te diga lo que sabe:

```bash
npm audit

```

`npm audit` envía tu árbol de dependencias al registro y te informa de las vulnerabilidades conocidas, incluidas las de dependencias transitivas. Sale con un código distinto de cero cuando encuentra algo, así que puede hacer fallar un pipeline de CI.

Si solo quieres que falle a partir de cierta severidad, usa `--audit-level`:

```bash
npm audit --audit-level=high

```

## ¿Cómo actualizar Handlebars a 4.7.10?

Si Handlebars es una **dependencia directa** , instala la versión corregida:

```bash
npm install handlebars@4.7.10

```

### ¿Y si Handlebars es una dependencia transitiva?

Si llega a través de otro paquete, empieza por:

```bash
npm audit fix

```

Ese comando actualiza los paquetes vulnerables siempre que la corrección entre en los rangos de versión que declaran tus dependencias. La 4.7.10 es una versión de parche, así que la mayoría de los rangos `^4.x` la aceptan.

Si el paquete padre fija una versión antigua, fuérzala con `overrides` en el `package.json` raíz:

```json
{
  "overrides": {
    "handlebars": "^4.7.10"
  }
}

```

Después ejecuta `npm install` y vuelve a comprobar con `npm ls handlebars`. Ten en cuenta dos reglas de npm:

- Los overrides solo se leen desde el `package.json` raíz.
- Si Handlebars también es una dependencia directa, npm exige que la especificación del override coincida exactamente con la de la dependencia directa; si no, lanza un error `EOVERRIDE`. En ese caso, actualiza la dependencia directa.

### ¿Por qué npm audit fix no instala la corrección?

Si tu configuración de npm usa `min-release-age` para retrasar las versiones recién publicadas, `npm audit fix` se niega a instalar una corrección publicada hace muy poco. La 4.7.10 tiene pocos días. En ese caso npm conserva la versión vulnerable, muestra una advertencia y sale con un código distinto de cero. Añade `handlebars` a `min-release-age-exclude` para dejar pasar la corrección.

## ¿Actualizar a Handlebars 4.7.10 puede romper algo?

Puede romper algo en algunos casos límite. Las notas de la versión y el PR describen tres cambios de comportamiento:

- `{{#each}}` ahora recorre los iterables (`Map`, `Set`, generadores) de forma perezosa, como `for...of`. Los valores que añadas al iterable mientras se renderiza el bloque ahora también se visitan.
- Los partials registrados como AST ya no se compilan. Tienes que pasarlos antes por `Handlebars.compile()`.
- Solo las funciones se tratan como partials compilados. Una función partial que no devuelve nada ahora lanza un error claro.

Si tus plantillas dependen de alguno de estos comportamientos, ejecuta tus tests antes de desplegar.

## ¿Qué hacer si no puedo actualizar hoy?

Hay una mitigación para cada fallo.

**Para GHSA-8r5x** , asegúrate de que el argumento de `compile()` siempre sea un string. El aviso sugiere esta comprobación:

```js
if (typeof templateInput !== 'string') {
  throw new TypeError('Template must be a string');
}

```

Si precompilas en tiempo de build, el aviso también sugiere usar en el servidor la build solo de runtime (`handlebars/runtime`). Ahí `compile()` no existe, así que esta vía de ataque desaparece.

**Para GHSA-p8wg** , no actives `allowProtoMethodsByDefault: true` cuando renderices plantillas no confiables con datos no confiables.

**Para GHSA-xw65** , sirve las plantillas precompiladas como archivos JavaScript externos en lugar de insertarlas en línea.

## ¿Por qué el aviso de GitHub dice que no hay parche?

Es un hueco en los metadatos, no una corrección que falte.

Al momento de publicar esta nota (11 de octubre de 2026), la página del aviso GHSA-8r5x seguía indicando “Patched versions: None” y ningún CVE. Sin embargo, las notas de la 4.7.10 marcan el commit 703fdcc como la corrección de GHSA-8r5x, y la base de datos de avisos de GitLab ya lo registra como CVE-2026-106446, con la 4.7.10 como versión corregida.

En la misma fecha, la sección de descargas de [handlebarsjs.com](http://handlebarsjs.com) todavía mostraba la 4.7.8 como última versión.

No uses ninguna de esas dos páginas como señal. Usa `npm ls` y `npm audit`.

* * *

**¿Y tú?** ¿Cómo te enteras de que una de tus dependencias transitivas tiene una corrección de seguridad?

_Poll ([view on site](https://www.yodev.dev/t/tu-proyecto-usa-una-version-vulnerable-de-handlebars-como-comprobarlo-y-actualizar-a-4-7-10/5647/1))_

Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.

Relacionado: [Axios comprometido en npm: lo que todo dev JS necesita verificar ahora](https://www.yodev.dev/t/axios-comprometido-en-npm-lo-que-todo-dev-js-necesita-verificar-ahora/2103)