Uma investigação da equipa de segurança Octagon Networks (que assina o trabalho no blogue pwn.ai) revelou uma cadeia de falhas no ImageMagick — a biblioteca de processamento de imagem usada por milhões de sites — que permite passar de leitura de ficheiros arbitrários a escrita de ficheiros no servidor, com potencial de execução remota de código. A investigação teve origem num teste de intrusão de rotina e, em cinco dias, um agente autónomo identificou o ImageMagick como superfície de ataque, descobriu uma falha de leitura de ficheiros e escalou até escrita de ficheiros e RCE, contornando todas as mitigações. O ponto mais preocupante: os investigadores notaram que o mecanismo de defesa principal da política “secure” está completamente não funcional em muitos sistemas, e este “magic byte shift” contorna até as políticas mais seguras.
Resposta rápida: Investigadores demonstraram que basta enviar uma imagem aparentemente inofensiva (mesmo um .jpg) a um site que use o ImageMagick para desencadear leitura e escrita de ficheiros no servidor, contornando as políticas de segurança recomendadas por delegação ao GhostScript. Afeta distribuições Linux comuns e instalações WordPress. A mitigação passa por endurecer o policy.xml (bloquear PDF, EPT e todos os módulos que invocam o GhostScript), isolar o processamento e validar o conteúdo real dos ficheiros.
O que é o ImageMagick e porque é uma superfície de ataque tão apetecível
O ImageMagick é uma das bibliotecas de manipulação de imagem mais usadas na web, invocada por plataformas de comércio eletrónico, redes sociais e sistemas de gestão de conteúdos sempre que é preciso redimensionar avatares, gerar miniaturas ou converter formatos. Afeta aplicações web que aceitam imagens carregadas por utilizadores e as processam usando o ImageMagick diretamente ou através de bibliotecas populares como o imagick do PHP, o rmagick e paperclip do Ruby ou o imagemagick do Node.js.
O problema estrutural não é novo. A questão central não é apenas um erro numa versão específica: é um problema de arquitetura na forma como o ImageMagick trata a delegação de formatos por omissão, remetendo por defeito para o GhostScript no caso de conteúdos PostScript, EPS, PDF e XPS. A menos que a política seja explicitamente endurecida, qualquer instalação que processe ficheiros fornecidos por utilizadores fica potencialmente exposta. Esta mesma classe de bugs esteve na origem do célebre ImageTragick, em 2016.
Como funciona o ataque “magic byte shift”
O ImageMagick não determina o tipo de ficheiro apenas pela extensão: lê os chamados “magic bytes” no início do ficheiro. A falha nasce de o ImageMagick não validar corretamente esses códigos internos, permitindo que atacantes disfarcem scripts maliciosos de imagens inofensivas. Ou seja, um ficheiro pode ter extensão .jpg mas conter, no seu cabeçalho, dados que o ImageMagick reconhece como PostScript — e que acabam entregues ao GhostScript.
A investigação técnica detalhada por analistas mostra uma escalada metódica através de cada barreira de segurança. A política “limited”, recomendada para produção, bloqueia o módulo PS mas não o módulo PDF, e ambos invocam o GhostScript através do mesmo delegado, pelo que um payload PostScript com extensão .pdf contorna por completo a política “limited”. Descobriu-se ainda um vetor adicional através de um formato pouco vigiado: o formato EPT (Encapsulated PostScript with TIFF preview) está registado como módulo próprio, está ausente de todas as listas de bloqueio das políticas e é detetado puramente pelos magic bytes, independentemente da extensão — permitindo que um único ficheiro .jpg com os magic bytes certos consiga escrita de ficheiros na política “limited”.
As técnicas de evasão não param aí. Vários coders adjacentes ao PostScript (EPSI, EPI, EPSF) não estavam incluídos na lista de bloqueio apesar de invocarem o mesmo delegado GhostScript, e foi possível outra evasão de deteção acrescentando um único byte de nova linha ao início de um payload PostScript, o que impediu o ImageMagick de o detetar como PostScript, embora o GhostScript o executasse normalmente. Mesmo com o “cofre” do GhostScript ativo, ficaram brechas: sob o modo -dSAFER do GhostScript 9.55.0 (a versão distribuída no Ubuntu 22.04), a execução de shell via %pipe% é bloqueada, mas as operações de escrita de ficheiros PostScript para /tmp/ continuam permitidas, tendo os investigadores demonstrado a escrita de conteúdo controlado pelo atacante nessa diretoria.
Quem é afetado
A descoberta afeta praticamente todas as principais distribuições Linux, incluindo Ubuntu 22.04, Debian e Amazon Linux. O impacto estende-se ao ecossistema WordPress: o mapeamento do “raio de explosão” abrangeu todas as principais distribuições Linux, o WordPress e o Gravity Forms. Uma parte das evasões tem correspondência de versões concreta: este bypass específico afeta versões do ImageMagick até à 6.9.13-33, o que inclui a versão distribuída no Ubuntu 22.04 (6.9.11-60), e foi silenciosamente corrigido na 6.9.13-34 sem CVE.
O aspeto mais delicado para quem gere servidores é que nem todas as brechas foram tapadas. Segundo os investigadores, o bypass do PDF e o bypass do delegado gslib nunca foram corrigidos e afetam todas as versões, incluindo a mais recente. Além disso, até a política “secure” foi contornada em sistemas onde o GhostScript é compilado como biblioteca ligada em vez de binário externo.
Cronologia da investigação
| Fase | Descrição |
|---|---|
| Origem | Teste de intrusão de rotina para cliente da pwn.ai, com identificação do ImageMagick como único motor de processamento |
| Leitura de ficheiros | Conteúdo de ficheiros arbitrários renderizado nas imagens de saída |
| Escalada | Encadeamento de evasão de deteção de formato, lacunas de política e escrita de ficheiros via GhostScript |
| Evasão total | Contorno das políticas “open”, “limited”, da correção do mantenedor e da política “secure” |
| Resposta | Cliente da pwn.ai corrigido em horas; endurecimento do policy.xml e whitelisting ao nível dos coders no WordPress |
Como mitigar
A resposta imediata dada pelos investigadores ao próprio cliente aponta o caminho. A política do ImageMagick foi atualizada para bloquear PDF, EPT e todos os módulos que invocam o GhostScript, e a instalação WordPress foi endurecida com whitelisting ao nível dos coders. A boas práticas gerais recomendadas por especialistas na gestão deste stack incluem:
- Executar o ImageMagick como utilizador de baixo privilégio, limitando o impacto de uma exploração bem-sucedida.
- Executar o ImageMagick num contentor, isolando o processamento em Docker ou ambiente semelhante para restringir o alcance de um atacante mesmo com RCE.
- Sanear nomes de ficheiros e declarar explicitamente o formato de entrada — usando
png:image.pngem vez deimage.png— para evitar que o ImageMagick infira o formato pelo conteúdo e remover um vetor de ataques de confusão de content-type. - Validar o conteúdo do ficheiro no lado do servidor, e não apenas a extensão ou o tipo MIME.
Existe também ferramenta dedicada de verificação: o ImageMagick Security Policy Evaluator da Doyensec permite verificar de forma automática se o policy.xml está endurecido contra vetores de ataque conhecidos, incluindo leitura de ficheiros arbitrários, e deve ser usado em qualquer revisão de implementação que envolva o ImageMagick.
Porque é que isto importa em Portugal
Grande parte das PME portuguesas assenta em sites WordPress e em aplicações que aceitam uploads de imagens — formulários de candidatura, catálogos, marketplaces, submissão de documentos. Como o ImageMagick é frequentemente uma dependência “invisível” nesses ambientes, muitas organizações nem sabem que o executam. Uma falha que transforma um simples upload numa via de escrita de ficheiros e potencial RCE representa um risco direto de comprometimento de servidor, exfiltração de dados e criação de backdoors persistentes.
Do ponto de vista legal, se um incidente destes levar ao acesso ou exfiltração de dados pessoais, aplicam-se as obrigações do RGPD, incluindo a notificação à CNPD no prazo de 72 horas e, quando existir risco elevado, a comunicação aos titulares afetados. Para entidades abrangidas pelo novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, transposição da NIS2), a gestão de vulnerabilidades em componentes de software e o reporte de incidentes ao CNCS/CERT.PT tornam-se obrigações de segurança que reforçam a importância de mapear e endurecer dependências como o ImageMagick e o GhostScript.
Perguntas frequentes
Basta mesmo uma imagem para explorar esta falha?
Sim, no essencial. Os investigadores demonstraram que um ficheiro com aparência de imagem, incluindo um .jpg, pode conter magic bytes que fazem o ImageMagick delegar o processamento ao GhostScript, permitindo leitura e escrita de ficheiros no servidor. O que importa é o conteúdo interno do ficheiro, não a sua extensão.
Atualizar o ImageMagick resolve o problema?
Só parcialmente. Alguns bypasses foram corrigidos em versões recentes, mas os investigadores afirmam que o bypass do PDF e o do delegado gslib não foram corrigidos e afetam todas as versões, incluindo a mais recente. Por isso, atualizar deve ser complementado com o endurecimento do policy.xml e isolamento do processamento.
O meu site WordPress está em risco?
Pode estar, se o servidor usar o ImageMagick para processar imagens e o GhostScript estiver disponível como delegado. A investigação mapeou explicitamente o WordPress e o plugin Gravity Forms como parte do impacto. Recomenda-se verificar a configuração do ImageMagick e restringir os coders que invocam o GhostScript.
Que medida devo tomar primeiro?
Endurecer a política do ImageMagick para bloquear PDF, EPT e todos os módulos que invocam o GhostScript, e validar o conteúdo real dos ficheiros carregados. Em paralelo, executar o processamento com baixo privilégio e em contentor isolado, e usar ferramentas como o Security Policy Evaluator da Doyensec para confirmar que a política está bem configurada.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Octagon Networks/pwn.ai e por análises técnicas de investigadores de segurança.