CVE-2020-5741

Falha de deserialização insegura (CWE-502) no framework de plugins do Plex Media Server para Windows: um arquivo interno chamado 'Dict', usado para persistir configurações do plugin com.plexapp.system, é carregado com pickle.load() sem qualquer validação. Um atacante autenticado com um token de administrador da conta Plex consegue substituir esse arquivo por um pickle malicioso e forçar sua execução, obtendo código Python arbitrário no contexto do usuário do sistema operacional que roda o servidor. O CVSS de 7.2 já reflete a exigência de privilégio alto (PR:H) — não é uma falha exploitável por qualquer usuário anônimo na rede, mas continua séria porque o resultado final é RCE completo com poucos passos automatizáveis.

O código vulnerável está em Framework.bundle, dentro do plugin de sistema com.plexapp.system, especificamente em Dict.py e Data.py. A função __load() em Dict.py verifica se existe um arquivo 'Dict' no caminho de dados do plugin e, se existir, chama Data.__unpickle(path), que por sua vez executa 'obj = pickle.load(f)' diretamente sobre o conteúdo do arquivo. Pickle em Python não é um formato de dados seguro: ele pode instanciar objetos arbitrários e invocar métodos durante a desserialização, incluindo __reduce__, o que permite embutir chamadas de sistema no próprio payload serializado.

O problema de design é duplo: primeiro, o servidor confia que qualquer arquivo chamado 'Dict' encontrado no caminho de dados do plugin foi gerado pelo próprio Plex, sem assinatura ou verificação de integridade; segundo, o caminho onde esse arquivo é procurado (LocalAppDataPath) é configurável via API de preferências, o que dá ao atacante controle sobre onde o servidor vai procurar o Dict malicioso.

O que o atacante controla, na prática, é o conteúdo binário do arquivo Dict (um pickle arbitrário) e a localização em disco onde esse arquivo fica, via duas primitivas legítimas da API do Plex: criação de biblioteca de mídia com localização customizada e upload de metadata para essa biblioteca. Nenhuma das duas exige exploração de memória ou bypass de sandbox — é abuso de funcionalidade normal combinado com falta de validação no parser de dados internos.

A exploração documentada pela Tenable segue um fluxo com passos encadeados via API HTTP do Plex, todos exigindo um token de autenticação com privilégios de administrador da conta: (1) criar uma biblioteca de fotos com uma localização arbitrária no disco (ex.: C:\Users\Public) via POST /library/sections; (2) usar o locationID retornado para fazer upload de um arquivo chamado 'Dict', contendo o pickle malicioso, via POST /library/metadata, o que faz o Plex criar a estrutura de diretórios e gravar o arquivo; (3) alterar a preferência LocalAppDataPath via PUT /:/prefs para apontar para o diretório onde o Dict malicioso foi gravado; (4) forçar o plugin com.plexapp.system a reiniciar via GET /:/plugins/com.plexapp.system/restart, o que dispara o carregamento e a desserialização do arquivo forjado, executando o payload.

O pré-requisito crítico — e é a informação que a manchete 'RCE' esconde — é posse de um token de administrador válido da conta Plex associada ao servidor, não apenas acesso de rede. Isso normalmente implica comprometimento prévio de credenciais, sessão roubada, ou um ataque combinado (phishing, reuso de senha, token exposto) que dê esse nível de acesso. Não é uma falha explorável por um atacante anônimo direto na porta do serviço.

A CISA incluiu a CVE no catálogo KEV confirmando exploração ativa em campo, e existe módulo Metasploit e PoC pública (incluindo a da Tenable, referenciada como auth_dict_unpickle_rce_exploit), o que reduz a complexidade prática para quem já tem o token — o ataque é totalmente automatizável a partir daí. Não há indicação nas fontes de exploração em massa ou associação com campanhas de ransomware conhecidas; o campo correspondente no KEV está marcado como 'Unknown'.

A correção do fornecedor é a atualização para Plex Media Server 1.19.3 ou superior — a Tenable confirmou que uma versão beta anterior não corrigia a falha e que apenas o build final 1.19.3 mitigou efetivamente a execução remota de código durante os testes de validação. Não há informação nas fontes sobre uma versão mínima exata anterior a partir da qual a falha existe; o que se sabe é 'antes de 1.19.3'.

Como controle compensatório, caso a atualização não seja imediata: restringir e monitorar rigorosamente quem possui token de administrador da conta Plex associada ao servidor, já que esse é o pré-requisito de exploração — rotação de credenciais, MFA na conta Plex e revogação de tokens não utilizados reduzem a superfície, mas não eliminam a falha em si, apenas dificultam a obtenção do pré-requisito. Restringir acesso de rede à interface administrativa do Plex (não expor a porta de gerenciamento diretamente à internet) também limita o vetor, mas de novo é controle de acesso, não correção da desserialização insegura.

O que não funciona como mitigação: desabilitar a feature de Camera Upload isoladamente não foi validado nas fontes como suficiente, já que o vetor documentado usa a API de bibliotecas de mídia de forma mais ampla (criação de biblioteca de fotos e upload de metadata), não exclusivamente o fluxo de câmera. Confiar apenas em firewall de perímetro sem also revisar quem tem token de admin deixa o vetor de exploração intacto para qualquer conta já comprometida.

Nos logs de acesso da API do Plex, procurar pela sequência característica: POST /library/sections com type=photo e scanner=Plex%20Photo%20Scanner apontando para localizações de disco fora do padrão; POST /library/metadata com filename contendo 'Dict' e overwrite=true; PUT /:/prefs?LocalAppDataPath= alterando o caminho de dados local para um diretório não usual; e GET /:/plugins/com.plexapp.system/restart imediatamente após essas chamadas. Essa combinação, fora de uma janela de manutenção legítima, é forte indício de tentativa de exploração.

No sistema de arquivos, a presença de um arquivo chamado 'Dict' em um diretório de biblioteca de fotos criado recentemente (ex.: sob C:\Users\Public ou caminho similar) que não corresponde a um arquivo de dados de plugin legítimo é um artefato pós-exploração a se buscar em resposta a incidente. Não há assinatura de rede ou payload fixo documentado nas fontes — a exploração usa chamadas de API HTTP legítimas do próprio produto, então a detecção depende de contexto comportamental (sequência de chamadas administrativas anômalas) e não de um IOC único e confiável.