Glossário
O que é RCE (execução remota de código) — por que é a pior classe de falha
RCE (execução remota de código) permite que um invasor rode código no seu servidor pela rede — direto para a tomada de controle, a pior classe. Como difere de XSS e SQLi, o que define o raio de impacto e como se defender: patches rápidos, monitoramento de CVE, privilégio mínimo.
"Um RCE com CVSS 10.0" — a frase que mais deixa o pessoal de segurança tenso. 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 raio de 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, movimento lateral, tudo | 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 segredosO raio de impacto é definido pelos "privilégios daquele processo". É exatamente por isso que conteinerização, privilégio mínimo e isolamento (minimizar o raio de impacto) funcionam. Rode como root e está tudo perdido; rode sem privilégios e isolado e você o contém.
A maioria dos RCEs vem de "buracos conhecidos", não das suas próprias falhas
O RCE muitas vezes vem não de uma falha que você escreveu, mas de um buraco conhecido em um framework ou biblioteca que você usa. Muitos incidentes marcantes foram RCEs.
- Log4Shell (CVE-2021-44228): RCE via um componente de logging; o mundo entrou em pânico.
- 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 negligenciar buracos conhecidos.
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.
Minimize o raio de impacto
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.
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)
FAQ
QComo o RCE difere de falhas comuns como XSS?
XSS e parecidos em geral se comportam mal dentro do navegador do usuário; o RCE roda programas arbitrários no próprio servidor. Como ele pode alcançar os privilégios, os dados e outros serviços do servidor, costuma ser a classe mais severa.
QAté onde o dano do RCE se espalha?
Tão longe quanto os privilégios do processo que estava em execução quando foi atacado. Rode como root ou com amplos direitos e o dano é enorme; rode como um usuário sem privilégios com isolamento por contêiner e você consegue contê-lo. Por isso o privilégio mínimo e o isolamento importam.
QComo eu (um desenvolvedor) me defendo contra RCE?
Além de não escrever falhas de RCE você mesmo (não passe entrada direto para a execução), a maior defesa é não negligenciar RCEs publicados nos frameworks/bibliotecas que você usa. Monitoramento de CVE e atualizações rápidas são o cerne.