Divulgadas vulnerabilidades de DoS e exposição de código-fonte em React Server Components

• Foram descobertas e divulgadas novas vulnerabilidades de negação de serviço (DoS) e exposição de código-fonte em React Server Components
• Essas vulnerabilidades não permitem execução remota de código (RCE), mas apresentam risco de interrupção do servidor ou vazamento de código
• Os pacotes afetados são react-server-dom-webpack, react-server-dom-parcel e react-server-dom-turbopack nas versões 19.0.0~19.2.2, e as versões corrigidas são 19.0.3, 19.1.4, 19.2.3
• A vulnerabilidade de DoS (CVE-2025-55184, CVE-2025-67779) pode causar loop infinito no servidor por meio de requisições HTTP maliciosas, e a vulnerabilidade de exposição de código-fonte (CVE-2025-55183) pode retornar partes do código de funções do servidor
• A equipe do React recomenda atualização imediata e explica que essa divulgação adicional faz parte do processo normal do ciclo de resposta de segurança

---

Visão geral das vulnerabilidades recém-divulgadas

• Pesquisadores de segurança descobriram duas vulnerabilidades adicionais durante a validação do patch de uma vulnerabilidade crítica divulgado na semana passada
• As novas vulnerabilidades não permitem execução remota de código (RCE), e o patch existente para React2Shell continua válido
• As vulnerabilidades recém-divulgadas são as seguintes
  • Negação de serviço (DoS) — CVE-2025-55184, CVE-2025-67779 (CVSS 7.5, alta gravidade)
  • Exposição de código-fonte — CVE-2025-55183 (CVSS 5.3, gravidade média)
• A equipe do React recomenda atualização imediata

Incompletude do patch anterior

• O patch das versões 19.0.2, 19.1.3 e 19.2.2 distribuído na semana passada estava incompleto, sendo necessário atualizar novamente
• A correção completa está incluída nas versões 19.0.3, 19.1.4, 19.2.3
• É preciso seguir as instruções de atualização da publicação anterior
• Mais detalhes serão divulgados após a conclusão da distribuição da correção

Pacotes e versões afetados

• A vulnerabilidade está presente nos mesmos pacotes e versões da CVE-2025-55182
• Versões afetadas: 19.0.0~19.2.2
• Pacotes afetados:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• Versões corrigidas: 19.0.3, 19.1.4, 19.2.3
• Apps que não usam servidor ou não oferecem suporte a React Server Components não são afetados

Padrão comum em divulgações de vulnerabilidades subsequentes

• Após a divulgação de um CVE crítico, vulnerabilidades subsequentes costumam ser encontradas durante a análise adicional dos caminhos de código relacionados
• Como exemplo, é citado o caso em que CVEs adicionais foram relatados após o Log4Shell
• Essas divulgações adicionais indicam que a resposta de segurança está funcionando normalmente

Frameworks e bundlers afetados

• Os frameworks e bundlers a seguir incluem ou dependem dos pacotes vulneráveis do React
  • next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, rwsdk
• É preciso seguir as instruções de atualização da publicação anterior

Medidas de mitigação por provedores de hospedagem

• Foram aplicadas medidas temporárias de mitigação em cooperação com vários provedores de hospedagem
• No entanto, não se deve depender dessas medidas e é necessário atualizar imediatamente

Orientações relacionadas ao React Native

• Usuários que usam apenas React Native não precisam de ação adicional
• Em ambientes de monorepo, é necessário atualizar apenas os seguintes pacotes
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• react e react-dom não precisam ser atualizados
• Os detalhes relacionados podem ser consultados na issue do GitHub do React Native

Alta gravidade: negação de serviço (DoS)

• CVE-2025-55184, CVE-2025-67779, CVSS 7.5
• Quando uma requisição HTTP maliciosa é enviada para um endpoint de função de servidor do React, pode ocorrer um loop infinito durante o processo de desserialização
• O processo do servidor pode parar e consumir CPU de forma excessiva
• Mesmo sem implementar diretamente um endpoint de função de servidor, um app com suporte a React Server Components pode estar vulnerável
• O patch distribuído hoje resolve o problema ao evitar loops infinitos
• Como a correção inicial estava incompleta, ela foi complementada por uma vulnerabilidade adicional (CVE-2025-67779)

Gravidade média: exposição de código-fonte

