A vulnerabilidade CVE-2026-45247 permite execução remota de código PHP por desserialização de dados não confiáveis e já é explorada contra lojas Magento vulneráveis.
| Componente | Mirasvit Cache Warmer, extensão de cache de página completa para Magento, em versões anteriores à 1.11.12. |
| Vetor | Requisições HTTP maliciosas entregam objetos PHP serializados e codificados em base64 para acionar desserialização de dados controlados pelo cliente. |
| Impacto | Execução remota de código PHP no servidor afetado por injeção de objeto PHP e uso de cadeias de gadgets presentes no Magento e em suas dependências. |
| Prioridade | Atualizar a extensão para a versão 1.11.12 ou posterior e revisar tráfego HTTP em busca de payloads serializados relacionados à exploração da CVE-2026-45247. |
| Exploração | Atividade ativa foi observada contra sites de jogos e negócios, com alvos nos Estados Unidos, Reino Unido, França e Austrália. |
| Artefatos | Payloads observados tentam acionar desserialização PHP e invocar funções como system() e current() para validar execução de código. |
A CISA adicionou a vulnerabilidade crítica CVE-2026-45247 ao catálogo de Vulnerabilidades Conhecidas Exploradas depois de relatos de exploração ativa contra ambientes Magento que usam a extensão Mirasvit Cache Warmer. A falha recebeu pontuação CVSS 9.8 e afeta todas as versões anteriores à 1.11.12, com correções disponibilizadas em 25 de maio de 2026. O componente vulnerável é usado para aquecimento de cache de página completa, o que o coloca em uma área sensível para lojas virtuais: ele opera junto a rotas web expostas, lógica de entrega de conteúdo e infraestrutura que normalmente recebe tráfego externo contínuo.
O problema técnico é desserialização de dados não confiáveis. Um valor vindo diretamente do cliente pode influenciar os objetos reconstruídos pelo PHP, abrindo caminho para injeção de objeto PHP, classificada como CWE-502. Quando essa condição encontra uma cadeia de gadgets já disponível em classes do Magento e de suas dependências, a falha deixa de ser apenas manipulação insegura de objeto e passa a permitir execução remota de código no servidor. A exploração observada busca confirmar se a execução de comandos é possível, o que torna a atualização e a caça por requisições suspeitas uma prioridade para operadores de lojas Magento expostas à internet.
A exploração não foi atribuída publicamente a um ator específico no material analisado. O objetivo observado parece ser identificar instalações vulneráveis e validar execução remota de código. Isso é relevante porque testes de execução bem-sucedidos podem anteceder etapas posteriores, como implantação de artefatos adicionais, alteração de conteúdo, criação de persistência ou abuso do servidor para outras finalidades; essas consequências, porém, não devem ser tratadas como confirmadas para está campanha sem evidência adicional.
A cadeia de exploração começa com uma requisição HTTP construída para entregar dados serializados ao ambiente Magento que executa uma versão vulnerável do Mirasvit Cache Warmer. Os payloads observados contêm objetos PHP serializados codificados em base64, desenhados para serem processados por uma rotina que aceita dado controlado pelo cliente. Quando o servidor desserializa esse conteúdo sem validação adequada, o atacante passa a influenciar quais objetos são reconstruídos em memória e quais métodos podem ser acionados de forma indireta durante o ciclo de vida desses objetos.
A etapa crítica é a combinação entre injeção de objeto PHP e cadeia de gadgets. Em aplicações PHP complexas, bibliotecas e dependências podem conter classes com métodos mágicos ou comportamentos acionados durante desserialização, destruição, conversão ou acesso a propriedades. A falha descrita permite que objetos escolhidos pelo atacante sejam reconstruídos, e a presença dessas classes no Magento ou em suas dependências pode transformar a desserialização em execução de código. No caso observado, os payloads tentam invocar funções como system() e current() para executar comandos no sistema subjacente ou validar que o caminho de execução foi alcançado. Comandos específicos e payloads reproduzíveis devem ser tratados como conteúdo operacional e omitidos em documentação defensiva.
O impacto confirmado no contexto é execução arbitrária de código PHP no servidor afetado. A pré-condição principal é a presença da extensão Mirasvit Cache Warmer em versão anterior à 1.11.12 em uma instalação Magento acessível ao tráfego malicioso. A existência de CDNs na frente da loja não elimina o risco; ela pode reduzir a visibilidade direta da instalação e dificultar estimativas externas, mas a requisição ainda pode alcançar a aplicação se a rota vulnerável estiver exposta e não houver bloqueio efetivo na camada de borda.
A superfície afetada envolve lojas Magento que instalaram o Mirasvit Cache Warmer antes da versão corrigida. A extensão é descrita como popular no ecossistema de cache de página completa, e uma estimativa identificou cerca de 6.000 lojas executando extensões da Mirasvit. O número real pode ser maior porque serviços de CDN, incluindo Cloudflare, podem mascarar instalações e impedir contagem precisa por varreduras externas. Para defesa, a contagem global é menos importante do que o inventário local: qualquer ambiente Magento com essa extensão deve ser tratado como candidato à atualização imediata.
A atividade observada priorizou sites dos setores de jogos e negócios, com maior incidência em alvos nos Estados Unidos, Reino Unido, França e Austrália. Esses recortes não devem ser interpretados como limitação de alvo. A falha depende de componente e versão, não de geografia ou segmento. Ambientes fora desses países ou setores continuam expostos se executarem a extensão vulnerável e aceitarem as requisições capazes de acionar a desserialização.
- Instalações Magento com Mirasvit Cache Warmer anterior à versão 1.11.12.
- Servidores web que recebem requisições HTTP externas direcionadas a rotas processadas pela extensão vulnerável.
- Ambientes protegidos por CDN que ainda encaminham tráfego malicioso à aplicação de origem.
- Lojas de comércio eletrônico em que inventário de extensões, versão instalada e data de atualização não estejam documentados.
A investigação deve começar pelos logs de acesso HTTP, registros de aplicação Magento, telemetria de WAF e eventos de processo no servidor. O sinal mais direto é a presença de requisições incomuns contendo dados serializados em PHP, especialmente quando codificados em base64 e direcionados a rotas relacionadas ao comportamento da extensão. Em vez de publicar payloads, a defesa deve procurar padrões estruturais: strings longas codificadas, objetos serializados, parâmetros com conteúdo anormal para a rota, taxas elevadas de erro após requisições específicas e respostas que indiquem diferença de comportamento entre tentativas.
No endpoint, eventos relevantes incluem criação de processos filhos pelo servidor web ou pelo interpretador PHP, invocação de funções associadas à execução de comandos e qualquer teste curto que pareça validar execução no sistema. O contexto cita tentativas de uso de system() e current(), incluindo comandos de teste para confirmar execução; portanto, a correlação entre requisições suspeitas e processos iniciados logo em seguida é mais útil do que a busca isolada por uma string. Em ambientes com WAF, vale revisar bloqueios, desafios e permissões recentes para confirmar se tentativas chegaram à origem.
A ausência de um ator atribuído exige foco em comportamento, não em nome de campanha. Indicadores estáticos podem mudar rapidamente, enquanto a técnica central permanece: entrada controlada pelo cliente, desserialização PHP, cadeia de gadgets e tentativa de execução de código. Equipes de segurança devem preservar amostras de requisições de forma redigida, sem expor payloads operacionais, para permitir correlação interna e validação de regras sem transformar documentação em material reproduzível.
- Requisições HTTP com objetos PHP serializados ou conteúdo base64 anormal em parâmetros associados ao Magento.
- Eventos de aplicação próximos a erros de desserialização, exceções PHP ou comportamento inesperado em rotas da extensão.
- Processos filhos incomuns iniciados por servidor web, PHP ou usuário de serviço da aplicação após requisições suspeitas.
- Tentativas repetidas de validação de execução remota de código, mesmo quando não houver persistência ou carga adicional confirmada.
A mitigação principal é atualizar o Mirasvit Cache Warmer para a versão 1.11.12 ou posterior. Como a vulnerabilidade já entrou no catálogo KEV e há exploração ativa, a atualização deve ser tratada como correção de emergência para ambientes expostos. Antes e depois da atualização, operadores devem confirmar a versão instalada no ambiente de produção, homologação e quaisquer cópias públicas esquecidas. Também é necessário validar se caches, imagens de contêiner, artefatos de deploy ou automações de provisionamento não reinstalam uma versão vulnerável em novos servidores.
A contenção deve combinar correção do componente, redução de exposição e revisão de telemetria histórica desde pelo menos a data de disponibilização da correção, em 25 de maio de 2026, ou por uma janela maior se a organização mantiver logs suficientes. Quando houver sinais de execução de código, a resposta deve avançar para análise de integridade do servidor, revisão de arquivos modificados, comparação de artefatos da aplicação, verificação de contas de serviço e análise de processos. O material analisado confirma tentativas de execução e testes de validação, mas cada ambiente deve determinar localmente se houve execução bem-sucedida.
Controles compensatórios podem reduzir risco enquanto a atualização é validada, mas não substituem o patch. Regras de WAF devem bloquear padrões de desserialização PHP e conteúdo codificado suspeito em rotas afetadas, com cuidado para não depender apenas de assinaturas literais. CDNs e proxies devem registrar cabeçalhos, corpo quando permitido por política e metadados suficientes para investigação. Após a correção, a equipe deve testar funcionalidade de cache, confirmar que a versão vulnerável não permanece em nós secundários e manter monitoramento reforçado para novas tentativas contra a CVE-2026-45247.
- Atualizar o Mirasvit Cache Warmer para a versão 1.11.12 ou posterior em todos os ambientes Magento expostos.
- Revisar logs HTTP, WAF, aplicação e endpoint em busca de tentativas de desserialização PHP e validação de execução de código.
- Adicionar bloqueios na borda para payloads serializados suspeitos, mantendo registro suficiente para investigação defensiva.
- Verificar pipelines, imagens, caches e automações de deploy para impedir reinstalação de versões anteriores à 1.11.12.
- Se houver indício de execução bem-sucedida, tratar o servidor como potencialmente comprometido e conduzir análise de integridade antes de retornar à operação normal.
0 Comentários