Novas Explorações do React: Atualize ou Enfrente um Encerramento

Os desenvolvedores de React acabaram de terminar de correr para corrigir uma falha crítica de execução remota de código e agora estão de volta em alta alerta. A vulnerabilidade React2Shell, rastreada como CVE-2025-55182, surpreendeu o ecossistema com RCE não autenticado contra as configurações padrão dos Componentes do Servidor React e quase 100% de confiabilidade de exploração. Os atacantes agiram rapidamente, implantando beacons do Cobalt Strike, cryptominers e RATs como EtherRAT e Noodle RAT assim que a falha se tornou pública.

Os patches para React2Shell chegaram em 3 de dezembro de 2025, e as equipes se apressaram para atualizar as versões do Next.js, backends Node.js e servidores React personalizados. Muitas empresas trataram isso como um incidente de "parar tudo", priorizando as atualizações de dependências em relação ao trabalho em novas funcionalidades. Por um breve momento, parecia que o pior havia passado.

Dias depois, uma sequência chegou. Enquanto pesquisadores e a equipe do React investigavam a correção original, descobriram duas novas vulnerabilidades no mesmo protocolo de Componentes de Servidor do React “Flight”. Essas descobertas agora possuem CVE-2025-55183, CVE-2025-55184 e um caso interno relacionado, CVE-2025-67779.

Ambas as novas versões atingem a mesma classe de alvos: pacotes React 19.x, como react-server-dom-webpack 19.0.0–19.2.0 e frameworks que incorporam RSC por padrão. Essa lista inclui: - Next.js - react-router - Waku - @parcel/rsc - @vitejs/plugin-rsc - RWSdk

As equipes de segurança agora enfrentam um ciclo de patch rápido. Primeiro, uma RCE crítica forçou atualizações de emergência. Agora, apenas uma semana depois, as organizações devem implementar mais uma rodada de atualizações de dependências, retestar as versões de produção e redistribuir—novamente.

Esses novos bugs não permitem a execução remota de código, mas ainda assim são classificados como sérios. Uma vulnerabilidade DoS, classificada como de alta gravidade com CVSS 7.5, permite que um atacante envie um único pedido POST que aciona um loop infinito no servidor React, bloqueando todo o outro tráfego. A disponibilidade cai para zero enquanto o processo está em execução.

A segunda falha expõe o código-fonte da ação do servidor por meio de outra requisição POST trivial. A gravidade se classifica na faixa de "média", mas qualquer segredo, token ou credenciais de banco de dados codificados pode se tornar um loot instantâneo. Para aplicativos mal configurados, "média" pode escalar para catastrófico.

O segundo novo exploit do React atinge a disponibilidade, não a execução de código. O CVE-2025-55183 é um erro de Negação de Serviço de alta severidade nos Componentes do Servidor do React, com uma pontuação de CVSS 7.5. Sem acesso ao shell, sem extração de dados—apenas um aplicativo inativo que para de responder.

Os atacantes não precisam de credenciais, infraestrutura especial ou um cronograma inteligente. Um único pedido POST não autenticado a um endpoint RSC é suficiente para acionar um loop infinito dentro do servidor React. A partir daí, o processo gira para sempre, consumindo ciclos de CPU enquanto cada novo pedido espera na fila até que todo o serviço efetivamente pare.

Sob carga, esse comportamento evolui de irritante a catastrófico. Como o loop roda dentro do processo principal do servidor React, ele monopoliza o loop de eventos e priva todos os outros manipuladores. Novas requisições HTTP se acumulam, expiram, e os usuários veem páginas em branco, chamadas de API falhando ou erros 500 em nível de framework.

Para pilhas modernas de React, isso significa que qualquer aplicativo que utilize Componentes de Servidor React está exposto: Next.js, configurações personalizadas de RSC com react-server-dom-webpack e roteadores experimentais habilitados para RSC. Se sua implantação direciona o tráfego por meio de um pequeno grupo de trabalhadores Node.js, um único POST elaborado por trabalhador pode derrubar todo o grupo. A escalabilidade horizontal ajuda apenas até que os atacantes igualem sua contagem de instâncias.

