Vulnerabilidade de execução remota de código (RCE) em React e Next.js

• Foi relatada uma vulnerabilidade de segurança que permite execução remota de código (RCE) em React e Next.js
• O problema ocorre dentro do pacote Next.js e um atacante pode induzir execução de código arbitrário por meio de entradas maliciosas
• A Vercel divulgou a vulnerabilidade por meio do aviso de segurança do GitHub (GHSA-9qr9-h5gf-34mp) e lançou uma versão atualizada
• Os usuários devem fazer upgrade para a versão mais recente para mitigar a vulnerabilidade
• Este caso novamente enfatiza a importância da gestão de segurança em nível de framework

---

Visão geral da vulnerabilidade RCE

• Foi encontrada uma vulnerabilidade de execução remota de código em ambientes Next.js e React
  • Há risco de um atacante executar JavaScript arbitrário no servidor
• A vulnerabilidade ocorre no processo de tratamento de código interno do pacote Next.js
  • Não foram divulgados detalhes específicos sobre função ou módulo vulnerável

Impacto e resposta

• A Vercel anunciou oficialmente o problema por meio do aviso de segurança do GitHub (GHSA-9qr9-h5gf-34mp)
  • O aviso foi publicado na seção de avisos de segurança do repositório Next.js
• As versões afetadas não foram especificadas, mas houve lançamento de uma versão atualizada
  • É recomendado que os usuários façam upgrade para a versão estável mais recente

Recomendações e medidas de mitigação

• Todos os projetos que usam o pacote Next.js devem imediatamente checar a versão
  • A versão do Next.js no package.json deve ser mantida na mais recente
• A Vercel não mencionou medidas de mitigação adicionais além da publicação da versão corrigida
• Os detalhes técnicos da vulnerabilidade permanecem não divulgados, com apenas informações limitadas fornecidas por razões de segurança

Importância

• Esta vulnerabilidade evidencia o risco de execução de código em ambientes de renderização no servidor
• Operadores de serviços baseados em React e Next.js devem aplicar atualizações de segurança regularmente
• Uma vulnerabilidade de segurança em nível de framework pode ter impacto direto na segurança geral da aplicação inteira

[GN⁺]

Opinião no Hacker News

• Esta vulnerabilidade é um caso em que o pior cenário sobre o qual já se alertava desde a introdução de RSC/server actions acabou se tornando realidade
  O servidor desserializou diretamente entradas não confiáveis do cliente, localizou o módulo e o nome do export e os executou
  Dá para bloquear com um patch de hasOwnProperty, mas o problema fundamental é que não se reconheceu com clareza que o React está criando uma camada de RPC
  Frameworks tradicionais de RPC como gRPC ou SOAP deixam as fronteiras claras com esquemas e definições de serviço explícitos, mas o React é perigoso porque expõe toda API que o bundler consegue ver
  É bastante provável que problemas de segurança causados por esse tipo de design continuem se repetindo no futuro

  • Isso parece ser simplesmente um problema de descuido
    Mesmo com um esquema explícito, não adianta se na etapa final você permite que uma entrada não confiável referencie qualquer objeto no namespace do servidor
  • Na prática, nem todo endpoint que o cliente pede fica exposto
    Só funções marcadas com "use server" são expostas, e a equipe do React sabe que está projetando um sistema de RPC
    Esse tipo de bug poderia perfeitamente acontecer em outros sistemas de RPC também (sou contribuidor do React)
  • Se já havia alertas e ainda assim isso aconteceu, no fim só dá para ver como uma implementação descuidada
  • Do ponto de vista do usuário comum, fica a dúvida se não usar essa abordagem já seria suficiente para estar seguro
    Mas manter um repositório privado antigo também não é uma boa opção

• O único mérito do Next é o build estático
  Se o suporte a isso acabar, não haverá mais motivo para usá-lo

• Segundo o aviso de segurança da Facebook/Meta, existe uma vulnerabilidade de execução remota de código (RCE) pré-autenticação nas versões 19.0.0~19.2.0 do React Server Components
  O aviso no blog oficial do React também explica que, por causa da estrutura em que o cliente pode chamar funções do servidor, um atacante pode montar requisições HTTP maliciosas e executar código arbitrário no servidor

  • Se a correção foi adicionar uma verificação com hasOwnProperty, o ataque provavelmente envolvia referenciar propriedades da cadeia de protótipos (__proto__ etc.)
  • Se “o cliente pode chamar funções do servidor” é uma funcionalidade intencional, isso parece um design bem assustador

