PolyShell no Magento: bloqueie a execução de PHP no pub/media

O que a falha faz

Produto com opção customizada do tipo file aceita upload. A API de carrinho recebe esse arquivo como um objeto file_info com o conteúdo em base64, o MIME type e o nome do arquivo, e grava em pub/media/custom_options/quote/.

Faltam três conferências no caminho, segundo a análise da Sansec: o ID da opção não é validado contra as opções reais do produto, o código roda mesmo que o produto não tenha nenhuma opção de arquivo, e a extensão não é restringida — .php, .phtml e .phar passam. A única validação é uma checagem de cabeçalho de imagem com getimagesizefromstring, que se contorna colocando o PHP dentro de um GIF válido. Daí o nome: um poliglota, imagem e código no mesmo arquivo.

As rotas mais perigosas não pedem credencial nenhuma:

Mutações GraphQL passam por outro caminho de código e não são afetadas.

Bloqueie a pasta agora

Antes de tudo, o aviso honesto: negar acesso à pasta não impede o upload. O arquivo continua sendo gravado no disco pela API. O que a regra faz é impedir que ele seja executado ou lido pelo navegador, o que já tira o ataque de pé. Quem barra o upload de fato é um WAF filtrando a chamada.

No nginx, a regra da Sansec entra no bloco server, antes de qualquer location que case com \.php$ — senão o handler de PHP ganha a disputa e o shell continua executável:

location ~* ^/pub/media/custom_options/ {
    deny all;
    return 403;
}

Se o seu document root é o pub/, que é o recomendado, o caminho na URL não tem o prefixo. O nginx.conf.sample oficial já cobre os dois casos e traz estas linhas:

location /media/custom_options/ {
    deny all;
}

Rode nginx -t e recarregue. Vale abrir o seu arquivo de vhost e conferir: a maior parte das lojas usa configuração pronta do provedor de hospedagem, não o sample da Adobe, e é aí que o buraco mora.

No Apache, o Magento já entrega um pub/media/custom_options/.htaccess com Require all denied. Ele só serve pra alguma coisa se o seu vhost tiver AllowOverride All nessa árvore. Confira o arquivo e a diretiva antes de dar por resolvido.

Procure o que já subiu

Bloquear a execução não apaga o que chegou antes. Comece pela pasta do upload:

find pub/media/custom_options/ -type f ! -name '.htaccess'

Qualquer .php, .phtml ou .phar ali é indício forte de comprometimento. A Sansec também catalogou uma segunda etapa: depois de conseguir execução, o atacante espalha um backdoor chamado accesson.php criando uma subpasta assets/images/ dentro de cada diretório de primeiro nível em que consegue escrever — var/, vendor/, pub/, generated/, lib/, app/ e por aí vai.

find /var/www -name 'accesson.php' -type f

E vale procurar no banco também: as páginas e blocos de CMS costumam receber um carregador de JavaScript ofuscado, que guarda o payload no localStorage do visitante pra sobreviver a recarga. Busque no conteúdo de CMS por referências aos domínios que a Sansec listou no relatório.

Se achar qualquer um desses arquivos, o roteiro deixa de ser "limpar" e passa a ser resposta a incidente: a loja teve execução remota de código.

O conserto de verdade é o 2.4.9

A regra de servidor é curativo. O código vulnerável existe desde a primeira versão do Magento 2 e a Adobe só corrigiu na linha 2.4.9, como parte do APSB25-94.

O que isso significa pro seu planejamento: 2.4.8 e 2.4.7 seguem em suporte regular — até 31/05/2028 e 31/05/2027 —, mas suporte regular não quer dizer que toda falha vira patch isolado. Nesse caso não virou. Coloque o upgrade pro 2.4.9 no calendário do trimestre em vez de deixar pra quando sobrar tempo.

Enquanto o upgrade não acontece, além do bloqueio da pasta eu faria mais duas coisas: rodar um scanner de malware no document root e revisar quem tem acesso de escrita no servidor. Ataque que dá execução remota raramente para no primeiro arquivo. O checklist completo do que fechar num servidor de loja está no guia de segurança e hardening do Magento 2.