• CVE-2025-55183, CVSS 5.3
• Uma requisição HTTP maliciosa pode retornar parte do código-fonte de uma função do servidor
• Isso ocorre quando a função do servidor expõe, de forma explícita ou implícita, argumentos do tipo string
• No código de exemplo, segredos codificados diretamente como uma chave de conexão com banco de dados podem ser expostos
• O patch resolve o problema ao impedir a conversão do código-fonte da função do servidor em string
• O escopo da exposição fica limitado ao código interno da função do servidor, e segredos em tempo de execução (process.env.SECRET etc.) não são afetados
• É necessário verificar com base no bundle de produção

Linha do tempo

• 3 de dezembro: Andrew MacPherson reporta exposição de código à Vercel e ao Meta Bug Bounty
• 4 de dezembro: RyotaK reporta a vulnerabilidade de DoS
• 6 de dezembro: a equipe do React confirma os dois problemas e inicia a investigação
• 7 de dezembro: elaboração da correção inicial e definição do plano de validação
• 8 de dezembro: notificação a provedores de hospedagem e projetos open source
• 10 de dezembro: aplicação das medidas de mitigação e conclusão da validação do patch
• 11 de dezembro: Shinsaku Nomura reporta um DoS adicional, e CVE-2025-55183·55184·67779 são divulgados

Reportado por

• Andrew MacPherson (AndrewMohawk) — reportou a exposição de código-fonte
• RyotaK (GMO Flatt Security Inc) e Shinsaku Nomura (Bitforest Co., Ltd.) — reportaram as vulnerabilidades de negação de serviço

[GN⁺]

Comentários do Hacker News

• Os React Server Components (RSC) sempre pareceram desconfortáveis
  porque, olhando só para o código JavaScript, é difícil distinguir o que roda no cliente do que roda no servidor
  Além disso, para implementar isso é necessário um mecanismo profundo de RPC por serialização, que é opaco para o desenvolvedor e aumenta o risco de vulnerabilidades de segurança

  • Na época do pages router do NextJS, eu gostava porque a fronteira entre código de servidor e de cliente era clara
    Mas quando mudaram para o app router, ficou confuso. Como o código pode rodar nos dois lados, objetos como Headers nem sempre existem, então ficou difícil saber o que está sendo executado e onde
  • Quando vi que uma equipe em que entrei recentemente usava Next, perguntei: “alguém sabe como isso funciona?” e ninguém conseguiu explicar com clareza
    Quando React+Next funciona bem, parece mágica, mas ao trabalhar em equipe o problema é que a previsibilidade vai desaparecendo
  • Por isso sou fã do Inertia.js. O Inertia.js conecta de forma natural backends MVC tradicionais como Laravel, Rails e Django com ferramentas de frontend como React, Vue e Svelte
    Os papéis ficam claros, o trabalho é simples, e acho que é a escolha mais segura para a maioria dos projetos
  • Parece que RSC e SSR foram adotados em excesso
    Para landing pages ou páginas de marketing, SSR é útil, mas em apps como dashboards SaaS comuns há quase nenhum ganho em comparação com a complexidade
  • Fico curioso sobre o quanto outros frameworks (Angular, SvelteKit, Nuxt) estariam expostos a esse tipo de vulnerabilidade
    Será que o React só recebe mais atenção por ser popular, ou ele é estruturalmente mais arriscado?

• Dei uma olhada em RSC na semana passada, e a complexidade era alta demais, além de quase não haver documentação
  O React diz que ainda é um recurso experimental, mas o NextJS já o distribuiu amplamente
  Acho que vão surgir mais problemas de segurança, e o sistema de build do Next é complexo demais, a ponto de dificultar até o debug
  O custo é alto demais para o benefício obtido

  • Já havia reclamações há tempos de que o Next empacota “recursos do React que ainda não estão prontos para produção” como se fossem novidade pronta
    Por isso eu também deixei o Next. A carga cognitiva era alta demais para pouco retorno
  • O React já tem há muito tempo um problema de falta de documentação
    Não só no RSC, mas de forma geral os guias claros sempre demoraram a aparecer, e ferramentas como CRA nem chegam a ser reconhecidas oficialmente
    Só agora a documentação de useEffect ficou boa, mas tarde demais
    Mesmo em 2025, ainda uso isso no trabalho, e ainda falta documentação clara

• A essência do SPA era “enviar o app inteiro para o cliente e trocar apenas dados com o servidor”

  • Mas agora, no ecossistema C#, o Blazor Server está em alta
    Como no antigo .aspx Web Forms, todo clique e entrada é enviado ao servidor, e o DOM alterado volta depois
    Na prática, parece um retorno ao modelo antigo, o que é meio absurdo
  • No fim, muitos desenvolvedores voltaram a entender por que existe a renderização no lado do servidor e regressaram a frameworks full-stack como PHP, Rails e Spring
  • Mas hoje em dia é comum fazer sites estáticos com bibliotecas como React, o que é mais lento e mais complexo do que uma combinação simples de template engine + JS
    É uma pena que tenha se perdido o “senso de escolher a ferramenta certa”
  • Claro, RSC não é para SPA puro. É uma abordagem com outro objetivo