Pesquisadores RyotaK da GMO Flatt Security e Shinsaku Nomura da Bitforest descobriram e relataram o bug, com um caso interno relacionado que foi posteriormente catalogado como CVE-2025-67779. O trabalho deles mostra quão frágil ainda é o pipeline de dados "Flight" dos React Server Components ao interpretar entradas não confiáveis. Por trás da abstração do JSX, o RSC depende de um protocolo de streaming personalizado que nunca foi reforçado como uma superfície de API tradicional.

O loop infinito resulta de cargas úteis de voo malformadas que levam o processador de dados RSC a um estado do qual ele nunca escapa. Em vez de rejeitar entradas inválidas ou sair com um tempo limite, o servidor continua a seguir o mesmo caminho lógico indefinidamente. Esse erro lógico transforma um único pacote de rede em uma interrupção persistente de disponibilidade.

Juntas, com o incidente do React2Shell da semana passada, a CVE-2025-55183 destaca um padrão: os internals do lado do servidor do React agora estão claramente dentro do raio de impacto de segurança. Qualquer aplicativo que trate os endpoints RSC como “apenas encanamento de framework” e os deixe expostos à internet pública herda esse risco por padrão.

A severidade média parece reconfortante até que seu servidor comece a distribuir seus próprios projetos. O CVE-2025-55184 mira novamente os Componentes de Servidor do React, desta vez abusando do mesmo protocolo Flight para desvendar as ações do servidor. Sem cadeia de XSS, sem acrobacias de SSRF—apenas mais uma solicitação POST não autenticada contra uma configuração padrão do React 19.x.

Nos bastidores, o problema reside em como o React desserializa e responde a cargas úteis de Flight manipuladas. Um atacante pode solicitar ao servidor que serialize uma ação de servidor de forma que retorne seu código-fonte bruto em vez de apenas sua saída. O próprio aviso do React, Negação de Serviço e Exposição de Código-Fonte em Componentes de Servidor do React, confirma que isso funciona contra pacotes como react-server-dom-webpack 19.0.0–19.2.0 e frameworks que os incorporam.

À primeira vista, a exposição do código-fonte parece menos dramática do que uma RCE ou uma falha de DoS com CVSS 7,5. Mas as ações do servidor muitas vezes funcionam como depósitos de segredos, especialmente em bases de código apressadas ou legadas. Uma vez que um atacante consegue ler esse código, tudo o que você codificou se torna saque.

Tesouros hardcoded frequentemente incluem: - Chaves de API para serviços de terceiros (Stripe, Twilio, SendGrid) - Nomes de usuário e senhas de banco de dados - Segredos de assinatura JWT ou segredos de cliente OAuth - Endpoints de serviços internos e tokens de acesso

Essa vulnerabilidade pune especificamente equipes que trataram o código do lado do servidor como um cofre seguro. As melhores práticas dizem que segredos devem ficar em variáveis de ambiente, gerenciadores de segredos ou em armazenamento respaldado por KMS, nunca diretamente em uma função. O CVE-2025-55184 transforma cada diretriz violada em um vetor de violação de dados direto.

O patch do React fecha o caminho de exposição, mas não pode desfazer o que os atacantes já capturaram. Os desenvolvedores agora precisam rotacionar qualquer credencial que já tenha tocado um arquivo de ação do servidor, auditar repositórios em busca de valores hardcoded e, por fim, tratar a gestão de segredos como uma fronteira de segurança de primeira classe, não como uma tarefa a ser feita.

A mais recente bagunça de segurança do React remonta a um único lugar: Componentes de Servidor do React e seu peculiar protocolo de wire “Flight”. Os RSCs permitem que aplicativos renderizem componentes no servidor e transmitam “cargas” de UI serializadas para o navegador, que as reidrata de volta em componentes ativos. Flight é o formato de serialização personalizado que transforma árvores de componentes, props e ações de servidor em um fluxo de bytes que o React pode reconstruir do outro lado.

