Quatro CVE de Plex2Shell permitem execução remota e implantação de mineiro e proxy backdoor

Nos últimos dias, foi confirmado um aumento de ataques que aproveitam uma cadeia de falhas em Plex Media Server, apoiada por pesquisadores, para executar código de forma remota e implantar tanto criptomineros como um proxy/reverso com funcionalidade de porta traseira. Os erros, relatados originalmente a Plex em 27 de julho de 2026 e corrigidos na versão 1.43.3.10861 publicada em 3 de agosto de 2026, foram combinados por atacantes após a publicação pública de um proof‐of‐concept (PoC) em 16 de outubro de 2026, e foram registrados tentativas de exploração na natureza no dia seguinte.

O que aconteceu (fatos confirmados): um pesquisador que opera sob o pseudônimo boredhackerblog descreveu uma cadeia de quatro vulnerabilidades (CVE‐2026‐96652, CVE‐2026‐96654, CVE‐2026‐96655 e CVE‐2026‐96656) que, encadeadas numa ordem específica, permitem passar de uma petição web não validada a uma execução remota de código sem autenticação em instâncias vulneráveis de Plex. O Plex lançou um adesivo na versão 1.43.3.10861 para corrigir estas falhas. Posteriormente, foram observadas tentativas de exploração que resultaram na descarga e execução de dois artefatos: um binário denominado "myawesomeproxy" — identificado por análise pública como um backdoor/reverse‐proxy para Linux — e um processo de mineração XMRig sob o nome "mylovelyminer" que contava com o domínio ota.proxystream[.]st. Analistas também correlacionaram atividade de rede com endereços IP públicos usados pelos atacantes (por exemplo, 217.60.194.116 e IPs 91.92.40.202, 176.65.139.228, 45.194.92.222).

Como funciona tecnicamente a cadeia: cada CVE satélite traz um elo para escalar desde um pedido inicial até a execução de um ELF controlado pelo atacante. Resumindo seu papel, sem reproduzir o exploit passo a passo: um dos erros permite que parâmetros controlados pelo atacante sejam inseridos em um URL usado pelo leitor de Plex (SSRF em /player/timeline), outro permite invocar funções de plugins e obter o token do proprietário (fuga de token via /searchOne), um terceiro habilita que um token válido solicite recursos arbitrários (SSRF na rota de transcodificação), e o último permite escrever um objeto compartilhado ELF na pasta de Codecs e forçar sua carga e execução. Encadeados, esses vetores convertem um pedido web maliciosa em execução remota sem necessidade de credenciais.

Quem afecta: instâncias do Plex Media Server que não foram atualizadas e acessíveis a partir da rede (Internet ou rede interna sem segmentar). O risco é maior em servidores com portos expostos, em instalações que permitem instalação automática de codecs ou plugins, ou em ambientes onde o processo de Plex corre com privilégios elevados ou com capacidade para escrever na sua própria árvore de arquivos.

Impacto observado: implantação de um criptominero XMRig e de um proxy com funcionalidade de porta traseira. O proxy ("myawesomeproxy") informa ao iniciar-se com uma mensagem que, segundo o pesquisador, adverte que o software pode usar o tráfego da rede do anfitrião; é uma confirmação operacional de que a máquina comprometida pode ser reutilizada como salto de saída/relay para tráfego alheio. Além disso, ligações entre subdomínios de proxystream[.]st e atividades prévias de botnets/proxyware foram documentadas por terceiros (por exemplo, relatórios de segurança que relacionam global.relay.proxystream[.]st com campanhas de AISURU em agosto de 2026).

O que está confirmado e o que não: é confirmado que existem os CVE e o adesivo público, que se observou atividade na rede após a publicação do PoC e que foram descarregados/executados os artefatos antes citados desde endereços e domínios indicados. Não está confirmado, por agora, que todas as instâncias relatadas por usuários em fóruns — como vários fios no Reddit que mencionam "mylovelyminer" — provem especificamente da cadeia Plex2Shell; há casos em que campanhas de cryptomining reutilizam múltiplos vetores. Também não há atribuição pública e verificada do ator responsável nem certeza absoluta sobre a escala completa das infecções além dos indicadores observados publicamente.

Para quem prefere referências técnicas oficiais, os registros CVE associados já estão publicados em bases públicas como MITRE ( CVE-2026-96652, CVE-2026-96656) e Plex mantém sua página de downloads e atualizações em https://www.plex.tv/media-server-downloads/. Para entender a peça de mineração técnica, XMRig (o software de mineração geralmente detectado nessas campanhas) documenta seu protocolo de conexão em https://xmrig.com.

O que deve fazer o administrador ou utilizador do Plex: primeiro e de forma urgente, verifique a versão do Plex Media Server; se for anterior a 1.43.3.10861, atualize imediatamente a versão alterada ou posterior. Se a instância estiver exposta à Internet, aisle o serviço até ter atualizado. Se suspeitar de compromisso, proceda com estas ações concretas: 1) desligar a máquina da rede externa; 2) realizar um volcado forense de memória e uma imagem do disco se tiver capacidades de análise; 3) procurar processos com nomes invulgares (por exemplo, "mylovelyminer", "myawesomeproxy") e ligações salientes para os domínios/IPs indicados; 4) inspeccionar pastas de Plex para arquivos ELF não autorizados dentro das pastas Codecs (ver a localização típica na sua distribuição; p. ex., no Linux, está normalmente sob a árvore de dados de Plex Media Server) e remover binários não reconhecidos; 5) rever unidades systemd/crontab e scripts de arranque para persistência; 6) rotar credenciais administrativas e tokens expostos, e 7) reinstalar o sistema se houver indícios de intrusão profunda ou persistente.

Em paralelo, aplique controles de prevenção: restringe o acesso ao servidor Plex através de firewall (permitir apenas redes de confiança), deshabilite UPnP/auto-port-forwarding em roteadors, coloque Plex atrás de um VPN ou proxy inverso que faça autenticação prévia e limite os privilégios do usuário que executa Plex para evitar escrita em suas próprias pastas críticas. Registre e monitorize conexões salientes frequentes para os IOC conhecidos (IPs e domínios citados acima) e bloquêe-os em perímetro.

Finalmente, documente e informe qualquer achado: se detectar provas de compromisso, capture logs, notifique seu provedor de hospedagem se aplica e compare indicadores com fontes de inteligência pública antes de tentar uma remediação local. A rapidez para aplicar adesivos e a segmentação de redes continuam a ser as barreiras mais eficazes contra este tipo de cadeias que transformam falhas de validação em execução remota e uso ilícito de recursos.