Para quem é: empresas que mantêm lojas virtuais em Adobe Commerce (antigo Magento Commerce) ou Magento Open Source, as agências que as desenvolvem e mantêm, e provedores de hospedagem. Este artigo se baseia em informações públicas da Adobe, da CISA e do NVD, e em relatórios de uma empresa de segurança de e-commerce. Não trata de etapas de ataque nem de código de exploração.
Em andamento: esta página será atualizada conforme novas informações forem publicadas
Em 28 de outubro de 2026 (horário do Japão)Ainda não se sabe
- Confirmação da exploração pela Adobe (o boletim ainda diz que ela não tem conhecimento)
- Alertas de órgãos públicos japoneses (nenhum do JPCERT/CC nem do IPA)
- Vítimas entre lojas no Japão (nenhuma divulgada)
A CISA incluiu a falha no KEV em 27 de outubro. A correção da Adobe saiu em 14 de julho. Os detalhes da exploração vêm de relatórios de uma empresa de segurança de e-commerce, que a Adobe não confirmou. Atualizaremos este artigo quando houver novos anúncios.
O que fazer hoje
Verifique sua versão e se a correção está aplicada
Execute bin/magento --version no servidor da loja para verificar a versão. A correção de julho é distribuída como um patch isolado aplicado sobre a versão de segurança mais recente de cada linha (por exemplo, 2.4.7-p10). Para verificar se está aplicada, use o Quality Patches Tool (vendor/bin/magento-patches -n status) em ambientes hospedados pela Adobe e, em outros ambientes, a Commerce Version Tool incluída na correção (disponível depois que o patch CE é aplicado) (notas de versão da Adobe). Se uma agência ou empresa de manutenção cuida da sua loja, pergunte a ela sobre os dois pontos.
Aplique a correção
O procedimento da Adobe é primeiro passar para a versão de segurança mais recente (a versão -p) da sua linha (a 2.4.9 fica como está) e depois aplicar a correção de julho. Os patches não são cumulativos, então aplique-os em ordem. Se você usa o módulo Adobe Commerce Events, atualize-o para 1.21.0 ou posterior. Para ambientes hospedados pela Adobe (Adobe Commerce on cloud infrastructure), a Adobe diz que a versão mais recente do Magento Cloud Patches corrige o problema, e alerta que aplicar o patch isolado por cima pode fazer a instalação falhar. Siga as orientações da Adobe.
Verifique as pastas de upload
A empresa de segurança de e-commerce relata que web shells foram instalados em pub/media/custom_options/ (especialmente na pasta quote dentro dela) e recomenda verificar também pub/media/customer_address/. Procure arquivos disfarçados com nomes de imagem e arquivos executáveis como .php, .phtml ou .phar. Normalmente essas pastas guardam coisas como arquivos que os clientes anexam aos pedidos.
Verifique os blocos CMS, as páginas CMS e as contas de administrador
No banco de dados, verifique as tabelas cms_block e cms_page em busca de tags <script> que você não adicionou e de entradas alteradas recentemente (update_time). O relatório da mesma empresa lista as strings a procurar. Verifique admin_user em busca de contas que você não reconhece, e o servidor em busca de processos desconhecidos em execução.
Se encontrar sinais, limpe e depois troque as credenciais
Depois de remover os arquivos e scripts maliciosos, troque as senhas e os tokens das contas de administrador, do banco de dados e das integrações de API. Remover só um script deixa aberto o caminho de volta do atacante (um web shell ou uma conta de administrador). Se a página de checkout foi alterada, contate as bandeiras e emissores de cartão e seu provedor de pagamentos.
Medidas provisórias se você não puder aplicar a correção de imediato (elas não impedem o ataque)
A mesma empresa recomenda configurar o servidor web para negar o acesso web a pub/media/custom_options/ e impedir que o PHP seja executado ali. Isso impede que arquivos enviados sejam executados de fora, mas não impede que arquivos sejam enviados. A empresa diz que é necessária uma regra de WAF (um sistema que inspeciona o tráfego de aplicações web) para bloquear as próprias requisições de upload. Ambas são soluções temporárias até você aplicar a correção.
Versões afetadas e corrigidas
| Produto | Afetado | Correção (notação da Adobe) |
|---|---|---|
| Adobe Commerce | 2.4.9, 2.4.8-p5 e anteriores, 2.4.7-p10 e anteriores, 2.4.6-p15 e anteriores, 2.4.5-p17 e anteriores, 2.4.4-p18 e anteriores | 2026-jul para cada uma de 2.4.9, 2.4.8, 2.4.7, 2.4.6, 2.4.5, 2.4.4 |
| Adobe Commerce B2B | 1.5.3, 1.5.2-p5 e anteriores, 1.4.2-p10 e anteriores, 1.3.4-p17 e anteriores, 1.3.3-p18 e anteriores | 2026-jul para cada uma de 1.5.3, 1.5.2, 1.4.2, 1.3.4, 1.3.3 |
| Magento Open Source | 2.4.9, 2.4.8-p5 e anteriores, 2.4.7-p10 e anteriores, 2.4.6-p15 e anteriores | 2026-jul para cada uma de 2.4.9, 2.4.8, 2.4.7, 2.4.6 |
| Adobe Commerce Events | 1.6.0 a 1.20.0 | 1.21.0 |
“2026-jul” não é um novo número de versão. Significa a versão de segurança mais recente de cada linha com o patch isolado de julho aplicado. Nas notas de versão da Adobe, os arquivos do patch são separados por versão de destino, por exemplo “2-4-7-p10-jul-2026.zip”. Usuários do Magento Open Source só podem baixar os patches diretamente para a 2.4.6 e posteriores.
A tabela da Adobe também lista a 2.4.9 como afetada. A empresa de segurança de e-commerce escreve que a 2.4.9 incluía a correção dessa falha, mas o boletim abrange 14 falhas corrigidas no mesmo dia. Recomendamos seguir a tabela da Adobe e aplicar a correção de julho também na 2.4.9.
A falha que permite o upload de arquivos (a porta de entrada)
Corrigida pela correção de julho (2026-jul)
Web shells instalados
Não removidos pela correção. Verifique as pastas de upload
Scripts injetados nas páginas
Não removidos pela correção. Verifique cms_block e cms_page
Administradores adicionados e credenciais possivelmente expostas
Não removidos pela correção. Verifique admin_user e troque as credenciais
O que foi divulgado
- CVE
- CVE-2026-48356 (boletim de segurança da Adobe APSB26-73)
- Tipo
- Upload irrestrito de arquivo de tipo perigoso (CWE-434). A Adobe indica como impacto a escalada de privilégios e como gravidade crítica, e diz que não é necessária autenticação
- Gravidade
- CVSS v3.1 9,6 na tabela do boletim da Adobe (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L). 9,3 no valor que a Adobe registrou no registro CVE e na nota do NVD (idêntico exceto A:N)
- Impacto (descrição da CVE)
- Execução de código arbitrário no contexto do usuário atual, podendo levar ao controle da conta ou da sessão da vítima. Diz que a exploração exige que a vítima abra uma URL manipulada ou interaja com uma página comprometida
- Correção
- Publicada em 14 de julho de 2026 (atualizada em 11 de agosto). O mesmo boletim corrige 14 vulnerabilidades, e esta é a única no KEV. A classificação de prioridade da Adobe é 2, a intermediária de três níveis
- Exploração (Adobe)
- A Adobe diz que não tem conhecimento de exploração (conforme publicado em 28 de outubro)
- Exploração (CISA)
- Incluída no KEV em 27 de outubro de 2026. O prazo para as agências civis federais dos EUA (FCEB) é 10 de novembro. Uso em campanhas de ransomware: “Unknown”. A avaliação SSVC da CISA no NVD classifica a exploração como “active”
Os dois valores CVSS diferem apenas em se o impacto na disponibilidade (A) é “baixo” ou “nenhum”. Ambos estão na faixa de 9 em uma escala de 10, que é crítica, e a prioridade não muda. A descrição da CVE diz que é necessária interação do usuário (UI:R), mas o texto de março da empresa, descrito abaixo, diz que é possível enviar arquivos sem fazer login. Damos mais peso à inclusão no KEV do que aos detalhes da nota (visão deste site).
A outra falha que a CISA incluiu no KEV no mesmo dia é uma vulnerabilidade no formato de compressão Brotli (CVE-2026-111497). Organizações no Japão não estão sujeitas ao prazo dos EUA, mas a CISA incentiva todas as organizações a priorizar a correção das vulnerabilidades do KEV.
Relatos de ataques (pesquisa de uma empresa de segurança de e-commerce)
O que segue vem de uma empresa de segurança especializada em investigar lojas virtuais comprometidas. A Adobe não o confirmou.
17 de março de 2026
A empresa divulgou uma falha de upload de arquivos no Magento e no Adobe Commerce, chamando-a de “PolyShell”. Disse que, na época, a correção só existia em uma versão de pré-lançamento (um pré-lançamento da 2.4.9)30 de março de 2026
A mesma empresa relatou um ataque em larga escala usando o PolyShell em que 471 lojas foram comprometidas em uma hora (esse relatório não cita um número de CVE)14 de julho de 2026
A Adobe publicou o APSB26-73 com correções para cada linha de versões com suporte24 de outubro de 2026
A empresa relatou que web shells instalados por meio do PolyShell (CVE-2026-48356) e de outras falhas, como a SessionReaper, foram usados para injetar JavaScript em páginas de lojas, em uma campanha que atingiu 953 lojas no total, a maioria Magento, desde julho de 202527 de outubro de 2026
A CISA incluiu a falha no KEV
Segundo o relatório de 24 de outubro, depois de instalar web shells, os atacantes injetaram JavaScript na tabela do banco de dados cms_block (os blocos exibidos nas páginas da loja). O script carrega código de sites externos que retorna um redirecionamento ou mais código para cada visitante. As 953 lojas são em sua maioria lojas Magento e incluem lojas comprometidas por meio de outra falha (SessionReaper, CVE-2025-54236).
O relatório diz que o código injetado também chegou a lojas corrigidas. Como exemplo, cita uma loja na 2.4.7-p10 sem nenhum patch do núcleo pendente. Também diz que apagar o script não remove o acesso do atacante. O relatório não deixa claro se esse acesso vinha de web shells instalados anteriormente ou de outra rota.
Se o PolyShell, como essa empresa o chama, for o mesmo que a CVE-2026-48356, o ataque em massa de março ocorreu antes de a Adobe lançar, em julho, as correções para as linhas com suporte (inferência deste site; a Adobe não confirmou exploração). Se sua loja já funcionava antes de julho, é mais seguro procurar vestígios desde março.
A situação no Japão
Em 28 de outubro, o JPCERT/CC e o IPA não haviam emitido alertas sobre essa falha. Dentro do que verificamos, nenhuma loja no Japão divulgou ter sido afetada por ela.
Se um script injetado for colocado em uma página de checkout, os dados de cartão que os compradores digitam podem ficar expostos. O padrão seguido pelas lojas que lidam com dados de cartão é o PCI DSS, e a explicação sobre XSS (cross-site scripting) mostra como scripts maliciosos acabam sendo executados nas páginas.
A visão deste site
A característica marcante das falhas de upload de arquivos é que o dano continua depois da correção. Arquivos instalados e código injetado nas páginas permanecem se foram adicionados antes da correção. Neste caso, a falha entrou no KEV três meses e meio depois de a Adobe lançar a correção. As lojas que aplicaram a correção de julho também não terminaram: precisam verificar sinais de invasão anteriores à data em que a aplicaram.
No Magento, os lugares a verificar são em grande parte fixos: as pastas de upload, cms_block e cms_page, e admin_user. Ao pedir a uma empresa de manutenção que faça a verificação, citar esses três lugares e pedir os resultados ajuda a evitar lacunas. As defesas gerais contra falhas de upload de arquivos são tratadas em Vulnerabilidades de upload de arquivos.
O que ainda não se sabe
| Item | Situação |
|---|---|
| Confirmação da exploração pela Adobe | O boletim (atualizado em 11 de agosto) ainda diz que a Adobe não tem conhecimento |
| Escala da exploração | A CISA não publicou detalhes. Os números vêm apenas dos relatórios de uma empresa de segurança de e-commerce |
| Se o PolyShell é esta CVE | Com base no relatório dessa empresa. A Adobe não menciona o nome |
| Situação da 2.4.9 | Afetada na tabela da Adobe. A empresa diz que a 2.4.9 incluía a correção (siga a tabela da Adobe) |
| Vítimas no Japão | Nenhuma divulgada |
Fontes
Todas verificadas em 28 de outubro de 2026.
- Adobe, “Security update available for Adobe Commerce | APSB26-73” (publicado em 14 de julho de 2026, atualizado em 11 de agosto) — adobe.com
- Adobe, “Security update available for Adobe Commerce - APSB26-73” (notas de versão, KA-37421) — experienceleague.adobe.com
- CISA, “CISA Adds Two Known Exploited Vulnerabilities to Catalog” (27 de outubro de 2026) — cisa.gov
- CISA, “Known Exploited Vulnerabilities Catalog” (dados da versão de 27 de outubro de 2026) — cisa.gov
- NVD, “CVE-2026-48356” — nvd.nist.gov
- Relatório de uma empresa de segurança de e-commerce (24 de outubro de 2026, incluindo como procurar vestígios de invasão) — sansec.io
- Texto da mesma empresa sobre o PolyShell (publicado em 17 de março de 2026, incluindo medidas provisórias) — sansec.io / seu relatório sobre o ataque em massa de março (30 de março de 2026) — sansec.io
- JPCERT/CC, lista de alertas de 2026 (em japonês) — jpcert.or.jp
Histórico de atualizações
2026-10-28: Primeira versão, com base em informações públicas da Adobe, da CISA e do NVD e em relatórios de uma empresa de segurança de e-commerce.
Leia a seguir
- Como se defender desse tipo de falha: Vulnerabilidades de upload de arquivos: como evitar web shells e RCE
- Como scripts maliciosos acabam sendo executados nas páginas: O que é XSS (cross-site scripting)
- Definindo a prioridade: Qual CVE corrigir primeiro: CVSS, EPSS e KEV
- Quando uma vulnerabilidade é anunciada: Guia de remediação de CVE
- Incluída no KEV no mesmo dia: Vulnerabilidade do Brotli CVE-2026-111497
- Termos: O que é um backdoor / O que é PCI DSS / O que é CVSS