"Um RCE com CVSS 10.0" é uma das frases mais graves nas notícias sobre vulnerabilidades. Veja por que o RCE é a "pior classe" e como difere de outras falhas, do zero.
Como difere de outras falhas
A maioria das vulnerabilidades tem impacto limitado. O RCE roda comandos no próprio servidor, então é uma ordem de magnitude pior.
| Vulnerabilidade | Onde o código roda | Dano principal | Severidade típica |
|---|---|---|---|
| XSS | o navegador | roubo de sessão, desfiguração | média–alta |
| SQLi | o banco de dados | ler/alterar dados | alta |
| RCE | o próprio servidor | tomada de controle, propagação a outros sistemas, tudo o que o processo puder fazer | pior (classe 10.0) |
Por que é a pior classe
Um invasor rodando comandos no seu servidor significa que qualquer coisa que aquele processo possa fazer, ele pode fazer.
RCE alcançado (execução de código arbitrário)
.env e roubar segredosAté onde o dano se espalha é definido pelos "privilégios daquele processo". É exatamente por isso que conteinerização, privilégio mínimo e isolamento (limitar até onde o dano se espalha) funcionam. Rode como root e o invasor pode controlar o servidor inteiro; rode sem privilégios e isolado e você o contém.
A maioria dos RCEs vem de vulnerabilidades publicadas, não das suas próprias falhas
O RCE muitas vezes vem não de uma falha que você escreveu, mas de uma vulnerabilidade conhecida em um framework ou biblioteca que você usa. Muitos incidentes marcantes foram RCEs.
- Log4Shell (CVE-2021-44228): RCE via um componente de logging; organizações do mundo todo correram para responder.
- Equifax (CVE-2017-5638): um RCE do Struts sem patch levou ao vazamento de dados de cerca de 147 milhões de pessoas.
- O CVSS 10.0 negligenciado: um RCE publicado deixado sem patch por meses.
O que você pode fazer para se defender
Não negligencie CVEs publicados (a maior defesa)
Monitore CVEs com máquinas (Dependabot / osv-scanner) e atualize para as versões corrigidas rapidamente. A maioria dos RCEs vem de deixar vulnerabilidades conhecidas sem patch.
Julgue pela versão em execução
Meça o risco pela versão realmente em execução, não pelo piso do manifesto. Confiar no texto avalia mal o perigo.
Limite o dano
Rode como um usuário sem privilégios; isole contêineres e redes. Contenha o dano se você for atingido.
Não passe entrada direto para a execução
Nunca alimente entrada externa diretamente em comandos de shell, desserialização ou avaliação de templates. O básico de não criar um RCE você mesmo.
As principais causas que levam a um RCE
RCE é o nome do resultado; as causas se dividem em vários tipos. O "CWE Top 25" da MITRE (as 25 fraquezas de software mais perigosas), publicado em dezembro de 2025, inclui muitas fraquezas que levam a RCE.
| Causa (CWE) | O que é | CWE Top 25 (2025) |
|---|---|---|
| Injeção de comandos do SO (CWE-78) | Entrada externa é misturada a um comando de shell e roda como comando | 9º |
| Injeção de código (CWE-94) | Entrada externa é avaliada e executada como código do programa | 10º |
| Upload de arquivo perigoso (CWE-434) | Um arquivo executável é colocado no servidor e executado lá (→ vulnerabilidades de upload de arquivos, em inglês) | 12º |
| Desserialização insegura (CWE-502) | Código roda ao restaurar dados recebidos de fora (→ desserialização insegura, em inglês) | 15º |
| Corrupção de memória (CWE-787 e outras) | Software escrito em C/C++ escreve fora dos limites da memória e tem sua execução sequestrada | 5º (escrita fora dos limites) |
As quatro primeiras são as que você tem mais chance de criar no seu próprio app. A corrupção de memória aparece sobretudo em sistemas operacionais, dispositivos de rede e bibliotecas, onde a defesa do usuário é atualizar.
Exemplos reais: produtos alcançáveis de fora são o alvo
- Dispositivos de rede: em julho de 2024, as agências americanas CISA e FBI publicaram um alerta pedindo aos fabricantes que eliminem a injeção de comandos do SO, depois que falhas desse tipo em dispositivos de borda de rede foram exploradas como RCE sem autenticação (→ defesa de dispositivos VPN, em inglês).
- Ferramentas de IA: o Langflow, uma ferramenta para criar agentes de IA, tinha um RCE sem autenticação no recurso de validação de código (CVE-2026-0770), que foi incluído no KEV (→ CVE-2026-0770 explicado, em inglês).
- CMS: uma falha de inclusão de arquivos no núcleo do WordPress (CVE-2026-87902) leva a RCE quando certas condições do servidor são atendidas (→ CVE-2026-87902 explicado, em inglês).
O que eles têm em comum é que os produtos ficam onde podem ser alcançados pela internet sem autenticação. O perigo de um RCE depende não só da falha em si, mas muito de ela ser alcançável de fora.
O que verificar quando você ouve "RCE com CVSS 10.0"
Você usa o produto?
Use a consulta de CVE / KEV para ver o produto e as versões afetados a partir do número do CVE, e compare com as versões realmente em execução no seu ambiente. Para dependências, o osv-scanner verifica tudo de uma vez.
Ele é alcançável de fora?
Verifique se o recurso afetado ou a tela de administração pode ser alcançado pela internet sem autenticação. Se puder, considere tirá-lo do ar até atualizar.
Está sendo explorado?
Se estiver no KEV da CISA, está sendo explorado na prática. Para ler as notas, veja priorizar com CVSS, EPSS e KEV.
Depois de atualizar, procure sinais de invasão
Se alguém entrou antes da atualização, continua lá depois dela. Procure arquivos desconhecidos, contas novas e tráfego de saída suspeito (C2).
Fontes (primárias)
- MITRE, "2025 CWE Top 25 Most Dangerous Software Weaknesses" (dezembro de 2025) — cwe.mitre.org (em inglês; posições de CWE-78, 94, 434, 502 e 787)
- CISA e FBI, "Secure by Design Alert: Eliminating OS Command Injection Vulnerabilities" (10 de julho de 2024) — cisa.gov (em inglês)
- FIRST, "CVSS v3.1 Specification Document" — first.org (em inglês; como a gravidade é pontuada)
- CISA, "Known Exploited Vulnerabilities Catalog" — cisa.gov (em inglês)
Leia a seguir
- Glossário: O que é um CVE · O que é CVSS
- História: Log4Shell — RCE através de uma dependência
- Defesa: Rodando o Next.js com segurança (higiene de CVE)