# Vulnerabilidade Magento PHP2Shell: proteger Magento e Adobe Commerce > Proteger Magento e Adobe Commerce após o PHP2Shell: esclarecer o estado do PHP, proteger o env.php, encontrar skimmers na base de dados e em pub/ e verificar admins. Fonte: https://phpsos.de/pt/plattformen/magento-adobe-commerce/ Atualizado em: 25/10/2026 Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6 **Em resumo:** a atual vulnerabilidade do Magento chama-se PHP2Shell e não está no Magento, mas no PHP. Um patch do Magento não a corrige. Depois da atualização do PHP com reinício, deve verificar `app/etc/env.php`, a base de dados quanto a skimmers e a lista de contas de administrador. ## O que o PHP2Shell significa para as lojas Magento O Magento Open Source e o Adobe Commerce são grandes aplicações PHP que correm, na maioria dos casos, com PHP-FPM. Segundo a equipa do PHP, as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 permitem executar código malicioso sem autenticação. Para isso, é irrelevante se a própria loja está atualizada. Há anos que as lojas Magento são um alvo preferido do skimming de cartões de crédito, em que os dados introduzidos no checkout são lidos. O PHP2Shell abre mais um caminho para isso. A Palo Alto Networks contou mais de 22,6 milhões de instâncias PHP expostas e potencialmente vulneráveis; não se sabe que lojas se encontram entre elas. ## Vulnerabilidade Magento: apurar corretamente o estado do PHP O Magento não mostra a versão do PHP de forma destacada no admin. Verifique, por isso, o estado no painel de alojamento para o domínio ou peça ao seu fornecedor que o confirme. O `php -v` na linha de comandos mostra apenas o PHP da CLI, com que correm o `bin/magento` e as tarefas cron. O PHP web através do FPM pode ser outra versão, e ambos têm de ter o patch aplicado. As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35; os backports das distribuições podem ter números mais antigos. Quais as versões do PHP que a sua versão do Magento suporta, verifique-o nos requisitos de sistema da documentação da Adobe (experienceleague.adobe.com). No Adobe Commerce em infraestrutura da Adobe, pergunte à Adobe ou ao seu operador pelo estado. Um guia passo a passo está em [Verificar corretamente a versão e o estado do patch do PHP](https://phpsos.de/pt/php2shell/php-version-pruefen/). ## Onde se aloja o código malicioso no Magento | Local | Conteúdo | Ponto de verificação | |---|---|---| | `app/etc/env.php` | Base de dados, chave de encriptação, caminho do admin | Data de alteração, renovar valores em caso de suspeita | | `pub/` | Raiz de documentos, `pub/media`, `pub/static` | Ficheiros PHP nas pastas media e static | | `app/code/` | Módulos próprios | Módulos desconhecidos, ficheiros alterados | | `vendor/` | Pacotes Composer, também extensões | Desvios em relação ao lockfile | | `generated/`, `var/` | Código gerado, cache, registos | Guardar registos, regenerar código | | Base de dados | Configuração, blocos CMS, utilizadores admin | Scripts alheios, novos admins | No Magento, os skimmers estão muitas vezes na base de dados, por exemplo nas definições para scripts adicionais no cabeçalho ou no rodapé da página e em blocos CMS. Uma simples análise de ficheiros não os deteta. Acessos de leitura inofensivos ajudam numa primeira vista (prefixo das tabelas consoante a instalação): ```bash bin/magento info:adminuri bin/magento module:status ``` ```sql SELECT username, email, created FROM admin_user; SELECT path, value FROM core_config_data WHERE path LIKE 'design/%' AND value LIKE '% **Importante:** > Um checkout limpo não significa que não houve fuga de dados. Guarde os registos a partir de 20/10/2026 e cópias da base de dados antes de remover scripts. Só assim se poderá apurar mais tarde desde quando e que encomendas foram afetadas. ## Área de administração e extensões No Magento, o caminho do admin pode ser escolhido livremente e consta do `env.php`. Um caminho difícil de adivinhar é útil, mas não substitui a autenticação de dois fatores nem a restrição a redes conhecidas. Verifique regularmente os utilizadores admin e as respetivas funções, bem como as integrações e os tokens de API. As extensões de terceiros são numerosas no Magento: métodos de pagamento, ligações ERP, módulos de pesquisa e de marketing. Cada uma traz código que tem de ser verificado nas atualizações do PHP. Use o `composer audit` regularmente e remova por completo os módulos desativados. Pense também nos processos em segundo plano. O Magento trabalha com tarefas cron e, muitas vezes, com consumers de filas, que correm como processos PHP próprios através da linha de comandos. Após a atualização do PHP, estes têm de ser reiniciados tal como o PHP-FPM. Depois de uma mudança da versão principal do PHP, deve ainda mandar reconstruir o código gerado em `generated/` e os ficheiros estáticos e percorrer a loja num ambiente de teste antes de retomar a operação em produção. Como o reinício se faz corretamente, descreve-o [Reiniciar o PHP-FPM e todos os workers](https://phpsos.de/pt/php2shell/php-fpm-neustart/). ## O que uma atualização do Magento consegue e o que não consegue Uma versão do Magento ou um patch de segurança da Adobe corrige falhas no código da loja. Não aplica patch ao PHP, não reinicia processos FPM, não remove scripts da base de dados e não elimina contas de admin alheias. Se já foi executado código, é necessária uma investigação. Como reconhecer backdoors, explica-o [Reconhecer e remover webshells](https://phpsos.de/pt/ratgeber/webshell-erkennen/). Para comerciantes com pagamento por cartão aplica-se ainda: verifique as regras do seu prestador de pagamento para incidentes de segurança e articule-se com ele antes de renovar chaves. Se é necessária uma notificação à autoridade de proteção de dados, esclareça-o com o seu encarregado de proteção de dados ou advogado. ## Como ajuda concretamente a PHP SOS? - Esclarecemos o PHP web e o PHP CLI do seu servidor Magento e fazemos confirmar o patch e o reinício. - Guardamos registos, ficheiros e base de dados de forma rastreável, se necessário através da nossa [forense informática](https://phpsos.de/pt/leistungen/it-forensik/). - Verificamos `env.php`, `pub/`, módulos, tabelas de configuração, blocos CMS e contas de admin. - Limpamos, renovamos chaves e acessos e documentamos o período de possível afetação para a proteção de dados e para o prestador de pagamento. ## Perguntas frequentes **Um patch de segurança do Magento também corrige o PHP2Shell?** Não. Os patches do Magento corrigem falhas no código da loja. O PHP2Shell está no interpretador PHP do servidor e só é corrigido por uma atualização do PHP ou por um backport confirmado, com reinício de todos os processos. **Onde escondem os atacantes skimmers de cartões de crédito no Magento?** Muitas vezes não em ficheiros, mas na base de dados, por exemplo nas definições para scripts adicionais no cabeçalho da página ou em blocos CMS. Por isso, perante uma suspeita, deve sempre verificar-se também a base de dados. **Quem aplica o patch ao PHP no Adobe Commerce na cloud?** Depende do seu contrato e do seu ambiente. Pergunte por escrito à Adobe ou ao seu operador pelo estado do PHP e pelo reinício. As extensões próprias e os conteúdos da base de dados continuam a ser da sua responsabilidade. **Porque é que o app/etc/env.php é tão importante?** O ficheiro contém o acesso à base de dados, a chave de encriptação e o caminho para a área de administração. Quem o conseguiu ler pode desencriptar valores cifrados e encontrar o admin. Perante uma suspeita, estes valores devem ser renovados. ## Fontes - [php.net: avisos de segurança](https://www.php.net/) - [Adobe Commerce](https://business.adobe.com/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) - [Palo Alto/TechTarget: instâncias expostas](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)