CVE-2026-32740: RCE no Next.js via processamento de imagens AVIF
Técnicas e Métodos de AtaqueOntem, 07:01
CVE-2026-32740: RCE no Next.js via processamento de imagens AVIF
Adrian Tiron, pesquisador da Fortbridge, demonstrou como uma vulnerabilidade de corrupção de memória no
libheif pode levar à execução remota de código em uma aplicação Next.js deliberadamente vulnerável usando sharp. A pesquisa é notável por demonstrar uma cadeia completa de exploração com ASLR, NX e PIE habilitados.Qual é a Vulnerabilidade?
CVE-2026-32740 é um heap-buffer overflow em
HeifPixelImage::copy_image_to(), uma função no libheif responsável por montar blocos de imagem HEIF/AVIF decodificados em uma grade.
Para os canais de cor Cb e Cr subsampleados, a função arredonda independentemente a linha de destino e o número de linhas a copiar. Com blocos AVIF especialmente criados, esses cálculos podem fazer com que uma linha seja escrita além do buffer de croma alocado.
Os pesquisadores construíram uma imagem AVIF com quatro blocos empilhados verticalmente, cada um com 33 pixels de altura, em uma tela de 116 × 132 pixels. O bloco final fez com que uma linha extra de croma fosse copiada além do limite do buffer, proporcionando uma escrita fora dos limites controlada de 58 bytes.Como o Overflow Foi Transformado em RCE?
A corrupção de memória sozinha normalmente causaria um crash. O pesquisador desenvolveu uma cadeia de exploração em vários estágios:
• Contornando o ASLR por meio de um vazamento de informações. Um AVIF separado especialmente criado fez com que
sharp retornasse um PNG contendo ponteiros de memória nativa não inicializada em seus dados de canal alfa. Ao combinar quatro ponteiros vazados com um perfil conhecido de pilha nativa, o exploit recuperou o endereço base randomizado do libvips.
• Transformando o overflow em uma escrita em endereço arbitrário restrita. O overflow de 58 bytes corrompeu os dois bytes inferiores de um ponteiro de filho direito em um nó de árvore rubro-negra std::map usado pelo libheif para armazenar metadados de plano de imagem. Isso redirecionou a busca pelo canal Cr para um nó de mapa forjado contendo um descritor ImagePlane controlado. O descritor especificava o endereço de destino para cópias de pixels subsequentes, criando uma primitiva restrita de write-what-where.
• Sequestrando a execução através da GOT. O exploit usou a escrita de pixel controlada para sobrescrever memcpy@GOT com o endereço da rotina interna g_module_open_full do libvips. A próxima chamada através da mesma entrada GOT transferiu a execução para essa rotina, que envolve dlopen e pode carregar uma biblioteca compartilhada nativa.
• Executando um comando. O atacante havia previamente enviado uma biblioteca compartilhada ELF disfarçada como uma imagem chamada uploads/x.jpg. Quando o carregador GModule abriu este arquivo, o construtor da biblioteca executou /usr/bin/id e retornou sua saída para o listener do atacante.
O exploit não exigia uma cadeia ROP ou conhecimento do endereço randomizado do executável Node.js. O endereço de código necessário foi calculado a partir da base vazada do libvips.Resultados do Experimento
O PoC foi testado contra uma aplicação deliberadamente vulnerável usando:
• Next.js: 15.5.23
• sharp: 0.34.4
• libvips: 8.17.2
• libheif: 1.20.2
Os dois ambientes de teste Linux x86-64 usaram builds diferentes do Node.js com PIE habilitado: versão 25.8.1 no Ubuntu e versão 20.19.2 no Debian 13.
Todas as 20 tentativas de exploração tiveram sucesso: dez contra processos Ubuntu novos e dez contra processos Debian novos. Em todas as execuções, o ASLR randomizou o endereço base do
libvips, e o exploit recuperou o endereço correspondente através do vazamento de informações do PNG.Limitações
A cadeia demonstrada requer uma rota vulnerável de processamento de AVIF, acesso à saída da imagem convertida e um mecanismo de upload que preserve uma biblioteca compartilhada ELF controlada pelo atacante em um caminho previsível acessível ao carregador nativo.
O exploit também depende de builds exatas de bibliotecas nativas, comportamento do alocador e layouts de memória. Versões ou configurações diferentes podem exigir um novo perfil de exploit verificado independentemente.
Esses resultados demonstram RCE sob as condições documentadas da aplicação, não exploração universal de toda implantação Next.js ou sharp.
Mitigação
A Fortbridge recomenda atualizar o libheif para a versão 1.22.0 ou posterior e garantir que a biblioteca corrigida esteja realmente incluída nas dependências nativas carregadas por
sharp e libvips. Atualizar apenas o pacote JavaScript de nível superior pode deixar uma biblioteca vulnerável empacotada no lugar.
Defesas adicionais incluem validar arquivos enviados pelo conteúdo real, gerar nomes de arquivo no lado do servidor, manter uploads fora do diretório de trabalho da aplicação e processar imagens em workers isolados com privilégios mínimos.Vulnerabilidades
Pesquisadores
Produto
Mais