CVEs da semana: por que sistemas legados viram porta de entrada

Toda semana, fabricantes e pesquisadores divulgam novas falhas de segurança. Para a maioria das empresas, a resposta parece simples: aplicar a atualização. O problema é que nem todo sistema consegue ser atualizado no mesmo ritmo em que as falhas aparecem.

A semana de 19 a 23 de outubro de 2026 mostrou bem esse descompasso. E ajuda a explicar por que sistemas legados costumam ser o ponto por onde o ataque entra.

O que é um CVE e por que ele importa para o negócio?

CVE é o identificador público dado a uma vulnerabilidade conhecida, para que fabricantes, equipes de TI e ferramentas de segurança falem da mesma falha com o mesmo nome.

Para o gestor, o identificador em si importa pouco. O que importa é a pergunta que vem depois: essa falha existe em algum sistema nosso, ele está exposto e alguém já está explorando? Quando a resposta é sim, o risco deixa de ser técnico e passa a ser de operação, de dados e de reputação.

Um bom termômetro é o catálogo KEV da CISA, a agência de cibersegurança dos Estados Unidos, que lista apenas falhas com evidência de exploração real.

O que aconteceu nesta semana?

O caso de maior alcance foi a php2shell (CVE-2026-109618 e CVE-2026-109619), duas falhas críticas no PHP, linguagem presente em uma enorme quantidade de sites, portais e sistemas web corporativos. Elas permitem executar código no servidor sem autenticação. As correções saíram em 21 de outubro, mas a Amazon registrou tentativas de exploração quatro dias antes da divulgação, e várias empresas de segurança viram ataques logo depois.

O detalhe mais relevante para quem tem legado: as versões do PHP fora de suporte não recebem atualização oficial. A CISA recomendou que sistemas que não puderem ser atualizados, ou que ainda rodem versões antigas sem suporte, sejam retirados do ar até a correção.

Também entraram no catálogo KEV, em 23 de outubro, uma falha de injeção de SQL no Arista VeloCloud Orchestrator instalado no próprio ambiente da empresa (CVE-2026-114625), ferramenta usada para gerenciar redes corporativas, e uma falha no servidor do Collabora Online embutido no Nextcloud (CVE-2026-110447), explorada desde setembro, segundo o registro oficial.

Por fim, a CISA incluiu no catálogo, em 20 de outubro, quatro falhas do Plex Media Server, conhecidas como Plex2Shell. A correção existia desde agosto. Mesmo assim, servidores sem atualização foram usados para instalar mineradores de criptomoeda.

Por que o legado vira a porta de entrada?

O caso do Plex resume o padrão: a correção já existia havia meses, e o ataque aconteceu onde ela não foi aplicada. Em sistemas legados, esse atraso costuma ter motivos concretos.

A versão da linguagem ou do framework está fora de suporte, então o fabricante não publica mais correções. As dependências foram congeladas porque qualquer atualização quebra alguma parte do sistema. Não há testes automatizados para confirmar que tudo continua funcionando depois da mudança.

Somam-se a isso a falta de documentação e a saída de quem conhecia o sistema. O resultado é o servidor que ninguém quer mexer. Ele continua rodando, muitas vezes exposto na internet, e cada nova falha publicada aumenta a distância entre o que ele tem e o que deveria ter.

Esse é o custo que aparece na conta da dívida técnica: o sistema funciona, mas a empresa perde a capacidade de reagir rápido quando surge um risco.

O que o gestor de TI pode fazer na prática?

Inventário. Não dá para corrigir o que não se conhece. É preciso saber quais sistemas existem, em que linguagem e versão rodam, quais componentes usam e quem é responsável por cada um. A própria CISA lembra que o PHP muitas vezes está embutido em outros produtos, sem aparecer à primeira vista.

Priorização pelo risco real. Nem toda falha tem a mesma urgência. Primeiro vêm os sistemas expostos na internet com falhas que já estão sendo exploradas, como as listadas no catálogo KEV. Depois, o restante.

Isolamento e medidas compensatórias. Quando o patch não pode ser aplicado de imediato, é possível reduzir a exposição: tirar o sistema da internet, restringir o acesso por VPN, aplicar regras em firewall de aplicação, desativar recursos vulneráveis e reforçar o monitoramento. Essas medidas ganham tempo, mas não substituem a correção.

Verificar se houve invasão. Em falhas exploradas antes da correção, aplicar o patch não basta. Vale revisar logs e processos dos servidores a partir da data das primeiras tentativas, não apenas da data da divulgação.

Testes e modernização gradual. A solução de fundo é tornar o sistema atualizável. Isso passa por criar testes que deem segurança para mudar, atualizar dependências aos poucos e substituir partes críticas por etapas, sem parar a operação. É o caminho descrito em modernização de sistemas legados sem risco.

Segurança também é decisão de gestão

Manter um sistema antigo pode ser uma escolha razoável. O que gera risco é mantê-lo sem inventário, sem testes e sem plano de evolução. Como discutimos em segurança da informação como tema de negócio, a pergunta não é se novas falhas vão aparecer, mas quanto tempo a empresa leva para responder a elas.

Como a RETTA pode ajudar?

A RETTA atua na manutenção e modernização de sistemas legados: mapeamento do ambiente, atualização de dependências, criação de testes e evolução gradual de sistemas críticos, para que aplicar uma correção volte a ser rotina, e não um projeto de risco.

Se a sua empresa tem sistemas que ninguém quer mexer, fale com a nossa equipe e avalie por onde começar.