• Neste aviso de segurança, a frase que mais chamou atenção foi “quando um CVE crítico é descoberto, vulnerabilidades subsequentes costumam aparecer”
  Antes mesmo de explicar o escopo do problema, o impacto ou as formas de mitigação, parecia que estavam tentando justificar o CVE, o que me deixou desconfortável

  • Mas há quem veja de outra forma: “isso não é uma justificativa, é apenas uma explicação sobre o ponto que as pessoas mais querem saber primeiro”
  • Disseram que ajustaram a redação com base no feedback → link do PR corrigido
  • Alguém descreveu isso como gestão de percepção (perception management)
    Artigo relacionado na Wikipédia
  • Também há quem veja interesses de carreira envolvidos nessa questão
  • Alguém disse: “isso parece um texto escrito pela equipe de marketing da Vercel”

• Há 15 anos, o Opa já tentava algo parecido
  Separava automaticamente código de cliente e servidor e introduziu uma sintaxe parecida com JSX
  Mas, ao reforçar a análise de segurança, o compilador ficou enorme, e no fim perceberam a importância de uma separação clara em vez do conceito de app único
  Talvez algum dia LLMs consigam gerar esse tipo de código automaticamente, mas por enquanto acho melhor ter uma estrutura simples

  • Na prática, a vulnerabilidade do RSC não vem tanto da divisão de código, mas das características dinâmicas do processo de serialização/desserialização
    Estão em andamento correções para bloquear problemas como poluição de protótipos em JS, toString de função e override de Promise
    O RSC distingue ambientes com validação estática como import "server-only" ou import "client-only", então estruturalmente é uma abordagem segura
  • Existe também um projeto com ideia semelhante chamado Electric Clojure → link
  • E vale lembrar que o Ocsigen Eliom tentou esse conceito antes do Opa

• O React era melhor quando era pequeno e simples, cumprindo o papel de View do MVC
  Agora parece inchado, com funções demais

  • Mas o RSC é uma biblioteca separada, então não vem incluído na instalação padrão do React
  • Se quiser voltar para a versão antiga, basta git checkout v15.0.0

• O RSC nunca deveria ter existido
  Para a maioria dos apps, renderizar HTML no servidor já basta, e os casos que realmente precisam de SPA são minoria
  O RSC só aumentou a complexidade e as vulnerabilidades de segurança

  • Concordo. Mas ecossistemas empurrados por bootcamps e capital de risco continuam forçando essa direção
    Projetos como Bun e Vercel vendem a ilusão de uma “utopia JS em que tudo funciona perfeitamente”, então essa tendência não deve desaparecer tão cedo

• Já discuti sobre RSC com Dan Abramov no X
  Ele disse que era um recurso inovador, mas eu disse que era uma “arma para atirar no próprio pé”. No fim, foi isso mesmo que aconteceu

  • Pessoalmente, já construí app com RSC e ainda gosto dessa abordagem
    Só subestimaram a possibilidade de bugs no nível do protocolo. Esta vulnerabilidade está concentrada no protocolo de serialização
    A comunidade de segurança só agora está analisando isso a fundo, então seria bom se a equipe tivesse reagido antes
  • Sistemas bem-sucedidos tendem a virar monstros por causa de expansão excessiva
    O React também explodiu em complexidade ao passar de biblioteca simples de renderização para um runtime
  • Pessoalmente, não acho a abordagem do Dan tão brilhante assim
    Em comparação, Vue e Vite me parecem muito mais elegantes em termos de design → site pessoal de Evan You
  • Claro, a maioria das ideias fracassa, então também é preciso tomar cuidado com uma postura puramente crítica
    Às vezes uma tentativa ousada acaba sendo um grande acerto
  • Também houve um comentário encorajador dizendo: “talvez você seja melhor do que ele”

• Se o RSC é uma tentativa de o frontend engolir o backend, o HTMX é o oposto
  O HTMX mantém a fronteira cliente-servidor, então o lado do backend é seguro, mas no frontend há risco de XSS

  • Mas o HTMX já resolve o problema de XSS com o escape automático da template engine
    Texto relacionado

• A equipe do Next anunciou uma nova atualização de segurança → NextJS Security Update 2025-12-11
  Afeta as versões 14.x, 15.x e 16.x