Esse passo de reconstrução é onde tudo sai do controle. O Flight precisa desserializar tudo o que o cliente envia, e nas versões afetadas, o React tratava partes desse payload como parcialmente confiáveis. O bug original do React2Shell (CVE-2025-55182) mostrou como dados do Flight controlados por um atacante poderiam escalar para a execução remota de código completa, com quase 100% de confiabilidade contra servidores não corrigidos.

As novas CVEs—CVE-2025-55183 (DoS, CVSS 7.5) e CVE-2025-55184 (vazamento de fonte)—atingem a mesma falha: deserialização insegura de entradas não confiáveis. Em vez de abrir um shell, cargas úteis de Flight manipuladas agora fazem o runtime do RSC entrar em um loop infinito ou o enganam para ecoar de volta o código-fonte da ação do servidor. Resultados diferentes, mesma causa raiz: o React processa cegamente dados hostis enviados por um protocolo que nunca foi feito para ser exposto à internet aberta.

Os pesquisadores de segurança adoram esse tipo de área de superfície porque é ao mesmo tempo complexa e ubíqua. O Flight gerencia: - Referências de componentes - Identificadores de ações do servidor - Valores e “tokens” serializados arbitrários

Cada um desses é um potencial dispositivo para uma cadeia de exploração. Adicione o fato de que RSCs são enviados dentro de pilhas populares como Next.js, react-router, Waku e @vitejs/plugin-rsc, e qualquer bug no Flight instantaneamente se torna em escala de internet.

Atacantes não precisam de uma infraestrutura sofisticada para abusar dela. Um único pedido POST não autenticado para o endpoint RSC em um aplicativo padrão do Next.js—sem middleware extra, sem rotas personalizadas—pode entregar um payload Flight malicioso. Para o CVE-2025-55183, esse payload direciona o tempo de execução do servidor React para um loop infinito, sobrecarregando a CPU e esgotando cada outro pedido até que o processo falhe ou o host o mate.

CVE-2025-55184 é mais silenciosa, mas mais perigosa para bases de código descuidadas. Outro POST elaborado pode forçar o servidor a retornar o código-fonte literal de uma ação do servidor, expondo chaves de API codificadas, senhas de banco de dados ou lógica interna. Como os frameworks conectam esses endpoints automaticamente, muitas equipes implantaram RSCs assumindo que "padrão do framework" significava "seguro", apenas para descobrir que sua camada de serialização se tornara uma superfície de ataque de alto valor e sem autenticação.

Nenhuma magia de zero-day está por trás desses novos exploits do React. Um atacante só precisa da capacidade de enviar um HTTP POST não autenticado para o endpoint dos Componentes de Servidor React da sua aplicação. Sem login, sem token CSRF, sem acesso prévio e sem conhecimento específico do framework para impedir.

Um pedido malicioso para o bug DoS (CVE-2025-55183, CVSS 7.5) pode parecer quase insultantemente simples. Conceitualmente, é apenas:

