Next.js 16.4.1 e Node.js de outubro: o checklist de patch para apps em produção

Em uma semana, as duas peças centrais de quase toda stack JavaScript moderna receberam patches de segurança: o Next.js em 14 de outubro e o Node.js em 21 de outubro. Minha tese é simples: atualizar não é a parte difícil. A parte difícil é saber, sem depender de memória, se cada app em produção está acima do piso seguro. Este post resume o que foi corrigido e mostra um checklist com um script que transforma isso em uma etapa do CI.

#O que o Next.js corrigiu em 14 de outubro

A equipe do Next.js publicou um update fora do ciclo normal, com duas correções que tinham sido adiadas do release de setembro por atraso em dependências upstream. As versões corrigidas são a 16.4.1 (Active LTS) e a 15.5.28 (Maintenance LTS).

Três detalhes merecem atenção:

• O RCE do use cache não exige que você tenha a função vulnerável. A recomendação oficial é atualizar mesmo que o seu código não retorne typed arrays de uma função cacheada. Segundo o The Hacker News, ele afeta da 16.0.0 até a 16.4.0.
• O RCE de imagem vem do librsvg, embutido no sharp. Por padrão o Next.js não otimiza SVG; isso só acontece com dangerouslyAllowSVG ligado ou com next/og renderizando SVG no runtime Node.js. Na linha 15, a 15.5.28 ainda aceita o sharp 0.34.x, e um upgrade por cima de uma instalação existente pode deixá-lo no lugar.
• O DoS mira as Server Actions. Requisições forjadas consomem CPU e travam o processo para as próximas requisições. Quem usa só Pages Router, ou não tem nenhuma Server Action, não é afetado.

#O que o Node.js corrigiu em 21 de outubro

O release de segurança do Node.js trouxe 10 CVEs (4 altas, 3 médias e 3 baixas), com correções em v22.23.4, v24.22.1 e v26.12.1. As altas são do tipo que passa despercebido em code review:

• CVE-2026-111497: escrita fora dos limites no decoder Brotli do node:zlib com entrada malformada, que pode levar a crash, vazamento de memória ou execução de código. Relevante para quem descomprime payloads de terceiros.
• CVE-2026-105482: dns.resolve*() e dns.reverse() truncam silenciosamente hostnames com byte NUL. Isso abre caminho para burlar allowlists de domínio, comuns em proteção contra SSRF.
• CVE-2026-106069 e CVE-2026-105483: grafias alternativas de IP (zero à esquerda ou dígitos fullwidth) fazem a checagem de certificado validar contra um endereço diferente do conectado.

Entre as médias, uma chama atenção para quem usa snapshots de inicialização ou executáveis SEA: crypto.randomUUID() e randomInt() podem repetir valores entre processos (CVE-2026-106074). O release também atualiza c-ares, OpenSSL, SQLite e Undici.

#O checklist

Esta é a ordem que eu recomendo para qualquer app Next.js em produção:

1. Descubra o que está rodando de verdade, não o que o package.json diz. O lockfile e a imagem de deploy mandam.
2. Atualize o Next.js para 16.4.1 ou 15.5.28. Quem está em linhas sem patch (14 ou anteriores) precisa planejar a migração de major.
3. Confira o sharp e garanta 0.35.5 ou superior, principalmente na linha 15.
4. Atualize o Node.js no ambiente de execução: imagem Docker, engines do package.json, .nvmrc e a versão configurada na plataforma de deploy.
5. Revise a superfície exposta: dangerouslyAllowSVG, uso de next/og e Server Actions públicas, como checkout ou formulário de contato.
6. Rebuild e redeploy. Patch instalado sem novo build não protege nada.

Os comandos de verificação manual:

# versão real instalada (vale para npm, pnpm e yarn)
npm ls next sharp
pnpm why sharp

# atualização
pnpm add next@16.4.1   # ou next@15.5.28 na linha 15

# versão do Node no ambiente de execução
node --version

#Transformando o checklist em etapa do CI

Checklist manual funciona uma vez. Para não depender de lembrar na próxima rodada de patches, prefiro um script sem dependências que falha o pipeline quando o Node ou o Next estão abaixo do piso. Basta atualizar a tabela FLOORS a cada novo advisory.

// scripts/check-security-floor.mjs
import { readFileSync } from "node:fs";
import { createRequire } from "node:module";

const require = createRequire(import.meta.url);

// Versão mínima corrigida por linha major (patches de outubro/2026)
const FLOORS = {
  node: { 22: "22.23.4", 24: "24.22.1", 26: "26.12.1" },
  next: { 15: "15.5.28", 16: "16.4.1" },
};

function parse(version) {
  return version.replace(/^v/, "").split("-")[0].split(".").map(Number);
}

function isAtLeast(current, floor) {
  const a = parse(current);
  const b = parse(floor);
  for (let i = 0; i < 3; i++) {
    if (a[i] !== b[i]) return a[i] > b[i];
  }
  return true;
}

function check(name, version) {
  const [major] = parse(version);
  const floor = FLOORS[name][major];
  if (!floor) return `${name} ${version}: linha ${major} sem patch, migre de major`;
  if (!isAtLeast(version, floor)) return `${name} ${version}: atualize para ${floor}+`;
  return null;
}

const nextPkg = JSON.parse(readFileSync(require.resolve("next/package.json"), "utf8"));

const problems = [
  check("node", process.versions.node),
  check("next", nextPkg.version),
].filter(Boolean);

if (problems.length > 0) {
  console.error(problems.join("\n"));
  process.exit(1);
}
console.log("Node e Next acima do piso de segurança.");

Rode com node scripts/check-security-floor.mjs como um passo antes do build. Em um projeto com next@15.5.4, por exemplo, a saída é next 15.5.4: atualize para 15.5.28+ e o processo termina com código 1, o que basta para barrar o deploy em qualquer CI. O sharp fica de fora de propósito: como ele costuma ser dependência transitiva do Next, conferir com npm ls sharp ou pnpm why sharp é mais confiável do que tentar resolvê-lo a partir da raiz do projeto.

#Por que isso importa para quem contrata

Vários projetos do meu portfólio rodam em Next.js, como o CRM sob medida e a plataforma antitrapaça com prova em vídeo. Em sistemas assim, uma RCE não autenticada não é um problema teórico: significa acesso ao servidor que guarda dados de clientes e operação. Para quem contrata, a pergunta certa não é "o seu app usa a última versão?", e sim "como você fica sabendo quando precisa atualizar, e quanto tempo leva para chegar em produção?".

#Conclusão

• Atualize para Next.js 16.4.1 ou 15.5.28 e Node.js 22.23.4, 24.22.1 ou 26.12.1, e faça rebuild e redeploy. Para o RCE do use cache e o DoS das Server Actions, não existe workaround.
• Não confie só no npm audit: dois dos três advisories do Next.js não apareciam no feed dele logo após o patch.
• Automatize o piso de versões no CI. Um script de poucas dezenas de linhas transforma "acho que já atualizei" em um pipeline que falha quando não atualizou.

#Fontes

• Next.js Security Update for Upstream Vulnerabilities (nextjs.org, 14/10/2026)
• Next.js ships out-of-band patch (The Hacker News, out/2026)
• Node.js Security Releases: October 21, 2026 (nodejs.org)