A cadeia de vulnerabilidades apelidada de Plex2Shell — composta por quatro falhas distintas no Plex Media Server — está sendo explorada ativamente desde 17 de outubro de 2026, menos de 24 horas após a publicação de um código de prova de conceito (PoC) pela segurança. O ataque não exige credenciais, login ou interação do usuário: qualquer servidor exposto à internet com versão inferior a 1.43.3.10861 está sob ataque. Dentro de horas, pesquisadores já confirmavam a instalação de mineradores de criptomoedas e um backdoor de proxy residencial em servidores honeypot.
O que torna o Plex2Shell particularmente perigoso não é a gravidade isolada de cada CVE — o mais alto tem pontuação CVSS 8,6 —, mas a elegância da cadeia: quatro vulnerabilidades aparentemente menores se encadeiam para permitir execução arbitrária de código no contexto do serviço Plex, sem qualquer autenticação prévia. A primeira falha, CVE-2026-96652 (CVSS 5,3), é um SSRF não autenticado no endpoint `/player/timeline`, onde o parâmetro `protocol` não é validado e força o servidor a enviar requisições POST a qualquer destino controlado pelo atacante. Em seguida, o CVE-2026-96654 (CVSS 6,9) explora uma falha de neutralização de URL no endpoint `searchOne`, permitindo extrair o token de administrador do proprietário sem senhas.
Com o token em mãos, o atacante usa o CVE-2026-96655 (CVSS 5,3) para realizar SSRF autenticado através do caminho `/video/:/transcode/universal`, acessando recursos internos ou externos. O golpe final — e o mais perigoso — é o CVE-2026-96656 (CVSS 8,6): uma falha de controle externo de nome de arquivo que permite escrever um objeto compartilhado ELF em qualquer caminho do diretório `Codecs` do Plex. A arquitetura de carregamento de bibliotecas do Plex é o ponto crucial: quando o serviço precisa transcoder um vídeo, ele enumera automaticamente todos os arquivos `.so` no diretório Codecs e os carrega via `dlopen`. O carregador não verifica prefixo `lib`, permissão de execução, assinatura digital nem símbolos exportados. Uma biblioteca `.so` com apenas uma função construtora (DT_INIT_ARRAY) executa seu código assim que carregada — e roda com a mesma identidade do serviço Plex (uid 1000). Isso significa que a cadeia inteira, do SSRF inicial até a execução arbitrária, opera sem credenciais.
Zach Main, o pesquisador que descobriu as falhas e publica em zmain.info sob o pseudônimo "ZM", relatou a vulnerabilidades ao Plex em 27 de julho de 2026. A empresa concedeu um bug bounty de US$ 500 em 4 de agosto e liberou o patch em 3 de agosto (versão 1.43.3.10861). Um aviso público foi emitido em 1 de setembro. No entanto, o estudo da Shadowserver Foundation feito em 9 de setembro — seis semanas após o patch — encontrou mais de 36.000 instâncias ainda vulneráveis, de aproximadamente 300.000 servidores Plex expostos na internet. Quando o PoC completo saiu em 16 de outubro, muitos daqueles servidores permaneciam desatualizados. A exploração começou no dia seguinte.
O primeiro payload observado foi um minerador de criptomoedas baseado em XMRig, batizado `mylovelyminer`, conectado ao servidor `ota.proxystream.st`. Dias depois, o mesmo pesquisador que operava o honeypot identificou um segundo programa chamado `myawesomeproxy`, um backdoor de proxy residencial Linux que converte o servidor comprometido em um nó de tráfego. O binário conecta-se a `global.relay.proxystream.st` — um subdomain vinculado pela Bitsight em agosto de 2026 à botnet AISURU de DDoS e proxyware. A conexão com a AISURU é significativa: a mesma infraestrutura que operava ataques de negação de serviço e revenda de largura de banda está sendo usada para hospedar os servidores de mineração e roteamento do Plex2Shell. Isso sugere reutilização de infraestrutura entre campanhas, possivelmente pelos mesmos operadores.
O que diferencia esta campanha de explorações típicas de vulnerabilidades em serviços domésticos é a sofisticação dos payloads. Mineradores sozinhos seriam um ganho limitado — o Monero (XMR) caiu em valor e a mineração em CPUs domésticas raramente compensa o custo de eletricidade. O proxy residencial, contudo, tem valor real: cada nó comprometido se torna um IP residencial que pode contornar bloqueios de IP corporativo, acessar VPNs e sistemas de e-mail internos, e servir como ponte para ataques a redes corporativas. A reputação de IP residencial, muitas vezes usada para burlar sistemas anti-bot, transforma um servidor Plex doméstico em infraestrutura de ataque de alto valor.
A persistência é outro aspecto crítico. Os payloads não desaparecem com a reinicialização do serviço: o arquivo `.so` permanece no diretório Codecs e é recarregado sempre que o Plex precisa transcoder. Parar e reiniciar o serviço Plex não remove a infecção. O patch resolve o problema na raiz, mas servidores já comprometidos precisam de limpeza manual — inspeção do diretório Codecs, remoção de arquivos não autorizados, verificação de processos filhos suspeitos e, idealmente, reinstalação completa a partir de uma imagem limpa.
A lição do Plex2Shell não é nova para administradores de infraestrutura self-hosted, mas ganha urgência com a escala: 36.000 servidores desatualizados, 300.000 expostos, e uma cadeia de exploits que opera em menos de 24 horas. O patch estava disponível por 75 dias antes da exploração pública, e ainda assim a maioria dos servidores permaneceu vulnerável. Quando a porta se abriu, a exploração foi quase imediata — e os payloads visam muito além da simples mineração de criptomoedas.
Fontes: The Hacker News, SecurityWeek, Security Affairs
✓ Fontes independentes cruzadas e verificadas antes da publicação
