Em 25 de agosto de 2026, o Next.js publicou um security release antecipado — a data saiu de 26 para 25 de agosto porque uma segunda vulnerabilidade crítica foi identificada durante a preparação. Resultado: duas falhas de execução remota de código (RCE) sem autenticação, corrigidas nas versões 16.3.3 (Active LTS) e 15.5.24 (Maintenance LTS). Se você roda Next.js em produção e não atualizou desde então, pare de ler e atualize: npm install next@16.3.4 (o patch follow-up de 31/08) ou next@15.5.25.
A falha da API de imagens é explorável sem credencial nenhuma — basta o atacante enviar uma imagem AVIF manipulada ao endpoint de otimização. Qualquer deploy exposto na internet que sirva imagens via next/image está no escopo.
Falha 1: RCE na otimização de imagens (libheif/sharp)
A primeira vulnerabilidade (GHSA-2xp9-vwfh-vxw4 / GHSA-g89c-p67h-r497) não estava no código JavaScript do Next.js — residia na libheif, biblioteca em C usada pelo sharp para decodificar AVIF. Uma imagem AVIF com dados manipulados levava à execução remota de código no processo do servidor. O fix das versões patchadas desabilitou a otimização AVIF até a correção do upstream se propagar pelo ecossistema.
O padrão é velho conhecido: imagem é input não autenticado e parsers nativos são a superfície de ataque. ImageTragick (ImageMagick, 2016) e o overflow do libwebp (CVE-2023-4863, o bug que afetou todos os browsers em 2023) seguiram o mesmo roteiro. A diferença em 2026: seu app JavaScript moderno carrega dezenas de dependências nativas — sharp, bcrypt, canvas, sqlite — e a superfície C/C++ do seu 'app JS' é real e auditável.
Falha 2: RCE em servidores Windows
A segunda (CVE-2026-75604 / GHSA-p293-qw3h-jr36) afeta aplicações que usam Pages Router e App Router juntos, sem Cache Components, em servidores com filesystem Windows — e também leva a RCE sem autenticação. Linux e macOS não são afetados. Não há workaround documentado: a única mitigação é atualizar. Deploys Next em Windows são minoria, mas existem — frequentemente dentro de corporações — e ficaram expostos sem plano B.
A mudança silenciosa: security releases agendadas
Este foi o segundo release do novo programa de segurança do Next.js (anunciado em julho): datas agendadas com aviso prévio, no modelo que curl e OpenSSL consagraram. O anúncio da release de 26/08 foi publicado dias antes, dando tempo de planejar a janela de patch — e a descoberta da segunda falha moveu tudo um dia mais cedo, com os dois fixes empacotados juntos para que os times atualizassem uma única vez. A lição operacional: acompanhe o blog oficial do Next.js e trate patch de segurança como processo, não como incêndio.
# Atualize imediatamente
npm install next@16.3.4 # Next 16 (Active LTS)
npm install next@15.5.25 # Next 15 (Maintenance LTS)
# pnpm — atualize em todo o workspace e commit o lockfile
pnpm up next@16.3.4 --recursive
pnpm install # reconcilia o lockfile com os overrides antes do CIChecklist: o que fazer além do upgrade
- Enquanto o sharp do seu lockfile não trouxer libheif corrigida, evite depender de AVIF no pipeline de imagens — os builds patchados do Next já desabilitam a otimização AVIF, e defesa em profundidade não faz mal
- Rode pnpm audit --audit-level high no CI — mas lembre: audit enxerga CVEs conhecidas em pacotes JS, não regressões em libs nativas empacotadas
- Considere minimumReleaseAge no gerenciador de pacotes: o pnpm 11 passou a recusar versões publicadas há menos de ~24h por padrão — janela mínima contra releases envenenados
- Se roda Node em Windows: migre para Linux ou contêiner. A superfície de plataforma é mantida por muito menos gente
- Monitore os advisories do Next.js (GHSA) e o blog oficial — o programa de releases agendados publica as datas com antecedência
- WAF na frente do endpoint de imagens ajuda contra varredura automatizada, mas não substitui o patch
O tempo médio entre a publicação de uma CVE e a exploração automatizada caiu para horas. Security release com data marcada é o novo normal — insira a janela de patch no calendário operacional, igual você faz com a renovação do certificado TLS.