Amasty: patch crítico de upload sem login. Confira suas versões hoje

As falhas que importam

Order Attributes (CVE-2026-53787, CVSS 9.3). Upload arbitrário de arquivo sem autenticação. Todas as versões até a 3.16.0, inclusive, estão vulneráveis; a correção é a 4.0.0, de 12 de junho de 2026. A Sansec registrou o primeiro ataque real horas depois do patch e mais de 12 mil tentativas em três dias, vindas de 45 endereços diferentes. Os endpoints atacados são estes:

POST /rest/V1/amasty_orderattr/uploadFile
POST /rest/all/V1/amasty_orderattr/uploadFile
POST /rest/default/V1/amasty_orderattr/uploadFile

Repare que a atualização é quebra de compatibilidade: a 4.0.0 passou a exigir um parâmetro attribute_code obrigatório no upload. Se você tem customização em cima desse endpoint, teste antes.

Gift Card e Advanced Product Reviews (críticas, julho de 2026). Mesma família de problema: upload de webshell sem login e execução de código. E tem um agravante no Gift Card que muda o plano de resposta — segundo a Sansec, essa falha permite escolher o local do upload, o que passa por cima do bloqueio padrão de execução de PHP em pub/media. Ou seja: quem confiava só naquele .htaccess não está protegido nesse caso.

As versões corrigidas dos módulos críticos:

Confira a sua loja em um minuto

Na raiz da loja:

composer show "amasty/*"

O Composer aceita máscara com curinga, então isso lista todo pacote Amasty instalado com a versão exata ao lado. Se o Composer estiver reclamando de plugin bloqueado ou de memória, dá para ler o mesmo dado direto do lock, sem depender dele:

php -r '$l=json_decode(file_get_contents("composer.lock"),true);
foreach($l["packages"] as $p){ if(strpos($p["name"],"amasty/")===0) printf("%-50s %s\n",$p["name"],$p["version"]); }'

Depois de comparar com a tabela, atualize só o que precisa:

composer require amasty/module-gift-card:^2.16.4 --update-with-dependencies
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento cache:flush

A lista crítica é a prioridade de hoje. Mas a leva de julho pegou dezenas de módulos, e vários são feijão com arroz de loja brasileira: amasty/shopby (Improved Layered Navigation) na 4.1.3, amasty/promo (Free Gift) na 2.19.0, amasty/module-shop-by-brand na 3.3.3 e amasty/rma na 2.11.0. A Sansec ainda estava acrescentando módulo à lista em 25 de agosto de 2026, então vale reler o aviso antes de dar o assunto por encerrado.

E se você já tomou

Atualizar fecha a porta. Não expulsa quem já entrou. Se a sua loja rodou uma versão vulnerável do Order Attributes depois de 12 de junho, faça essas três conferências antes de dormir tranquilo.

1. Procure o ataque no log do servidor.

grep -c "amasty_orderattr/uploadFile" /var/log/nginx/access.log*

Qualquer número diferente de zero merece uma olhada linha a linha. Um 200 nessa rota, vindo de IP que não é seu, é assunto sério.

2. Procure arquivo que não deveria existir. A recomendação da Sansec é revisar as pastas web atrás de .php, .phtml, .phar, .html e .svg inesperados. Ordene por data, que é o que entrega:

find pub/ -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.svg' \) \
  -newermt '2026-06-01' -printf '%TY-%Tm-%Td %p\n' | sort

3. Não pare no arquivo. Quem consegue executar código costuma deixar mais de uma porta: usuário de admin criado do nada, chave de integração nova, job de cron estranho. Confira a tabela admin_user e a lista em System > Extensions > Integrations.

Uma opinião, depois de ver isso acontecer com cliente: módulo pago não é mais seguro que módulo grátis, é só mais caro. O que separa loja invadida de loja intacta é ter alguém olhando a lista de versões uma vez por mês. Se você não tem essa rotina, o guia de hardening tem o checklist que eu uso.