Mirasvit Cache Warmer for Magento < 1.11.12 PHP Object Injection

Falha de deserialização insegura (PHP Object Injection) na extensão Mirasvit Full Page Cache Warmer para Magento 2, usada para pré-aquecer o cache de página completa em lojas Magento e Adobe Commerce. Qualquer requisição de storefront com um cookie CacheWarmer malicioso atinge unserialize() nativo do PHP sem autenticação, sessão de admin ou configuração especial — e, combinada a gadget chains já presentes no Magento e suas dependências, escala para execução remota de código. Está no catálogo KEV da CISA com exploração ativa confirmada, o que torna a atualização urgente independente do tamanho da loja.

A extensão empacota o estado de sessão de um visitante-alvo (moeda, grupo de cliente etc.) dentro de um cookie chamado CacheWarmer para que o crawler de aquecimento renderize cada variação de página corretamente. No servidor, um plugin lê esse cookie e ajusta moeda e sessão de cliente antes de renderizar a página — e esse plugin roda em toda requisição de storefront, não só no tráfego do próprio warmer.

O problema é que o valor do cookie é parcialmente desserializado com unserialize() nativo do PHP, sem qualquer whitelist de classes permitidas (sem uso de allowed_classes). Como o valor vem direto do cliente, o atacante controla exatamente quais objetos PHP são reconstruídos na memória do processo. Isso é PHP Object Injection, CWE-502.

Objeto injection por si só não executa código — mas o Magento e suas dependências carregam classes com métodos mágicos (__wakeup, __destruct, __toString etc.) que podem ser encadeadas em gadget chains para produzir efeitos colaterais perigosos. A Imperva observou payloads reais usando classes do Monolog (SyslogUdpHandler, BufferHandler, FingersCrossedHandler, GroupHandler) para acionar chamadas a system() e current(), transformando a injeção de objeto em execução arbitrária de comando no sistema operacional do servidor.

O vetor é trivial de acionar: basta enviar uma requisição HTTP comum a qualquer página de storefront com um cookie CacheWarmer contendo um objeto PHP serializado codificado em base64. Não há necessidade de autenticação, sessão administrativa ativa ou toggle de configuração — o plugin vulnerável processa o cookie em qualquer requisição normal, o que elimina praticamente toda pré-condição que normalmente reduziria o risco de uma CVE 'crítica'.

A Imperva confirmou exploração ativa desde a divulgação, com payloads visando classes do Monolog para invocar system() e current(). Parte dos ataques observados usa comandos de teste (echo PWNED_CVE2026_$(date +%s), sleep 5) típicos de reconhecimento inicial — o atacante primeiro valida se a execução de código funciona antes de instalar webshells, backdoors ou outras ferramentas de persistência. Setores de jogos e negócios foram os mais visados, concentrados em EUA, Reino Unido, França e Austrália.

O risco é agravado porque o Cache Warmer vem empacotado dentro de outras extensões Mirasvit — muitos comerciantes rodam o componente vulnerável sem saber que ele está instalado, o que amplia a superfície real além do que aparece em inventários manuais de extensões.

Atualizar para Mirasvit Full Page Cache Warmer 1.11.12 ou superior é a única correção real — a Mirasvit lançou o patch em 25 de maio de 2026, um dia antes da atribuição do CVE. Como o Cache Warmer pode vir embutido em outros pacotes Mirasvit, é necessário revisar todas as extensões instaladas (via composer.json / módulos ativos no Magento) e não apenas procurar pelo nome do pacote isoladamente.

Se a atualização imediata não for possível, a única mitigação técnica viável é bloquear ou filtrar o cookie CacheWarmer na camada de borda (WAF ou proxy) até o patch ser aplicado — inspecionando e rejeitando valores que contenham a marca 'CacheWarmer:' seguida de string base64 característica de objeto serializado PHP. Desativar temporariamente o módulo Cache Warmer, se a operação permitir, remove a superfície de ataque por completo. Não há como mitigar isso ajustando apenas configuração do Magento core, já que a falha está no código do plugin de terceiro, não no framework.

Dado que o KEV da CISA já registra exploração confirmada e prazo de correção vencido (due date 2026-06-06), qualquer ambiente ainda na versão vulnerável deve ser tratado como potencialmente já comprometido: além de atualizar, é necessário varrer diretórios web-acessíveis (pub/ e afins) em busca de arquivos PHP inesperados e verificar indícios de webshell.

A assinatura de requisição é clara: procurar por requisições de storefront contendo um cookie CacheWarmer cujo valor traga o marcador 'CacheWarmer:' seguido de uma string em base64. Como objetos PHP serializados costumam começar, após codificação base64, com 'Tz', 'Qz' ou 'YT', um valor de cookie que combine com o padrão 'CacheWarmer:(Tz|Qz|YT)' é forte indicador de tentativa de exploração.

Em logs de aplicação ou WAF, payloads observados na exploração real referenciam classes do namespace Monolog\Handler (SyslogUdpHandler, BufferHandler, FingersCrossedHandler, GroupHandler) dentro da string serializada, e tentativas de comando de teste como 'PWNED_CVE2026_' ou padrões de 'sleep' embutidos no payload — presença desses termos em logs de acesso é evidência de tentativa de exploração, não apenas de varredura passiva.