A atualização de manutenção 7.0.4 do WordPress trouxe uma correção de segurança que passou despercebida por muitos administradores, mas que merece atenção antes de simplesmente aplicar o update. A mudança altera a forma como o WordPress repassa arquivos de mídia enviados ao ImageMagick, fechando uma brecha que permitia que um usuário autenticado com nível de Autor transformasse um upload aparentemente inofensivo em execução de código no servidor.
O problema afeta todas as versões do núcleo do WordPress desde a 4.7 até a 7.0, um período extenso que expõe um grande número de instalações. O anúncio oficial foi publicado no site do projeto, e uma regra de mitigação já foi aplicada automaticamente aos sites conectados à Patchstack.
A origem do problema
O WordPress utiliza o ImageMagick, por meio da extensão Imagick, para redimensionar e processar imagens enviadas à Biblioteca de Mídia. Ocorre que o ImageMagick é capaz de interpretar muito mais do que arquivos JPEG e PNG: ele também abre arquivos PostScript, EPS e PDF, e para renderizar esses formatos recorre ao Ghostscript, componente historicamente vulnerável a manipulações que o levam a executar comandos indevidos. Trata-se da mesma categoria de falhas que ficou conhecida como “ImageTragick”.
O ponto central da vulnerabilidade está na forma como cada sistema identifica um arquivo. O ImageMagick determina o tipo de arquivo com base em seu conteúdo real, e não em sua extensão — mas o WordPress, na prática, confiava majoritariamente na extensão informada. Assim, um arquivo chamado “ferias.png”, mas que na verdade continha código PostScript, conseguia passar pelas verificações de upload, era entregue ao Imagick, que reconhecia o conteúdo PostScript e acionava o Ghostscript. Essa incompatibilidade entre extensão e conteúdo real era exatamente onde residia o risco.
Como a falha podia ser explorada
O método WP_Image_Editor_Imagick::load(), presente no núcleo do sistema, decidia como entregar um arquivo enviado ao ImageMagick observando apenas a extensão, sem jamais inspecionar seu conteúdo. As funções readImage() e readImageBlob() analisam os chamados “magic bytes” do arquivo — sua assinatura binária — e ignoram o nome atribuído a ele. Dessa forma, um conteúdo iniciado com sequências como %!, x04%!, xC5xD0xD3xC6 ou xFFWPC acionava o decodificador de PS/EPS/WPG do ImageMagick, que por sua vez chamava o Ghostscript, executando o arquivo como um programa PostScript.
Em um fluxo normal de upload, a função wp_check_filetype_and_ext() identifica essa inconsistência e bloqueia o ataque. O problema é que nem todos os caminhos de envio de arquivo passam por essa verificação. A função wp.uploadFile do XML-RPC e a rotina de extração de capa de arquivos MP3 gravam os bytes recebidos por meio de wp_upload_bits(), que não faz qualquer inspeção de conteúdo — permitindo que o arquivo malicioso chegasse ao disco e alcançasse o código vulnerável.
A correção aplicada
A falha foi corrigida por um commit que atualiza a função load(), agora responsável por verificar o conteúdo real do arquivo antes de instanciar o objeto Imagick, impedindo que qualquer dado seja repassado a um decodificador da família PostScript. De forma concreta, a nova verificação passou a rejeitar:
- Arquivos PostScript e EPS, identificados por suas assinaturas características (%!, cabeçalhos binários EPS, gráficos WordPerfect), pela extensão ou por prefixos de “especificador de formato” usados pelo ImageMagick;
- PDFs falsos, ou seja, arquivos com extensão PDF que não começam com o marcador real %PDF-;
- Arquivos compactados que o ImageMagick descompactaria automaticamente (como gzip e bzip2), outra via usada para contrabandear conteúdo malicioso pelas verificações.
Há ainda um detalhe mais sutil: o ImageMagick permite forçar um determinado manipulador de arquivo por meio de um prefixo no nome, como em “EPS:inocente.png”. A correção passou a identificar e neutralizar esses prefixos, tomando o cuidado de não confundi-los com letras de unidade do Windows, como “C:”. Como o mesmo artifício pode chegar por uma URL remota ou por um stream, a correção também passou a analisar nomes de arquivo vindos dessas origens antes de validá-los.
Quem está mais exposto
Para explorar essa vulnerabilidade, é necessário ter permissão para enviar arquivos de mídia — o que exige, no mínimo, uma conta com nível de Autor. Não se trata, portanto, de um ataque anônimo e aleatório. Ainda assim, vale refletir sobre quem tem acesso a esse tipo de conta no seu site.
Sites com múltiplos autores, plataformas de assinatura, sites com colaboradores externos ou com cadastro aberto e pouco controlado apresentam um risco muito mais concreto do que parece à primeira vista.
Nesses casos, um Autor enviando uma “imagem” armadilhada representa uma ameaça real, não apenas teórica. Já em sites administrados apenas pelo proprietário e por um grupo restrito de editores de confiança, a exposição tende a ser bem menor.
O que fazer agora
A recomendação é atualizar o WordPress imediatamente. Sites com atualizações automáticas em segundo plano habilitadas podem já estar protegidos, mas vale conferir a versão instalada. Para quem realiza atualizações manuais, essa correção deve ser tratada como prioridade, especialmente em sites que concedem contas a usuários além da equipe principal.
O episódio serve também como lembrete sobre como pensar a segurança no tratamento de mídia: o risco raramente está na imagem em si, e sim em tudo o que a biblioteca de processamento de imagens está disposta a abrir sem que o administrador perceba.
