O SessionReaper é a pior coisa que aconteceu com o Magento desde o CosmicSting, e o assunto não terminou quando o patch saiu. Patch fecha a porta. Ele não expulsa quem já estava dentro de casa.
Se a sua loja levou mais de um dia para receber a correção, ou se você assumiu a loja depois de outubro de 2025 e não sabe o que aconteceu ali, a varredura abaixo leva cinco minutos e responde a pergunta.
O ataque em 30 segundos
CVE-2025-54236, CVSS 9.1. O atacante envia uma sessão forjada que o Magento desserializa dentro da API REST, e disso sai execução de código no servidor. O arquivo em si entra pelo /customer/address_file/upload, o controller de anexo do endereço do cliente, sem login nenhum.
A linha do tempo que a Sansec registrou: patch de emergência em 09/09/2025 (APSB25-88), correção incluída no pacote regular de 14/10/2025, e o primeiro ataque em massa em 22/10/2025, no mesmo dia em que saiu a análise técnica pública. Em 26/10 metade das lojas do mundo já tinha sido atacada, com estimativa de 16% a 18% com pelo menos um backdoor plantado. Em 01/11, 81% tinham recebido visita.
O detalhe que muita gente não leu: a Adobe corrigiu a desserialização, não o upload. O arquivo continua caindo no disco mesmo em loja com patch. O que o patch faz é impedir que ele vire execução de código. Achar arquivo estranho em pub/media/customer_address/ numa loja que se corrigiu a tempo não é, sozinho, sinal de invasão.
Os cinco nomes e a pegadinha deles
A Sansec catalogou os nomes que os backdoors mais usaram. Três deles existem no Magento de verdade, e é aí que mora a armadilha: procurar pelo nome não acha nada, porque o arquivo já estava lá.
| Nome | Existe no Magento? | Como conferir |
|---|---|---|
static.php | Sim, é o pub/static.php | comparar com uma cópia limpa da mesma versão |
bootstrap.php | Sim, é o app/bootstrap.php | comparar com uma cópia limpa da mesma versão |
404.php | Sim, é o pub/errors/404.php | comparar com uma cópia limpa da mesma versão |
sysapi.php | Não | se existe, é invasão |
gsfa1faewf.txt | Não | se existe, é invasão |
Fora esses, a Sansec viu pub/rootz.php (com a assinatura do atacante dentro) e um pub/6376bad677a8.php baixado de um domínio externo. Os domínios de comando que apareceram nos ataques foram sagecrafft.com, worcksbot.com e tecnokauf.ru.
A varredura de cinco minutos
Comece pelo que não tem desculpa: arquivo PHP com data de alteração depois do patch. Rode na raiz da loja e olhe linha por linha.
find pub app var generated -name '*.php' -newermt '2025-09-01' -printf '%TF %p\n' | sortDepois procure os nomes que não pertencem a lugar nenhum:
find . -name 'sysapi.php' -o -name 'gsfa1faewf.txt' -o -name 'rootz.php'Agora os domínios de comando, dentro dos arquivos:
grep -rlE 'sagecrafft|worcksbot|tecnokauf' pub app var generatedE no banco, porque bloco de CMS é esconderijo clássico de carregador de JavaScript:
SELECT block_id, identifier FROM cms_block WHERE content LIKE '%worcksbot%' OR content LIKE '%sagecrafft%';Se a loja está em git, o atalho é melhor ainda: um git status na raiz mostra qualquer arquivo do core que foi mexido.
Achou alguma coisa. E agora
Pare de apagar. Arquivo apagado é prova perdida, e apagar um backdoor sem saber por onde ele entrou costuma render um segundo backdoor na semana seguinte. Guarde uma cópia dos arquivos suspeitos e dos logs de acesso do período antes de mexer.
A partir daí o roteiro é o de incidente: aplicar o patch (ou subir de versão) se ainda não aplicou, girar a chave de criptografia, trocar senha de admin, senha de banco e todos os tokens de integração, e passar um scanner de malware no document root inteiro. Chave vazada é o que permite ao atacante continuar editando bloco de CMS mesmo depois de você limpar tudo.
Quem ainda está em 2.3 ou em uma versão sem patch disponível tem o módulo wubinworks/module-session-reaper-patch como paliativo — ele fecha a falha por plugin, sem preference, então não trava upgrade futuro. Paliativo, não solução. O resto do que fechar num servidor de loja está no guia de segurança e hardening do Magento 2.
Perguntas rápidas
Apliquei o patch no dia que saiu. Preciso varrer mesmo assim?
Se aplicou dentro das primeiras 24 horas, o risco é baixo e a varredura serve só como conferência. O ataque em massa começou seis semanas depois do patch, em 22 de outubro de 2025, então quem se corrigiu em setembro passou longe da janela.
Encontrei arquivos estranhos em pub/media/customer_address. Fui invadido?
Não necessariamente. A Adobe não corrigiu o upload, só a desserialização, então esses arquivos de sessão falsa continuam chegando mesmo em loja com patch. O sinal de invasão é o backdoor fora dessa pasta, ou arquivo do core alterado.
Dá para saber a versão de patch da minha loja pela linha de comando?
Sim. Rode composer show magento/product-community-edition na raiz da loja e compare com a versão que corrigiu a falha na sua linha. Em Adobe Commerce o pacote é magento/product-enterprise-edition.