O código malicioso carrega JavaScript por canais de dados WebRTC e exfiltra informações de pagamento por UDP cifrado, enquanto ataques PolyShell exploram lojas com configuração web desviada do padrão recomendado.
| Componente | Skimmer JavaScript em sites de comércio eletrônico, com exploração associada à vulnerabilidade PolyShell em Magento Open Source e Adobe Commerce. |
| Vetor | Upload de arquivo poliglota por requisição HTTP POST ao endpoint REST /rest/default/V1/guest-carts/{cart_id}/items, com execução condicionada a desvio da configuração web recomendada para diretórios sob pub/media/custom_options/. |
| Impacto | Carregamento de JavaScript malicioso na página de checkout e exfiltração de dados de pagamento por canais de dados WebRTC sobre UDP cifrado com DTLS, fora do fluxo HTTP inspecionado por muitas defesas. |
| Prioridade | Bloquear acesso a pub/media/custom_options/, procurar web shells e backdoors nas lojas, revisar regras Nginx ou Apache e validar quando a correção chegar aos ramos de produção. |
| Versões | A correção para PolyShell foi disponibilizada em 2.4.9-beta1 em 10 de março de 2026, mas ainda não havia chegado às versões de produção descritas no contexto. |
| IoCs | O skimmer observado estabelecia conexão WebRTC com o endereço defangado 202.181.177[.]177 pela porta UDP 3479. |
Uma campanha contra comércio eletrônico passou a usar um skimmer de pagamento que troca o padrão tradicional de exfiltração via HTTP por canais de dados WebRTC. O código malicioso foi descrito como um script autoexecutável: ao ser carregado na página, ele cria uma conexão ponto a ponto com um endereço IP codificado no próprio script, recupera JavaScript adicional e injeta esse conteúdo no fluxo visual do site para capturar informações de pagamento digitadas pelo usuário. A mudança é relevante porque tira a operação do caminho mais monitorado em ataques de skimming, no qual requisições HTTP, beacons por imagem ou chamadas para domínios externos costumam ser bloqueados por política de segurança de conteúdo e por inspeção de tráfego web.
A atividade foi associada a uma exploração da vulnerabilidade PolyShell em Magento Open Source e Adobe Commerce. A falha permite que um invasor não autenticado envie executáveis arbitrários pela API REST e alcance execução de código quando a instância tem configuração web permissiva. O caso citado envolve o site de comércio eletrônico de uma fabricante de veículos, o que indica uso prático contra checkout real, não apenas prova de conceito. A exploração em massa teria começado em 19 de março de 2026, com mais de 50 endereços IP participando de varreduras, e ataques PolyShell foram encontrados em 56,7% das lojas vulneráveis observadas no levantamento recebido.
O fluxo combina dois elementos: a porta de entrada PolyShell e a etapa de skimming baseada em WebRTC. A raiz da falha está na função ImageProcessor::processImageContent(), que aceita uma imagem considerada válida e move o arquivo para uma pasta de destino sob pub/media/custom_options/quote/. A validação descrita verifica se o conteúdo não está vazio, se tem tamanho, se possui tipo MIME válido e se o nome do arquivo não contém caracteres bloqueados. O ponto crítico é a ausência de uma checagem que obrigue a extensão do arquivo a corresponder ao tipo MIME informado. Com isso, um arquivo poliglota pode satisfazer a lógica de validação como imagem e ainda carregar comportamento executável quando o servidor permite esse tratamento.
O acionamento da falha envolve uma requisição HTTP POST ao endpoint REST de itens em carrinhos de convidados, representado por /rest/default/V1/guest-carts/{cart_id}/items. A publicação técnica recebida deixa uma condição importante: o arquivo enviado só fica acessível e executável se o servidor web estiver configurado de forma diferente dos exemplos recomendados para Magento e Adobe Commerce. Em configurações Nginx ou Apache alinhadas ao padrão sugerido, tentativas de acessar esses arquivos resultam em erro 404 ou são bloqueadas por regras de negação e restrições à execução de PHP. Remover cláusulas de negação no caminho pub/media/custom_options pode abrir espaço para XSS, e retirar restrições de execução de PHP pode transformar o upload em execução de código.
Depois da inserção do componente malicioso, o skimmer estabelece uma conexão WebRTC com o IP defangado 202.181.177[.]177 usando a porta UDP 3479. O canal de dados WebRTC transporta o JavaScript de segunda etapa e também serve como caminho de saída para as informações capturadas. Como o tráfego roda sobre UDP cifrado com DTLS, ferramentas que dependem de inspeção HTTP não enxergam o conteúdo da exfiltração. A política CSP continua útil para reduzir conexões web não autorizadas, mas, isoladamente, não cobre esse canal quando o navegador permite WebRTC e a aplicação comprometida consegue iniciar a comunicação.
A superfície exposta é formada por lojas Magento Open Source e Adobe Commerce que aceitam o fluxo de carrinho de convidado e mantêm configurações web que permitem acesso ou execução indevida de arquivos enviados para diretórios de mídia. O risco não decorre apenas da presença do software vulnerável; ele depende também da forma como Nginx, Apache e arquivos de controle de acesso foram implantados. Instâncias que removeram regras de bloqueio em diretórios de upload, que perderam arquivos .htaccess necessários ou que relaxaram restrições de execução em áreas de mídia ficam em posição mais frágil.
O impacto operacional concentra-se em páginas de compra e checkout, nas quais o JavaScript injetado consegue observar dados de pagamento antes ou durante a submissão legítima do formulário. Não há base no contexto para afirmar movimentação lateral, acesso a bancos internos ou comprometimento generalizado de dados armazenados; o efeito confirmado é a captura de informações de pagamento por skimmer no navegador e a possibilidade de execução de código em servidores com configuração vulnerável.
- Lojas Magento Open Source e Adobe Commerce expostas ao fluxo REST de carrinho de convidado.
- Diretórios sob
pub/media/custom_options/acessíveis ou executáveis por configuração web permissiva. - Servidores Nginx ou Apache com desvios das regras recomendadas para negar acesso a pastas e bloquear execução de PHP em mídia.
- Páginas de checkout capazes de carregar JavaScript injetado após comprometimento do ambiente.
A investigação deve começar pela correlação entre atividade no endpoint REST de carrinho de convidado, criação de arquivos em caminhos de mídia e tráfego UDP incomum saindo de sessões de navegador ou do perímetro associado ao checkout. O uso de WebRTC reduz a visibilidade de controles focados em HTTP, portanto a ausência de beacon HTTP suspeito não elimina a hipótese de skimming. Também é necessário revisar integridade de arquivos, alterações recentes em diretórios de upload e presença de web shells, backdoors ou scripts adicionados fora do processo normal de publicação.
No navegador e na camada de rede, sinais úteis incluem conexões WebRTC para infraestrutura inesperada, uso da porta UDP 3479 e criação de canais de dados durante interação com páginas de pagamento. Em servidores, os registros de acesso devem ser examinados para requisições ao endpoint REST de itens de carrinho, principalmente quando seguidas por tentativas de acessar conteúdo recém-gravado em pub/media/custom_options/. Em ambientes com WAF, proxy reverso ou EDR no servidor, eventos de escrita e execução em diretórios de mídia merecem prioridade, porque esses caminhos normalmente não devem hospedar código executável.
- Requisições anômalas ao endpoint
/rest/default/V1/guest-carts/{cart_id}/items. - Arquivos recentes ou com extensão incoerente em
pub/media/custom_options/e subdiretórios. - Conexões UDP para
202.181.177[.]177na porta 3479 ou para destinos WebRTC não esperados. - JavaScript novo, ofuscado ou autoexecutável em páginas de checkout e pagamento.
- Logs 404, bloqueios ou acessos incomuns relacionados a arquivos enviados como imagens.
A contenção deve priorizar a superfície de upload e a execução de conteúdo em mídia. Bloquear acesso direto a pub/media/custom_options/ reduz a viabilidade da cadeia quando o ataque depende de tornar o arquivo carregado acessível pelo servidor web. Em paralelo, a equipe deve revisar as configurações Nginx ou Apache em comparação com os exemplos recomendados para Magento e Adobe Commerce, garantindo que diretórios de mídia não executem PHP e que regras de negação continuem ativas. A correção publicada em 2.4.9-beta1 indica o caminho de remediação do produto, mas o contexto informa que ela ainda não estava disponível nos ramos de produção no momento da notícia; por isso, controles compensatórios continuam essenciais.
Depois do bloqueio inicial, a resposta deve tratar a loja como potencialmente adulterada. Isso inclui varredura de web shells e backdoors, comparação de arquivos do checkout com versões conhecidas, revisão de scripts de terceiros e validação de CSP, mesmo sabendo que CSP não cobre sozinha a exfiltração via WebRTC. Quando houver suspeita de captura de pagamento, a organização deve preservar logs, acionar o fluxo interno de resposta a incidente e coordenar análise com antifraude e adquirentes, limitando a comunicação externa a fatos confirmados pela investigação.
- Negar acesso web a
pub/media/custom_options/e subdiretórios usados por uploads de opções customizadas. - Confirmar que arquivos em diretórios de mídia não podem ser executados como PHP.
- Procurar web shells, backdoors e JavaScript não autorizado em checkout e temas ativos.
- Monitorar ou restringir WebRTC quando o modelo operacional da loja não exige esse recurso.
- Acompanhar a chegada da correção aos ramos de produção e aplicar atualização assim que estiver disponível para o ambiente afetado.
0 Comentários