---
title: "Una línea en .npmrc que blinda tu proyecto contra ataques a npm"
description: "Los ataques de cadena de suministro en npm están a la orden del día. Con una sola línea en tu .npmrc puedes evitar la inmensa mayoría de ellos en tus proyectos WordPress con build de JS. Te cuento cuál es, cómo funciona y qué limitaciones tiene."
url: https://davidperezgar.com/blog/desarrollo-web/una-linea-en-npmrc-que-blinda-tu-proyecto-contra-ataques-a-npm/
date: 2026-09-21
modified: 2026-09-21
author: "David Pérez"
image: https://davidperezgar.com/wp-content/uploads/una-linea-en-npmrc-que-blinda-tu-proyecto-contra-ataques-a-npm-K9oNcZ2x.avif
categories: ["Desarrollo Web"]
type: post
lang: es
---

# Una línea en .npmrc que blinda tu proyecto contra ataques a npm

Si trabajas con WordPress y tienes un build de JavaScript por medio (Gutenberg, temas modernos, plugins con React…), estás usando npm. Y npm lleva meses siendo el patio de recreo favorito de los ataques de cadena de suministro: alguien compromete la cuenta del mantenedor de un paquete popular, publica una versión con código malicioso, y en cuestión de horas hay miles de proyectos infectados por el mundo.

La buena noticia: hay una línea de configuración que corta la mayoría de estos ataques en seco.

## La línea mágica

Abre (o crea) el archivo `.npmrc` en la raíz de tu proyecto y añade:

Copy

```
min-release-age=7
```

Ya está. Eso es todo.

## Qué hace exactamente

Con esa línea, npm ignora cualquier versión de cualquier paquete publicada hace menos de 7 días. Es decir: aunque `paquete-popular@2.5.7` acabe de salir hace 3 horas, tu instalación no la tocará. Se quedará en la última versión que ya tenga al menos una semana de vida.

¿Por qué funciona esto contra los ataques? Porque cuando comprometen un paquete popular, la comunidad lo detecta muy rápido —normalmente en horas— y la versión maliciosa se retira. Con una ventana de 7 días, tú ni siquiera llegas a instalarla. El ataque pasa por delante de tu proyecto sin tocarlo.

## Requisitos

Necesitas **npm 11.10.0 o superior**. Comprueba tu versión con:

Copy

```
npm --version
```

Y si te hace falta, actualiza con:

Copy

```
npm install -g npm@latest
```

## Dos cosas que NO arregla (importante saberlas)

Esto no es una bala de plata. Hay dos escenarios en los que `min-release-age` no te salva:

1. **Si tu `package-lock.json` ya está envenenado, da igual.** El lockfile manda: si dice que hay que instalar la versión X, npm instala la versión X, tenga la antigüedad que tenga. Revisa siempre los cambios en el lockfile antes de mergear pull requests, especialmente los automáticos de Dependabot y compañía.
2. **`npx` se salta la protección.** `npx` ejecuta paquetes sin pasar por tu configuración de instalación, así que la restricción no se aplica. Ojo con lo que ejecutas por ahí, sobre todo en scripts de CI.

## ¿Por qué deberías hacerlo hoy?

Porque el coste es literalmente escribir una línea en un archivo, y el beneficio es blindarte contra el 90% de los ataques de cadena de suministro que están pasando ahora mismo en npm.

Si mantienes un proyecto WordPress con build de JavaScript —un tema propio, un plugin con bloques Gutenberg, un headless con Next.js encima— esta es probablemente la mejor relación coste/beneficio en seguridad que puedes conseguir hoy en tu stack.

No lo dejes para mañana. Añádelo, commitea, y a otra cosa.