Vulnerabilidade na API REST do Magento aceita arquivos disfarçados de imagem em opções de produto e pode levar a RCE, XSS armazenado e tomada de conta conforme a configuração do servidor web.
| Componente | API REST do Magento usada para upload de arquivos em opções customizadas de itens no carrinho, com gravação em pub/media/custom_options/quote/. |
| Vetor | Requisições não autenticadas podem enviar um objeto file_info com dados em base64, tipo MIME e nome de arquivo quando uma opção de produto tem tipo file. |
| Impacto | Dependendo da configuração do servidor web, o upload irrestrito pode permitir execução remota de código por PHP enviado como imagem poliglota ou tomada de conta por XSS armazenado. |
| Prioridade | Restringir acesso a pub/media/custom_options/, revisar configuração do servidor web e priorizar atualização quando houver correção aplicável ao ramo em produção. |
| Versões | A falha afeta Magento Open Source e Adobe Commerce até 2.4.9-alpha2; a correção foi incorporada ao ramo pré-lançamento 2.4.9 em APSB25-94. |
| Exploração | Foi relatada exploração ativa desde 16 de março de 2026, com varredura automatizada em massa iniciada três dias depois e ao menos 50 endereços IP envolvidos na atividade. |
A vulnerabilidade PolyShell expõe uma condição crítica no fluxo de upload da API REST do Magento. O problema aparece quando uma opção customizada de produto aceita arquivo e o carrinho processa um objeto file_info contendo conteúdo codificado em base64, tipo MIME e nome de arquivo. Esse material é gravado no caminho pub/media/custom_options/quote/, área que pode ficar acessível pelo servidor web dependendo da configuração adotada pela loja. A falha é relevante porque o atacante não precisa de autenticação para acionar o fluxo de upload descrito no contexto.
O nome PolyShell decorre do uso de arquivos poliglotas: imagens válidas, como GIF ou PNG, que também carregam código PHP incorporado. Em uma configuração permissiva, o servidor pode tratar o arquivo enviado como executável e permitir execução remota de código. Em outro cenário, o mesmo problema pode sustentar XSS armazenado e tomada de conta, caso o arquivo ou seu conteúdo seja apresentado a usuários em uma superfície renderizável. A exploração ativa foi observada a partir de 16 de março de 2026, com automação de varredura em massa três dias depois.
O fluxo vulnerável começa no suporte legítimo a opções de produto com arquivo. Quando a opção possui tipo file, o Magento aceita metadados do arquivo e o conteúdo embutido no objeto file_info. O controle insuficiente sobre o tipo real do arquivo, o nome fornecido e a consequência da gravação no diretório de mídia cria a janela de abuso. O atacante pode enviar um arquivo que aparenta ser imagem válida, mas que também contém código interpretável como PHP. O risco aumenta quando o servidor web permite execução de scripts em diretórios destinados a mídia carregada por usuários.
Os ataques observados usaram arquivos poliglotas e entregaram payloads PHP com função de web shell. O contexto descreve dois efeitos: uma web shell capaz de executar código arbitrário e uma shell RCE protegida por senha que repassa comandos para system(). Por conformidade defensiva, o detalhe operacional do comando e do payload deve ser omitido em playbooks públicos; para a defesa, o ponto essencial é que o upload cria um arquivo persistente em área web e que a execução depende da interpretação do servidor após a gravação.
A correção aparece no ramo pré-lançamento 2.4.9 como parte de APSB25-94, mas o texto recebido indica ausência de patch isolado para versões atuais em produção no momento da publicação. Isso muda a prioridade operacional: lojas que ainda não conseguem aplicar a versão corrigida precisam reduzir a exposição do diretório de upload, bloquear execução de scripts em mídia e revisar regras de WAF especializadas. Apenas negar acesso HTTP ao diretório não impede que novos arquivos sejam gravados, portanto a mitigação precisa considerar gravação, execução e visibilidade.
A superfície inclui instalações Magento Open Source e Adobe Commerce até 2.4.9-alpha2 que exponham a API REST e possuam produtos com opções customizadas do tipo arquivo. O impacto prático varia conforme o servidor web. Ambientes que seguem uma configuração restritiva para diretórios de mídia tendem a limitar a consequência do upload, enquanto configurações customizadas de hospedagem podem permitir que arquivos gravados em pub/media/custom_options/quote/ sejam acessados e interpretados de forma perigosa.
A campanha paralela de comprometimento e desfiguração de sites Magento amplia o alerta, embora o contexto não confirme que ela use a PolyShell. A atividade começou em 27 de fevereiro de 2026 e envolveu arquivos de texto em diretórios web públicos em cerca de 15.000 hostnames distribuídos por 7.500 domínios. Também foi observado ao menos um caso de PHP malicioso em /media/customer_address, possivelmente relacionado a exploração de SessionReaper, mas essa relação não deve ser tratada como prova de vínculo com PolyShell.
- Lojas Magento Open Source e Adobe Commerce até
2.4.9-alpha2com API REST acessível. - Produtos que aceitam opção customizada de arquivo e processam
file_infono carrinho. - Servidores web que permitem execução de PHP ou renderização insegura em diretórios sob
pub/media/. - Ambientes de hospedagem com configuração customizada diferente do modelo restritivo recomendado.
A investigação deve começar por acessos e gravações em pub/media/custom_options/quote/ e pub/media/custom_options/. O foco não é apenas procurar extensões óbvias de PHP. Arquivos poliglotas podem manter cabeçalho de imagem válido e ainda carregar código executável. Equipes de DFIR devem correlacionar eventos de upload anônimo, requisições REST associadas a carrinho e acessos subsequentes ao arquivo recém-criado. Uma sequência curta entre gravação e requisição HTTP direta ao artefato é um sinal forte de tentativa de validação ou execução.
A telemetria de servidor web deve ser cruzada com eventos de aplicação, WAF, EDR e integridade de arquivos. Busque criação de arquivos em diretórios de mídia com conteúdo incompatível com o tipo declarado, nomes incomuns, tentativas repetidas de upload e erros de execução PHP em caminhos que deveriam conter somente ativos estáticos. Como a varredura automatizada envolveu ao menos 50 IPs, picos de requisições contra rotas de carrinho, opções customizadas ou uploads de mídia podem indicar reconhecimento em massa.
- Criação recente de arquivos em
pub/media/custom_options/quote/com assinatura de imagem e trechos compatíveis com PHP. - Acesso HTTP direto a arquivos recém-gravados em diretórios de mídia do Magento.
- Requisições não autenticadas para fluxos REST de carrinho que incluam metadados
file_info. - Erros de PHP, processos filhos incomuns ou chamadas de sistema originadas de caminhos sob
pub/media/. - Arquivos de desfiguração em diretórios web públicos e uploads inesperados em
/media/customer_address.
A resposta deve priorizar contenção da execução e redução do abuso de upload. Restrinja o acesso a pub/media/custom_options/, mas trate essa ação como camada parcial: o bloqueio de acesso não impede, por si só, que arquivos maliciosos continuem sendo enviados. A configuração do servidor web deve negar execução de PHP em diretórios de mídia e uploads, validar mapeamento de tipos MIME de forma conservadora e impedir que extensões perigosas sejam interpretadas quando armazenadas sob pub/media/.
Em paralelo, revise produtos que aceitam opções de arquivo, regras de WAF relacionadas a uploads e controles de autenticação e taxa nas rotas REST afetadas. Ambientes com sinais de exploração precisam preservar artefatos, coletar logs antes de limpeza, remover web shells, revisar contas administrativas e investigar sessões ou alterações de conteúdo. Quando a atualização aplicável estiver disponível para o ramo em produção, ela deve ser tratada como correção principal; até lá, a combinação de hardening do servidor web, monitoramento de integridade e bloqueio de execução em mídia reduz o caminho de exploração.
- Negar execução de PHP e outros scripts em todos os diretórios de mídia e upload, incluindo
pub/media/custom_options/. - Restringir acesso público ao diretório de upload afetado e validar se a restrição não quebrou fluxos legítimos de compra.
- Auditar arquivos recentes em
pub/media/e remover artefatos incompatíveis com mídia legítima após preservação forense. - Criar alertas para upload anônimo com
file_info, acesso direto a arquivos recém-criados e execução anômala a partir do servidor web. - Aplicar a correção do ramo
2.4.9quando compatível com o ambiente e acompanhar a disponibilidade de patch para versões em produção.
0 Comentários