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: o que importa não é velocidade, mas um sistema que não deixa escapar
Quando desenvolvedores indie falham em segurança, geralmente não é por falta de conhecimento, mas porque não conseguem manter a operação em andamento. 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 concentra em construir esse sistema, em vez de 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.
# see the versions actually resolved
npm ls next react react-dom
# inside a running container
docker exec <container> npm ls nextFaixas com circunflexo (^16.0.0) se atualizam automaticamente no rebuild; deps fixadas ficam para trás. Julgue pelas versões mostradas aqui.
Como verificar o seu próprio ambiente
Estes passos mostram qual versão o seu app está de fato rodando e se um CVE conhecido se aplica. Cada um só inspeciona o seu próprio ambiente.
Verifique a versão local
Rode npx next info na pasta do projeto. Ele mostra as versões reais de next, react e react-dom e o quanto você está atrás da versão mais recente. npx next -v mostra só a versão do Next.js.
Veja por que você tem essa versão
npm ls next (ou pnpm why next) mostra qual versão está instalada e por meio de qual pacote. Se o seu lockfile (package-lock.json ou pnpm-lock.yaml) não está commitado, a versão pode mudar a cada build; então commite-o primeiro.
Verifique a versão rodando em produção
Atualizar localmente não muda um servidor que ainda roda uma imagem antiga. Num container, leia o campo version do package.json do next dentro do container em execução (comando abaixo). Isso também funciona com output: 'standalone'.
Compare com os CVEs conhecidos
npm audit --omit=dev verifica só as dependências que vão para produção. Adicionar --audit-level=high faz o comando sair com código diferente de zero quando encontra algo High ou acima, então o CI pode parar nisso. Escanear o lockfile com o osv-scanner serve ao mesmo propósito.
Leia o aviso oficial para o seu caso
Os avisos do Next.js às vezes se dividem entre App Router e Pages Router, ou entre auto-hospedado e gerenciado. Compare as versões corrigidas listadas no aviso com as versões que você encontrou nos passos 1 a 3.
# local: actual versions and distance from latest
npx next info
# the version running inside the production container
docker exec <container> node -p "require('next/package.json').version"
# check only production dependencies; fail on High or above
npm audit --omit=dev --audit-level=highO que muda conforme a forma de rodar
O mesmo CVE pode afetar você ou não dependendo de como você roda o Next.js. Dois casos passados, por tipo de deploy:
| Como você roda | Bypass de autenticação no middleware (CVE-2025-29927) | RCE em RSC (CVE-2025-55182) | Quem atualiza |
|---|---|---|---|
| Gerenciado (Vercel, Netlify etc.) | Não afetado (o roteamento roda num sistema separado) | Afetado se você usa App Router; existem regras de bloqueio, mas você ainda precisa atualizar | Você (o seu lockfile decide a próxima versão) |
| Auto-hospedado (next start / standalone, incl. Docker) | Afetado | Afetado se você usa App Router | Você (reconstruindo a imagem e reiniciando) |
| Exportação estática (output: 'export') | Não afetado (nenhum servidor roda) | Nenhum servidor recebe requisições, então em geral não chega até você | Você (as dependências de build ainda precisam de atualização) |
Ou seja, mesmo em hospedagem gerenciada, subir a versão do Next.js é trabalho seu. Trate as proteções do provedor como um ganho de tempo até você estar na versão corrigida.
Verifique também a janela de suporte. Pela política de suporte oficial, em outubro de 2026:
| Linha | Situação (outubro de 2026) | Correções de segurança |
|---|---|---|
| 16.x | Active LTS (recursos, correções, patches de segurança) | Sim |
| 15.x | Maintenance LTS (dois anos a partir do lançamento inicial) | Só as críticas |
| 14.x e anteriores | Sem suporte | Raramente, para problemas graves, sem garantia |
2. Monitore suas dependências por máquina
Rastrear CVEs à mão não se sustenta, e o lapso vira o incidente. Monitore-as automaticamente com uma ferramenta.
Monitoramento de dependências gratuito
osv-scanner scan -L pnpm-lock.yamlNo GitHub, ative o Dependabot ("Settings" do repositório → "Advanced Security" → "Dependabot alerts"). 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 núcleo do trabalho.
3. Atualização: vá para a versão corrigida, não para um paliativo
Quando uma vulnerabilidade aparece, atualize o framework para a versão corrigida para corrigir a vulnerabilidade em si.
Correções superficiais (insuficiente)
- Bloquear num proxy reverso só as requisições que parecem o ataque
- Parar as cobranças/sintoma e chamar de "resolvido"
- Deixar a vulnerabilidade de RCE em si no lugar
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 a contenção do dano e a correção da causa como dois trabalhos separados, e fazer ambos
A falha comum
"Parou as cobranças/sintoma" ≠ "resolvido". Conter o dano e corrigir a vulnerabilidade são trabalhos diferentes. Faça os dois.
Um exemplo real: a vulnerabilidade de React Server Components de dezembro de 2025
Veja como foi, na prática, lidar com um CVE publicado, usando a vulnerabilidade de React Server Components (RSC) divulgada em dezembro de 2025. Tudo abaixo vem dos anúncios oficiais do React e do Next.js e dos dados públicos da CISA.
3 de dezembro de 2025
O React divulgou o CVE-2025-55182 (CVSS 10.0), que pode levar à execução de código no servidor sem autenticação. No Next.js, apps com App Router nas versões 15.x, 16.x e alguns canaries foram afetados (CVE-2025-66478); Pages Router e Edge Runtime não. Não havia paliativo: era obrigatório atualizar para uma versão corrigida (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 e outras).5 de dezembro de 2025
A CISA o incluiu no seu catálogo de vulnerabilidades com exploração confirmada (KEV).6 de dezembro de 2025
O Next.js acrescentou que apps online e sem correção em 4 de dezembro, às 13h (horário do Pacífico), deveriam rotacionar os segredos que usam (chaves de API etc.).11 de dezembro de 2025
Enquanto o patch era examinado, mais dois problemas no mesmo mecanismo (negação de serviço e exposição de código-fonte) foram encontrados e corrigidos. Depois, a correção da negação de serviço se mostrou incompleta, o CVE-2025-67779 foi emitido e quem já tinha atualizado foi orientado a atualizar de novo.
Daí saem três lições de operação:
- Uma atualização não é o fim. Correções de acompanhamento no mesmo código podem chegar com dias de intervalo
- As regras de bloqueio do provedor foram um complemento; atualizar foi descrito como a única correção completa
- Se você estava online antes de corrigir, rotacione os segredos além de atualizar
A visão deste site: concluído significa versão de produção corrigida, não ter rodado uma atualização
Quando as correções de acompanhamento continuam chegando, como aqui, "atualizei semana passada" deixa de ser confiável. Julgue a conclusão por a versão em produção estar igual ou acima da versão corrigida no aviso mais recente, não pela lembrança do trabalho. Este site também só marca uma atualização como concluída depois de confirmar que o container foi recriado e verificar a versão rodando dentro dele.
Erros comuns e como corrigi-los
- Julgar pelo número no package.json: a versão instalada pode ser outra. Verifique com
npx next infoounpm ls next. - Parar depois de atualizar o lockfile: a versão antiga continua rodando até a imagem de produção ser reconstruída e reiniciada. Verifique a versão dentro da produção.
- Sentir-se seguro após uma atualização: podem vir avisos de acompanhamento. Mantenha alertas como os do Dependabot ligados e acompanhe os avisos por alguns dias.
- Deixar tudo para as regras de bloqueio do provedor: elas podem não pegar todas as formas de um ataque. Atualize.
- Ficar numa linha sem suporte: 14.x e anteriores não têm garantia de correções. Planeje a migração para o 16.x.
- Perder avisos relevantes para produção no meio do ruído de dependências só de desenvolvimento: rode
npm audit --omit=devpara ver primeiro o que vai para produção. - Ignorar a janela antes da correção: segredos podem ter sido levados nesse tempo. Rotacione chaves de API e senhas de banco de dados (→ fundamentos de .env e chaves de API).
4. Menor privilégio para limitar o dano
Projete para que o dano fique limitado se o app for explorado.
Rode como um usuário sem privilégios
USER do container como root. Uma invasão então alcança só o que esse usuário pode fazer.Vincule DB/Redis só à rede interna
Separe por serviço
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 tipo de lapso que deu início a tudo (um CVSS 10.0 público negligenciado) não fique de novo dependendo da atenção humana. Dizemos "classifique por prioridade (KEV + CVSS)" porque é assim que de fato operamos.
Leia a seguir
- Incidente: Um RCE público negligenciado cobrado por fraude
- Glossário: CVE · CVSS · RCE
- História: Log4Shell — RCE através de uma dependência
- Framework: segurança do Next.js (a fronteira, variáveis de ambiente, CVEs de dependências)
- Priorização: como classificar CVEs com CVSS, EPSS e KEV
- Monitoramento: configurando o osv-scanner
- O panorama: Next.js e React têm muitas vulnerabilidades? (o que os dados de CVE realmente mostram; em inglês)
Fontes
- Next.js, "Security Advisory: CVE-2025-66478" (3 de dezembro de 2025; atualizado em 6 de dezembro): nextjs.org
- Next.js, "Security Update: December 11, 2025" (CVE-2025-55183 / 55184 / 67779): nextjs.org
- NVD, "CVE-2025-55182": nvd.nist.gov / CISA, "Known Exploited Vulnerabilities Catalog": cisa.gov
- Vercel, "React2Shell Security Bulletin": vercel.com
- Vercel, "Postmortem on Next.js Middleware bypass" (CVE-2025-29927): vercel.com
- Next.js, "Support Policy": nextjs.org / "next CLI": nextjs.org / "Static Exports": nextjs.org
- npm Docs, "npm audit": docs.npmjs.com / OSV-Scanner, "Usage": google.github.io / GitHub Docs, "Configuring Dependabot alerts": docs.github.com