Pular para o conteúdo
>_ITDITDPlataforma de Segurança Web

Guias de Segurança

#Next.js#CVE#dependências#Docker

Rodando Next.js com segurança: não ficar para trás nos CVEs publicados

Com Next.js, o mais assustador é deixar um CVE publicado sem correção — um RCE CVSS 10.0 com meses já causou invasões reais. Quatro pilares: julgue pela versão em execução, monitore dependências por máquina, atualize rápido e menor privilégio — através da lente operacional deste site.

Publicado 2026-06-07 Atualizado 2026-06-07 4 min de leitura

Para: qualquer pessoa publicando apps com Next.js (ou frameworks JS similares), especialmente "construído com a ajuda da IA, operando no feeling". Destilado de um incidente real (→ o CVSS 10.0 negligenciado).

A visão deste site: a batalha não se vence na 'velocidade'

Desenvolvedores indie geralmente perdem em segurança não por falta de conhecimento, mas por falta de continuidade operacional. Ler notícias de CVE mais rápido que qualquer um não tem valor (deixe a velocidade para fornecedores e noticiários). O que funciona é um sistema que não deixa escapar os CVEs relevantes para você. Por isso este artigo se apoia em "sistematizar", não em "saber mais".

1. Julgue pela versão em execução

Meça "estou numa versão perigosa" pelo que está de fato rodando, não pelo piso do manifesto — porque o número do manifesto e a versão em execução muitas vezes discordam.

✗ Contar pelo piso do package.json

"next": "^16.0.0" → "16.0.0 é vulnerável, então nós somos" — superestimado como "8 vulneráveis".

✓ Contar pela versão em execução

npm ls next mostra a versão resolvida → as auto-atualizadas estão seguras, só as fixadas ficam para trás. Na verdade 2.

O piso do package.json mente. Julgue pela versão em execução e o risco muda (8 'vulneráveis' viraram 2).
# ver as versões de fato resolvidas
npm ls next react react-dom
# dentro de um container em execução
docker exec <container> npm ls next

Faixas com circunflexo (^16.0.0) se atualizam automaticamente no rebuild; deps fixadas ficam para trás. Os números aqui são a verdade.

2. Monitore suas dependências por máquina

Rastrear CVEs à mão é impossível, e o lapso vira o incidente. Deixe as máquinas vigiarem.

Monitoramento de dependências gratuito

osv-scanner scan -L pnpm-lock.yaml

No GitHub, ative o Dependabot (Settings → Security). Você receberá PRs só para CVEs que casam com suas deps.

O que importa é a priorização. A postura deste site: classifique por "está sendo explorado (KEV)" vezes "quão alto é o CVSS". Um CVSS alto que você não usa é de pequeno impacto; uma nota média sob exploração ativa é prioridade máxima — essa priorização é o trabalho de verdade.

3. Disciplina de atualização: corrija a raiz, não o sintoma

Quando uma vulnerabilidade aparece, atualize o framework para a versão corrigida para fechar o buraco em si.

Esconder o sintoma (insuficiente)

  • Bloquear só requisições "de aparência suspeita" num proxy reverso
  • Parar as cobranças/sintoma e chamar de "resolvido"
  • Deixar o RCE em si vivo

Correção de raiz (correta)

  • Atualizar o framework para a versão corrigida
  • Após atualizar, confirme que a assinatura sumiu nos seus logs
  • Tratar primeiros socorros e a correção de raiz como dois trabalhos separados, fazer ambos

A falha comum

"Parou as cobranças/sintoma" ≠ "resolvido". Primeiros socorros e fechar a vulnerabilidade são trabalhos diferentes. Faça os dois.

4. Menor privilégio para encolher o raio de explosão

Contenha o dano se você for atingido.

1

Rode como um usuário sem privilégios

Não rode o USER do container como root. Uma invasão alcança só "aquele privilégio".
2

Vincule DB/Redis só à rede interna

Nunca público. Reduza a superfície diretamente acessível.
3

Separe por serviço

Divida redes e dados por serviço para que uma invasão não possa cascatear para tudo.

Estes decidem se uma invasão para em "roubo de env dentro de um container" ou alcança "tomada do host".

Nós fazemos isso

Este site monitora suas próprias dependências em busca de CVEs, exatamente como escrito aqui — para que o incidente que deu início a tudo (um CVSS 10.0 público negligenciado) nunca mais seja deixado passar por um humano. Dizemos "classifique por prioridade (KEV + CVSS)" porque é assim que de fato operamos.

Leia a seguir

FAQ

QO que mais importa para a segurança do Next.js?
A

Antes de não escrever bugs, é não deixar CVEs publicados no framework ou em suas dependências sem correção. A maioria das invasões graves vem de buracos conhecidos e negligenciados, não de ataques novos.

QDá para saber se estou vulnerável pelo package.json?
A

Não. O `^` (piso) no package.json não reflete a realidade — faixas com circunflexo se atualizam automaticamente no rebuild, deps fixadas ficam para trás. Sempre julgue pela versão de fato em execução.

QQual é a única coisa a fazer primeiro, sozinho?
A

Ative o Dependabot (GitHub) ou o osv-scanner para que as máquinas vigiem suas dependências em busca de CVEs. Patrulhas manuais sempre deixam escapar. Um sistema que continua vence mais conhecimento.