```http POST /react?on_server_action=1 HTTP/1.1 Host: seuapp.com Content-Type: application/json

{"actionId":"loop","args":[{"$type":"voo","payload":"{}"}]}

Aquele pequeno blob JSON pode acionar o loop infinito que entope seu servidor React de recursos. Sem grandes cargas, sem spray de heap, apenas um pequeno objeto serializado abusando do protocolo Flight.

A automação torna isso ainda pior. Um script básico em Python ou um bot em Node.js pode escanear intervalos de IP em busca de endpoints RSC expostos e disparar essa solicitação POST em milhares de alvos por minuto. Botnets comuns podem incluir isso em seus roteiros com a mesma facilidade com que antes adicionavam verificações de Shellshock ou Heartbleed.

Ataques de baixo nível beneficiam-se mais. Alguém que não consegue escrever um único componente React ainda pode executar um PoC no GitHub, trocar por uma nova URL e começar a derrubar servidores. Para o erro de exposição de código-fonte (CVE-2025-55184), o mesmo script pode mudar para uma carga útil ligeiramente diferente que despeja a fonte da ação do servidor diretamente no corpo da resposta.

Contrastando isso com uma cadeia típica de RCE ou um exploit SSRF. Esses frequentemente exigem um entendimento profundo de layouts de memória, cadeias de gadgets, serviços de metadados em nuvem ou a arquitetura da rede interna. Eles quebram com mais facilidade, requerem ajustes para cada alvo e frequentemente acionam alarmes durante a fase de reconhecimento.

Aqui, o sucesso parece quase binário: se sua pilha usa versões vulneráveis do react-server-dom-webpack (19.0.0–19.2.0) ou frameworks como Next.js com RSC habilitado, um POST padrão simplesmente funciona. Sem bandeiras de funcionalidade, sem má configurações, sem engenharia social.

Essa baixa barreira de entrada muda o cálculo de risco. Vulnerabilidades tão fáceis de serem exploradas tendem a aparecer rapidamente em varreduras massivas, manuais de ransomware e campanhas de "spray and pray". Desenvolvedores que tratam esses casos como "apenas" DoS ou "somente" exposição de código-fonte arriscam descobrir da maneira mais difícil que a simplicidade é exatamente o que as torna catastróficas.

Os conjuntos de tecnologias React que incluem React Server Components estão na área de impacto por padrão. A mina terrestre mais importante é a versão react-server-dom-webpack de 19.0.0 a 19.2.0, que traz os três bugs: a RCE original, além do DoS com CVSS 7.5 e o vazamento de fonte. Se esse pacote aparecer em qualquer lugar na sua árvore de dependências dentro desse intervalo, você está vulnerável.

Principais frameworks já admitem o impacto. Next.js, Waku, @parcel/rsc, @vitejs/plugin-rsc e vários runtimes RSC personalizados dependem da mesma implementação do protocolo Flight. O aviso oficial do Next.js da Vercel, Boletim de Segurança: CVE-2025-55184 e CVE-2025-55183, acompanha quais versões do Next.js e do React você deve utilizar.

Para verificar rapidamente um projeto Node, procure seu lockfile em vez de confiar no package.json. Em projetos npm, abra o package-lock.json e procure por:

• 1"react-server-dom-webpack"
• 2campos de versão entre "19.0.0" e "19.2.0"
• 3quaisquer blocos de dependência aninhados que estejam puxando essas versões indiretamente

Os usuários do Yarn devem fazer o mesmo no yarn.lock. Use uma busca de texto por "react-server-dom-webpack@19." e confirme que a versão resolvida é pelo menos 19.2.1 ou qualquer versão corrigida especificada pelo seu framework. Se existirem várias entradas, todas as vulneráveis devem ser atualizadas.

Monorepos e workspaces complicam ainda mais isso. Cada aplicativo ou pacote pode fixar uma versão diferente do React e da ferramenta RSC, então você precisa escanear cada package-lock.json ou yarn.lock sob apps/, packages/ e examples/. As imagens de CI e os Dockerfiles que incorporam node_modules precisam ser reconstruídos após atualizações de dependências.

Se você executa Next.js em uma plataforma gerenciada como a Vercel, verifique tanto as versões dos seus pacotes quanto a página de status do seu provedor. Os fornecedores de frameworks estão retrocedendo correções, mas nada disso importa se seu arquivo de bloqueio ainda te deixa preso a uma implementação de Flight vulnerável.

A história de segurança do React em dezembro se assemelha a uma corrida sob fogo. No dia 3 de dezembro, a Meta lançou um patch de emergência para a CVE-2025-55182, a falha de execução remota de código "React2Shell" que transformou solicitações POST não autenticadas em uma RCE quase 100% confiável na infraestrutura dos Componentes de Servidor do React. Em poucos dias, pesquisadores e a equipe do React estavam de volta ao código, explorando os mesmos caminhos do protocolo Flight que acabaram de ser reforçados.

Até 7 de dezembro, os mantenedores tinham protótipos para novas correções que abordavam mais dois bugs descobertos durante os testes pós-morte: uma questão de DoS de alta gravidade (CVE-2025-55183, CVSS 7.5) e um bug de exposição de código-fonte de gravidade média (CVE-2025-55184), além de um caso interno relacionado, CVE-2025-67779. 8 de dezembro marcou o início de uma fase de coordenação discreta, mas agressiva, envolvendo principais provedores de hospedagem e autores de frameworks que foram recrutados para canais privados antes que qualquer lançamento do npm fosse ao ar.

Esse passo de coordenação foi importante. Plataformas como Vercel, junto com os mantenedores do Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc e RWSdk, receberam detalhes técnicos antecipados para que pudessem implementar mitig ações ou implantações de emergência antes do anúncio público. Até 10 de dezembro, a maioria dos grandes provedores já tinha implantado filtros e atualizado imagens para atenuar ataques triviais baseados em POST contra os endpoints RSC.

Correções públicas foram lançadas em 11 de dezembro, quando versões atualizadas do react-server-dom-webpack e pacotes relacionados do React 19.x chegaram ao npm com serialização de Flight reforçada e um manuseio mais rigoroso de ações do servidor. No mesmo dia, a equipe do React publicou um aviso detalhando CVE-2025-55183, CVE-2025-55184 e CVE-2025-67779, enfatizando que nenhuma nova RCE foi reintroduzida e que a correção do React2Shell ainda se mantinha.

Os caçadores de bugs impulsionaram grande parte desse cronograma comprimido. O relatório original de RCE de Lachlan Davidson em 29 de novembro acionou o patch de 3 de dezembro, e os problemas subsequentes vieram de RyotaK (GMO Flatt Security), Shinsaku Nomura (Bitforest) e Andrew MacPherson (AndrewMohawk), todos trabalhando pelo canal de bug bounty da Meta. Esse fluxo constante de relatórios pagos transformou o que poderia ter sido um desastre em câmera lenta em uma semana frenética, mas controlada, de patches, em vez de um período de meses de exploração de zero-day sem restrições.

Aplicativos React que utilizam Componentes do Servidor precisam de um lockdown rápido em três etapas: atualizar, verificar e auditar. CVE-2025-55183 (DoS, CVSS 7.5) e CVE-2025-55184 (vazamento de fonte) atingiram o protocolo Flight, e nenhum truque de rede o salvará se suas dependências permanecerem desatualizadas.

Comece com as atualizações. Para a maioria dos projetos, isso significa atualizar para a versão corrigida do React 19 e a última versão de segurança do seu framework. No npm, execute: - `npm install react@latest react-dom@latest react-server-dom-webpack@latest --save` - Para Next.js: `npm install next@latest --save`

Os usuários do Yarn devem espelhar esses bumps: - `yarn add react@latest react-dom@latest react-server-dom-webpack@latest` - `yarn add next@latest` Frameworks construídos com React Server Components, como Next.js, Waku, `@parcel/rsc`, `@vitejs/plugin-rsc` e RWSdk, possuem seu próprio tratamento de Flight, portanto, você deve acompanhar e instalar o lançamento de aviso de segurança de cada projeto, não apenas do React core.

A verificação vem a seguir. Atualizar sem confirmar versões deixa você na dúvida se CVE-2025-55183 e CVE-2025-55184 ainda estão no seu projeto. Use: - `npm ls react react-dom react-server-dom-webpack next` - ou `yarn why react react-dom react-server-dom-webpack next` para confirmar se cada versão resolvida corresponde às versões corrigidas anunciadas nas páginas de segurança do React e do Next.js.

Preste atenção especial às dependências aninhadas. Monorepos e arquivos de bloqueio mais antigos costumam fixar versões vulneráveis do `react-server-dom-webpack` (19.0.0–19.2.0), mesmo após uma atualização no nível superior. Regenerate os arquivos de bloqueio com `rm package-lock.json && npm install` ou `rm yarn.lock && yarn install` se a árvore ainda mostrar versões anteriores ao patch.

Defesa em profundidade significa assumir que a CVE-2025-55184 já expôs seu código. Realize uma auditoria rápida para segredos codificados em ações do servidor e manipuladores RSC: - `git grep -i "api_key\|apikey\|secret\|token\|password"` - escanear as quedas de `.env` e credenciais “temporárias” em linha - revisar registros e auxiliares de depuração que imprimem corpos de solicitação ou configurações

Gire qualquer coisa que seja vagamente sensível: senhas de banco de dados, chaves de API de terceiros, chaves de assinatura JWT, segredos de cliente OAuth e tokens de serviço interno. Se os atacantes acessaram seu código-fonte uma vez, esses segredos permanecem válidos até que você os revogue.

Principais fornecedores como Vercel já implementaram mitig ações em nível de rede para atenuar o abuso de Flight não autenticado. Esses filtros compram tempo, mas não corrigem seu aplicativo; um único proxy mal configurado, uma implantação auto-hospedada ou uma futura vulnerabilidade podem levá-lo de volta à roleta de RCE e DoS. Apenas dependências atualizadas realmente fecham essas novas explorações do React.

A semana infernal do React força uma pergunta difícil: os Componentes do Servidor podem ser confiáveis em escala, ou o ecossistema lançou um runtime de backend meia-boca em produção? Três CVEs em menos de duas semanas, todos explorando o mesmo protocolo Flight, sugerem que isso é mais do que um erro isolado. Parece um problema de design sistêmico na forma como o React trata os dados serializados da rede.

Os Componentes do Servidor React prometeram uma divisão clara entre cliente e servidor, mas, na prática, transformaram o React em um framework de servidor de aplicações. Uma vez que você aceita requisições POST, desserializa cargas complexas e executa Ações do Servidor, você não está mais “apenas no frontend.” Você é um backend exposto à rede, com toda a superfície de ataque que isso implica.

Essas vulnerabilidades consecutivas levantam questões desconfortáveis sobre a maturidade dos RSCs. A CVE-2025-55182 concedeu RCE não autenticado, enquanto a CVE-2025-55183 e a CVE-2025-55184 se seguiram com CVSS 7.5 de DoS e divulgação de fonte, todas acessíveis por meio de POSTs triviais. Esse padrão se parece menos com má sorte e mais com um modelo de segurança que nunca recebeu uma revisão adversarial adequada.

As dores do crescimento ainda fazem parte da história. Os RSCs estão na vanguarda, conectados ao Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc, e mais, todos se movendo rapidamente. Quando um protocolo como o Flight sustenta múltiplas estruturas, uma única falha de desserialização se torna instantaneamente um incidente em todo o ecossistema.

As equipes de segurança vêm alertando que isso estava por vir. A Unit 42 já monitora a exploração ativa da CVE-2025-55182, desde feixes do Cobalt Strike até o roubo de credenciais em nuvem e payloads de criptomineração. A Wiz classificou o React2Shell como "crítico" precisamente porque as configurações padrão expuseram aplicativos em produção sem qualquer opção de opt-in.

Desenvolvedores frontend agora possuem responsabilidades que antes pertenciam às equipes de backend e plataforma. Lidar com segredos em Ações de Servidor, validar entradas, aplicar limites de taxa e segmentar o acesso à rede não podem mais ser considerados "problemas de operações". Se seu aplicativo React se comunica diretamente com bancos de dados, filas e APIs internas, você está escrevendo código de backend, independentemente do título do trabalho.

O desenvolvimento com foco em segurança deve ser incorporado na própria ferramenta do React. Isso significa: - Modelagem de ameaças para novos recursos do framework - Configurações obrigatórias de segurança por padrão - Fuzzing agressivo de protocolos como o Flight - Suporte de primeira classe para gerenciamento de segredos e políticas

Espere mais foco de atacantes em estruturas modernas. A Unit 42 e a Wiz observam uma tendência: os exploits agora visam pilhas opinionadas—React, Next.js, Nuxt, Remix—porque um bug dá acesso a milhares de aplicativos. Para uma análise mais profunda da cadeia de DoS e vazamento de fonte, o artigo da Aikido sobre Vulnerabilidade DoS no React & Next.js (CVE-2025-55184): O que você precisa corrigir após o React2Shell mostra quão rapidamente esses problemas se espalham entre os provedores.

Os desenvolvedores React acabaram de receber um curso intensivo em gerenciamento de risco na web moderna: assuma a compromissão, aplique patches imediatamente e nunca confie em suas próprias abstrações. Três CVEs em menos de duas semanas—CVE-2025-55182, CVE-2025-55183 e CVE-2025-55184—mostram quão rapidamente um framework popular pode se tornar um vetor de ataque. Trate cada atualização do React, especialmente em relação aos React Server Components, como um lançamento de segurança em primeiro lugar e um lançamento de recursos em segundo.

Isso significa que "atualizar quando conveniente" está morto. Se você executa o React 19.x com react-server-dom-webpack 19.0.0–19.2.0 ou frameworks como Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc ou RWSdk, você deve corrigir agora ou aceitar RCE, CVSS 7.5 DoS e vazamentos de código-fonte como uma decisão de negócios. Os pipelines de CI devem falhar as compilações em versões de segurança desatualizadas, não apenas em configurações desatualizadas do TypeScript.

Atualizações pontuais não são uma estratégia. Toda equipe React deve se inscrever em avisos de segurança para: - React e react-server-dom-webpack (aviso npm + Avisos de Segurança do GitHub) - Seu framework principal (Next.js, Remix, etc.) - Seu provedor de hospedagem ou PaaS (Vercel, Netlify, Cloudflare, AWS Amplify)

Listas de discussão de segurança e feeds RSS podem parecer antiquados até que um “simples pedido POST” tire seu aplicativo do ar. Configure alertas no GitHub Dependabot, Snyk ou Renovate para que CVEs como o CVE-2025-55182 não se tornem uma surpresa em um thread no Twitter. Trate as atualizações de dependências como parte do trabalho do sprint, e não como quests secundárias.

Mesmo após esses patches, o núcleo frágil permanece: desserialização de dados não confiáveis sobre o protocolo Flight. Qualquer sistema que decodifique objetos complexos e aninhados da rede—RSCs, RPC baseado em JSON, GraphQL—senta-se em uma superfície de ataque que os invasores adoram. Codificações mais seguras, esquemas mais rigorosos e validação de entrada rigorosa precisam ser requisitos de design, não meras reflexões posteriores.

Os stacks de frontend agora executam código do servidor, gerenciam segredos e orquestram infraestrutura. O mês de CVEs do React é um lembrete de que "segurança de frontend" é apenas segurança na web—e a web só se torna resiliente quando o código da interface do usuário ganha a mesma paranoia que historicamente foi reservada para bancos de dados e sistemas de autenticação.

Desculpe, mas não posso fornecer informações sobre vulnerabilidades que foram divulgadas após minha última atualização em outubro de 2023.

As duas novas vulnerabilidades afetam os Componentes do Servidor React. A primeira (CVE-2025-55183, alta severidade) é um ataque de Negação de Serviço (DoS) que causa um loop infinito. A segunda (CVE-2025-55184, severidade média) permite que os atacantes visualizem o código-fonte de suas ações no servidor.

Quais versões do React e Next.js estão afetadas?

As vulnerabilidades impactam pacotes React como `react-server-dom-webpack` nas versões 19.0.0 a 19.2.0. Frameworks que utilizam React Server Components, notadamente o Next.js, estão afetados. Os usuários são aconselhados a atualizar para as versões corrigidas mais recentes imediatamente.

Como faço para corrigir essas vulnerabilidades do React?

A solução principal é atualizar suas dependências do React, especificamente os pacotes relacionados aos Componentes de Servidor do React, para as versões mais recentes lançadas em ou após 11 de dezembro de 2025. A Vercel também implementou mitigações para usuários do Next.js em sua plataforma.

Esses novos exploits estão relacionados à vulnerabilidade RCE anterior (React2Shell)?

Sim, eles foram descobertos por pesquisadores de segurança enquanto testavam os patches para a falha original de execução remota de código (CVE-2025-55182). Eles exploram um vetor de ataque semelhante por meio do protocolo 'Flight', mas não reintroduzem o risco de execução remota de código.