• O commit de correção parece ser este commit
  Parece que ele foi squashado junto com várias outras mudanças, então os detalhes ficaram meio escondidos
  No código, dá para ver em 4 lugares um padrão que limita a lista de funções expostas por meio de whitelist

  • Ou talvez este commit seja a causa (“corrige uma vulnerabilidade crítica de segurança”, explicitamente)

• A Vercel já está bloqueando padrões de requisição maliciosa com proteção em nível de plataforma
  Veja o aviso
  A Cloudflare também reagiu preventivamente com uma regra de WAF

  • Em cooperação com vários parceiros, foram distribuídas medidas de mitigação preventiva
    Ainda assim, recomenda-se fortemente atualizar imediatamente as dependências de Next, React e outros meta-frameworks
  • Também vale ver o aviso de resposta da Netlify e o post no blog de Deno Deploy/Subhosting
  • Eu mesmo apliquei o patch e refiz o build, e também adicionei uma regra de WAF do Crowdsec para o caso de algo ter passado despercebido

• Usei o repositório PoC como referência para reproduzir a vulnerabilidade

  • Mesmo com react-server-dom-webpack corrigido, o RCE ainda executa, então parece que o mecanismo não bate completamente
    Seria bom ver uma demonstração em um projeto real de Next.js
  • Ainda assim, o texto explicando tudo ficou realmente impressionante

• A ponto de surgirem comentários como “sem Vercel, sem RCE”, este caso expõe a correlação entre ambiente de hospedagem e segurança

• Uma pontuação CVE 10.0 é assustadora em um projeto tão amplamente usado

  • O pacote afetado react-server-dom-webpack informa explicitamente que é “experimental e use por sua conta e risco”
    Mesmo assim, passa de 310 mil downloads semanais
  • Em casos assim, é preciso indicar claramente CVSS 10.0 para que isso não seja abafado por discurso de PR
  • React é amplamente usado, mas React Server Components ainda não é algo tão disseminado

• É difícil entender por que a equipe do React gasta tempo com funcionalidades tão confusas
  Fica a dúvida sobre o que isso tem de melhor que SSR e quanto ganho de performance realmente existe
  A experiência de desenvolvimento piorou desde a introdução dos Hooks, e em vez de melhorar isso, adicionaram outra camada de complexidade
  Eu preferiria que deixassem usar de forma natural o controle de fluxo nativo do JS na lógica dos componentes

  • Server Components não têm relação direta com SSR
    Eu vejo isso como uma camada de BFF (Backend for Frontend) componentizada
    Cada pedaço da UI se conecta diretamente à lógica de backend correspondente e consegue buscar dados sem chamadas fetch
    Isso facilita a evolução conjunta de frontend e backend e permite carregar apenas os dados necessários com granularidade fina
    No fim, isso permite incorporar de forma natural uma lógica de servidor específica para a UI dentro da estrutura dos componentes
  • É uma pena que o React tenha virado o “framework padrão”
    O modelo baseado em compilador do Svelte ou do React é muito mais fácil de lidar
  • No fundo, acho que o problema é a limitação da linguagem JS e a falta de concorrência
    Vue, Svelte e Angular exigem compiladores separados e extensões de arquivo próprias
    Já React/JSX recebe tratamento preferencial ainda na etapa do pré-processador
    Rust resolveu esse tipo de problema com seu sistema de macros — por exemplo, Leptos e Yew suportam JSX ou templates HTML dentro de arquivos .rs padrão
    Se o JS não ganhar esse tipo de extensibilidade, a web provavelmente continuará sendo um ambiente complexo e ineficiente
  • Eu gosto de hooks :)
  • RSC foi uma tentativa alternativa que surgiu porque não conseguiram tornar SSR rápido
    Tentaram reduzir a carga no lado do cliente, mas até isso passa a sensação de ter falhado

• Também vale ler a explicação detalhada no blog do React